/srv/irclogs.ubuntu.com/2016/06/09/#launchpad.txt

=== 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
clivejois there any way to auto-merge a merge request when accepted via LP?13:55
clivejofor git13:55
dobeyyou'd have to set up some CI to do it13:58
dobeythere's no feature in launchpad itself which auto-merges branches, be they git or bzr13:58
cjwatsonclivejo: Some people are using https://code.launchpad.net/~zyga/+git/pmr to do this14:17
clivejocjwatson: what is $PROJECT ?14:19
cjwatsonclivejo: context please?14:19
clivejohttps://git.launchpad.net/~zyga/+git/pmr/tree/process-merge-requests14:19
clivejoUsage: process-merge-requests PROJECT [PROJECT...]14:20
cjwatsonPlease don't assume from the fact that I mention a tool that I know all about it14:20
cjwatsonIts help says that it's the name of a Launchpad project to process14:20
cjwatsonIf you're not working with a top-level project then you might need to adjust it14:20
clivejojust need something to accept the git merge request and have it auto add the code into the LP git repo14:22
cjwatsonIf 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 process14:22
cjwatsonStill, it'll be a lot easier for you to hack that into pmr than to start entirely from scratch14:22
rbasakIn 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
rbasakHowever, 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
rbasakIs 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
cjwatsonHm, difficult14:27
cjwatsonRelates to the refs/merge/ namespace that we've wanted to implement for a while14:27
wgrantI'd be reluctant to expose old commits.14:31
wgrantIt's a potential security issue.14:32
wgrantrbasak: 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
rbasakwgrant: 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
rbasakwgrant: 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
cjwatsonI don't think it's a security issue for something that was proposed as a merge.14:37
cjwatsonWe certainly don't want to expose unreferenced commits *in general*.14:37
wgrantPerhaps the act of creating a merge proposal can be said to disclose the history of the MP.14:37
rbasakwgrant: at MP stage, rebasing a branch is absolutely a thing. That's exactly what Linux devs do with RFC v2, v3 etc.14:37
wgrantrbasak: But Linux uses patches, not branches.14:38
rbasakThey are one and the same.14:38
wgrantIt's not quite the same thing.14:38
rbasakgit interchanges between them losslessly.14:38
cjwatsonI 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
wgrantHardly.14:39
wgrantIf I apply patches I expect to not be sensibly mergable.14:39
wgrantIf I base my thing on a branch I can usually expect it to be mergable.14:39
wgrantIt's extremely distasteful to rebase a public branch, but some people do do it.14:39
rbasakDefine "public branch".14:40
rbasakIf it's merely "the public can see it", then I disagree.14:40
cjwatsonWe would have more of a leg to stand on there if LP accepted incoming patches as a way to create merge proposals.14:40
cjwatsonBut 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
rbasakI 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
rbasakOr, more specifically, the difference between a patchset and a git ref.14:41
rbasakA branch additionally implies that you intend to grow it further I suppose, whereas a tag doesn.t14:42
cjwatsonI 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
cjwatsons/stage/state/14:42
cjwatsonSerious git users often have some branches that they advertise as FFing and some that they advertise as explicitly not being so.14:42
rbasakRight. I like to share my work, even if I intend to rebase it.14:43
rbasakAs long as I make that clear, I don't see that it automatically makes it distasteful to publish my work in progress.14:43
rbasakOTOH, 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
wgrantWhy did you need to see the old commit in this case?14:44
rbasakBecause 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
wgrantSo I hear that VCSes have a concept of controlling changes :P14:45
rbasakthe review can be severe enough, that is.14:45
rbasakThis is the collision of two things in the VCS. 1) A time machine; 2) Management of patchsets.14:46
rbasakOnly git really has 2.14:46
rbasakWhat I care about is the evolution of an entire patchset over time. I want the patchset to be a first class citizen.14:47
rbasakConceptually it's git-dpm but for Ubuntu deltas.14:47
wgrantIn GitHub PR terms that would probably be one PR per commit, and squash at the end.14:47
rbasakYeah, 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
cjwatsonSquashing at the end is somewhat different.14:48
rbasakAdvanced git users consider Github broken too.14:48
wgrantRight, I'm just trying to think how people who use this workflow would cope with GitHub.14:49
wgrantAs presumably they do.14:49
cjwatsonBy which I mean that squashes everything into just one commit, rather than just squashing away the commits before the most recent rebase.14:49
wgrantcjwatson: Right, but on GitHub you manage patchsets by using one PR per patch.14:50
wgrantrbasak is trying to do a whole patchset in a single MP.14:50
cjwatsonMaybe people just do much smaller patchsets on GitHub since its workflow for it is still a bit more convenient than ours?14:50
wgrantBut is probably not unreasonable, but not how GitHub, for example, does it.14:50
cjwatsonThough I guess that can't account for all of it.14:51
wgrantIt also seems like it would be useful to diff equivalent commits in different revisions of the MP.14:52
wgrantAs gerrit allows.14:52
wgrantWhich is doable, but awkward, by grabbing both commits locally and diffing them.14:52
cjwatsonIt does commit message analysis IIRC?14:52
wgrantBut that's hardly optimal.14:52
rbasakI'd like that feature in git too.14:52
wgrantgerrit uses Change-Ids, I think.14:52
rbasakIt'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
rbasakI've used git notes to track changes through rebases before, though it's still painful.14:53
dobeyhmm. how do MPs for git work? /Code/Git doesn't say anything about them :-/18:01
naccdobey: we've done a few if you want some links (using the server team git workflow)18:02
naccthey seem to mostly work18:02
rbasakdobey: there's a page in LP for each branch. Go to that page and create the MP from there.18:02
dobeynacc: i know i've seen them. but i don't see how to create one18:02
naccdobey: oh i see18:02
naccyeah what rbasak said, it's only visible from the to-be-merged branch18:03
naccs/the/a/18:03
rbasakhttps://code.launchpad.net/~racb -> View Git repositories -> <repo> -> <branch> -> Propose for merging18:03
dobeyso 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
naccdobey: you could, i think18:07
rbasakWhen 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
naccyour 'master' branch is not the same as the origin 'master' branch18:07
naccusually you'd use a 'topic' branhc, though, just for clarity18:08
rbasakSo 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
rbasakWhen 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
dobeyhmm18:19
dobeyis https://help.launchpad.net/Code/Git wrong for how to add the remote?18:20
dobeygit complains "remote origin already exists"18:20
rbasakdobey: 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
dobeyrbasak: so the docs are wrong (or at least unclear)?18:35
cjwatsonit'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, yes18:49
cjwatson(I don't think we can get into documenting all of git though ...)18:49
dobeysure. 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
cjwatsonwhen I'm out from postgres planner headspace :)18:54
cjwatsonwouldn't be sad about a reminder bug18:55
dobeyalright :)19:04
lifelesscjwatson: you wouldn't know how many source packages ubuntu has currently, offhand ?20:38
lifelesscjwatson: I thought LP might tell me, but nope :)20:38
lifelesscjwatson: nearest 5K would be more than sufficient for my needs20:39
dobeylifeless: 1 → 75 of 32356 results20:49
dobeylifeless: https://launchpad.net/ubuntu/+search?text=20:49
dobeyoh that's binaries20:50
dobeydoh20:50
dobeypackages.ubuntu.com requires at least 2 characters in keyword search. blah20:52
maprericjwatson: imho the null-and-void task from these 3 bugs should be removed.  can you do it? https://bugs.launchpad.net/null-and-void21:26
tewardDo I have to deactivate an existing signature on the CoC if I want to update it with my current PGP keys?21:32
lifelessdobey: yeah21:42
rbasaklifeless:23:21
rbasak$ hcdist yakkety-proposed grep-dctrl-sources -sVersion .|wc -l23:21
rbasak2697523:21
rbasak26125 in the release pocket.23:21
rbasakNot 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!