| === gkadam is now known as Guest11574 | ||
| === Guest11574 is now known as gkadam | ||
| === _morphis is now known as morphis | ||
| === acheron_uk is now known as acheronuk | ||
| === JanC is now known as Guest27912 | ||
| === JanC_ is now known as JanC | ||
| === JanC_ is now known as JanC | ||
| clivejo | is there any way to auto-merge a merge request when accepted via LP? | 13:55 |
|---|---|---|
| clivejo | for git | 13:55 |
| dobey | you'd have to set up some CI to do it | 13:58 |
| dobey | there's no feature in launchpad itself which auto-merges branches, be they git or bzr | 13:58 |
| cjwatson | clivejo: Some people are using https://code.launchpad.net/~zyga/+git/pmr to do this | 14:17 |
| clivejo | cjwatson: what is $PROJECT ? | 14:19 |
| cjwatson | clivejo: context please? | 14:19 |
| clivejo | https://git.launchpad.net/~zyga/+git/pmr/tree/process-merge-requests | 14:19 |
| clivejo | Usage: process-merge-requests PROJECT [PROJECT...] | 14:20 |
| cjwatson | Please don't assume from the fact that I mention a tool that I know all about it | 14:20 |
| cjwatson | Its help says that it's the name of a Launchpad project to process | 14:20 |
| cjwatson | If you're not working with a top-level project then you might need to adjust it | 14:20 |
| clivejo | just need something to accept the git merge request and have it auto add the code into the LP git repo | 14:22 |
| cjwatson | If you're working with a package, say, or just a random single repository - I think pmr probably needs to be adjusted to be able to work with something other than a project, and perhaps use e.g. git_repository.landing_candidates to find the list of MPs to process | 14:22 |
| cjwatson | Still, it'll be a lot easier for you to hack that into pmr than to start entirely from scratch | 14:22 |
| rbasak | In https://code.launchpad.net/~louis-bouchard/ubuntu/+source/kexec-tools/+git/kexec-tools/+merge/296323 caribou rebased, and Launchpad seems to have handled that quite well. It has two diffs stored and I can pick between the two, and it tells me the commit hash of the two tips. | 14:24 |
| rbasak | However, I couldn't seem to grab the old tip without asking caribou to push a tag (which he's now done for me) | 14:24 |
| rbasak | Is this something that LP should do in MP handling, perhaps, so the before-rebase tips are available still? Or am I missing something? | 14:24 |
| cjwatson | Hm, difficult | 14:27 |
| cjwatson | Relates to the refs/merge/ namespace that we've wanted to implement for a while | 14:27 |
| wgrant | I'd be reluctant to expose old commits. | 14:31 |
| wgrant | It's a potential security issue. | 14:32 |
| wgrant | rbasak: Why do you need the pre-rebase commit? | 14:33 |
| wgrant | (and why was a pushed branch rebased? that's not usually a thing.) | 14:33 |
| rbasak | wgrant: for any team that follows a git rebase workflow. In this case, what is important is the logical Ubuntu delta that we're breaking down into a patchset and then rebasing and pushing as an MP for an Ubuntu upload. If that needs to be redone, that's a rebase. | 14:35 |
| rbasak | (I don't think it was needed in this particular case, but in the general case I think we want it) | 14:35 |
| rbasak | wgrant: it can't be a security issue right now because LP happily displays the old diff still. I just can't get it locally easily but I could derive it as the diff is right there. | 14:37 |
| rbasak | (or, if you consider it a security issue, you have that right now) | 14:37 |
| cjwatson | I don't think it's a security issue for something that was proposed as a merge. | 14:37 |
| cjwatson | We certainly don't want to expose unreferenced commits *in general*. | 14:37 |
| wgrant | Perhaps the act of creating a merge proposal can be said to disclose the history of the MP. | 14:37 |
| rbasak | wgrant: at MP stage, rebasing a branch is absolutely a thing. That's exactly what Linux devs do with RFC v2, v3 etc. | 14:37 |
| wgrant | rbasak: But Linux uses patches, not branches. | 14:38 |
| rbasak | They are one and the same. | 14:38 |
| wgrant | It's not quite the same thing. | 14:38 |
| rbasak | git interchanges between them losslessly. | 14:38 |
| cjwatson | I don't much like the "rebase proposed branch" workflow, but it's hugely popular in various communities and I think we ought to handle it well. | 14:38 |
| wgrant | Hardly. | 14:39 |
| wgrant | If I apply patches I expect to not be sensibly mergable. | 14:39 |
| wgrant | If I base my thing on a branch I can usually expect it to be mergable. | 14:39 |
| wgrant | It's extremely distasteful to rebase a public branch, but some people do do it. | 14:39 |
| rbasak | Define "public branch". | 14:40 |
| rbasak | If it's merely "the public can see it", then I disagree. | 14:40 |
| cjwatson | We would have more of a leg to stand on there if LP accepted incoming patches as a way to create merge proposals. | 14:40 |
| cjwatson | But right now the only way we advertise to ask the maintainer of an LP-hosted repository to take a patch is by way of an MP, so ... | 14:41 |
| rbasak | I still fail see the difference between a patchset and a branch, except that a patchset needs to imply what to base it on and with a branch that's explicit. | 14:41 |
| rbasak | Or, more specifically, the difference between a patchset and a git ref. | 14:41 |
| rbasak | A branch additionally implies that you intend to grow it further I suppose, whereas a tag doesn.t | 14:42 |
| cjwatson | I would be in favour of explicitly modelling the rather commonplace notion of "this branch is expected not to be fast-forwarding", although it would be tricky since at the moment we try not to maintain too much explicit database stage about refs. | 14:42 |
| cjwatson | s/stage/state/ | 14:42 |
| cjwatson | Serious git users often have some branches that they advertise as FFing and some that they advertise as explicitly not being so. | 14:42 |
| rbasak | Right. I like to share my work, even if I intend to rebase it. | 14:43 |
| rbasak | As long as I make that clear, I don't see that it automatically makes it distasteful to publish my work in progress. | 14:43 |
| rbasak | OTOH, it it's a coordination point for others, eg. a project master branch, or even a feature branch that multiple people are working on, then I wouldn't rebase that. | 14:44 |
| wgrant | Why did you need to see the old commit in this case? | 14:44 |
| rbasak | Because I want to diff the old commit against the new commit so that I can check that my review points have been addressed and nothing else has regressed that I might be unhappy about. In this case, I would have preferred a couple of commits on to the end. But in the general case, the review is severe enough that starting again would be easier both for the submitter and the reviewer. | 14:45 |
| wgrant | So I hear that VCSes have a concept of controlling changes :P | 14:45 |
| rbasak | the review can be severe enough, that is. | 14:45 |
| rbasak | This is the collision of two things in the VCS. 1) A time machine; 2) Management of patchsets. | 14:46 |
| rbasak | Only git really has 2. | 14:46 |
| rbasak | What I care about is the evolution of an entire patchset over time. I want the patchset to be a first class citizen. | 14:47 |
| rbasak | Conceptually it's git-dpm but for Ubuntu deltas. | 14:47 |
| wgrant | In GitHub PR terms that would probably be one PR per commit, and squash at the end. | 14:47 |
| rbasak | Yeah, and in the bzr world I was told to use stacked branches. | 14:48 |
| wgrant | (GitHub doesn't have the feature you ask for here, so if the workflow is common then there must be some other way to achieve it with PRs, which is interesting to look at here) | 14:48 |
| cjwatson | Squashing at the end is somewhat different. | 14:48 |
| rbasak | Advanced git users consider Github broken too. | 14:48 |
| wgrant | Right, I'm just trying to think how people who use this workflow would cope with GitHub. | 14:49 |
| wgrant | As presumably they do. | 14:49 |
| cjwatson | By which I mean that squashes everything into just one commit, rather than just squashing away the commits before the most recent rebase. | 14:49 |
| wgrant | cjwatson: Right, but on GitHub you manage patchsets by using one PR per patch. | 14:50 |
| wgrant | rbasak is trying to do a whole patchset in a single MP. | 14:50 |
| cjwatson | Maybe people just do much smaller patchsets on GitHub since its workflow for it is still a bit more convenient than ours? | 14:50 |
| wgrant | But is probably not unreasonable, but not how GitHub, for example, does it. | 14:50 |
| cjwatson | Though I guess that can't account for all of it. | 14:51 |
| wgrant | It also seems like it would be useful to diff equivalent commits in different revisions of the MP. | 14:52 |
| wgrant | As gerrit allows. | 14:52 |
| wgrant | Which is doable, but awkward, by grabbing both commits locally and diffing them. | 14:52 |
| cjwatson | It does commit message analysis IIRC? | 14:52 |
| wgrant | But that's hardly optimal. | 14:52 |
| rbasak | I'd like that feature in git too. | 14:52 |
| wgrant | gerrit uses Change-Ids, I think. | 14:52 |
| rbasak | It's painful though, to follow commits through rebases since they can be squashed, split, deleted, added to or even juggled in a more complex way than that. | 14:53 |
| rbasak | I've used git notes to track changes through rebases before, though it's still painful. | 14:53 |
| dobey | hmm. how do MPs for git work? /Code/Git doesn't say anything about them :-/ | 18:01 |
| nacc | dobey: we've done a few if you want some links (using the server team git workflow) | 18:02 |
| nacc | they seem to mostly work | 18:02 |
| rbasak | dobey: there's a page in LP for each branch. Go to that page and create the MP from there. | 18:02 |
| dobey | nacc: i know i've seen them. but i don't see how to create one | 18:02 |
| nacc | dobey: oh i see | 18:02 |
| nacc | yeah what rbasak said, it's only visible from the to-be-merged branch | 18:03 |
| nacc | s/the/a/ | 18:03 |
| rbasak | https://code.launchpad.net/~racb -> View Git repositories -> <repo> -> <branch> -> Propose for merging | 18:03 |
| dobey | so i have to make new branches; i can't just clone, add new remote, make changes, commit, push up, and then propose that? | 18:07 |
| dobey | <- not a git user. | 18:07 |
| nacc | dobey: you could, i think | 18:07 |
| rbasak | When you push up, you're effectively creating a branch. LP requires you to push the branch to your own repo though, not a team repo. | 18:07 |
| nacc | your 'master' branch is not the same as the origin 'master' branch | 18:07 |
| nacc | usually you'd use a 'topic' branhc, though, just for clarity | 18:08 |
| rbasak | So yes, just clone, make changes, add new remote (your own LP URL for the repo). As soon as you push, your personal repo and branch get automatically created. | 18:08 |
| rbasak | When the MP is done, somebody who can push to the team repo will need to push the branch. | 18:09 |
| rbasak | (which I think is essentially the same as bzr?) | 18:09 |
| dobey | hmm | 18:19 |
| dobey | is https://help.launchpad.net/Code/Git wrong for how to add the remote? | 18:20 |
| dobey | git complains "remote origin already exists" | 18:20 |
| rbasak | dobey: you're naming the remote origin. Name it something else. | 18:28 |
| rbasak | (my convention is "lpme") | 18:28 |
| rbasak | "git remote add lpme ..." | 18:29 |
| dobey | rbasak: so the docs are wrong (or at least unclear)? | 18:35 |
| cjwatson | it's not wrong as such, it's just describing the situation of a new repository rather than one that you cloned from elsewhere. but perhaps unclear, yes | 18:49 |
| cjwatson | (I don't think we can get into documenting all of git though ...) | 18:49 |
| dobey | sure. maybe change the page structure though so it's above the "pulling code from git" section, and maybe rename it to "Creating a new repository" or something :) | 18:51 |
| cjwatson | when I'm out from postgres planner headspace :) | 18:54 |
| cjwatson | wouldn't be sad about a reminder bug | 18:55 |
| dobey | alright :) | 19:04 |
| lifeless | cjwatson: you wouldn't know how many source packages ubuntu has currently, offhand ? | 20:38 |
| lifeless | cjwatson: I thought LP might tell me, but nope :) | 20:38 |
| lifeless | cjwatson: nearest 5K would be more than sufficient for my needs | 20:39 |
| dobey | lifeless: 1 → 75 of 32356 results | 20:49 |
| dobey | lifeless: https://launchpad.net/ubuntu/+search?text= | 20:49 |
| dobey | oh that's binaries | 20:50 |
| dobey | doh | 20:50 |
| dobey | packages.ubuntu.com requires at least 2 characters in keyword search. blah | 20:52 |
| mapreri | cjwatson: imho the null-and-void task from these 3 bugs should be removed. can you do it? https://bugs.launchpad.net/null-and-void | 21:26 |
| teward | Do I have to deactivate an existing signature on the CoC if I want to update it with my current PGP keys? | 21:32 |
| lifeless | dobey: yeah | 21:42 |
| rbasak | lifeless: | 23:21 |
| rbasak | $ hcdist yakkety-proposed grep-dctrl-sources -sVersion .|wc -l | 23:21 |
| rbasak | 26975 | 23:21 |
| rbasak | 26125 in the release pocket. | 23:21 |
| rbasak | Not sure if I missed something but it sounds about right. | 23:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!