| SamB_MacG5 | okay, so I got this branch merged into 2.4, anything I should do to get it merged also in 2.5 and bzr.dev? https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6 | 01:14 |
|---|---|---|
| mgrandi | if you propose to merge into 2.5 and trunk they will review it i believe | 01:21 |
| SamB_MacG5 | merge from where, 2.4 or my branch? | 01:28 |
| mgrandi | go to the link you pasted and click 'propse for merging' | 01:29 |
| mgrandi | and then select the branch, probably lp:bzr-2.5 or whatever its called, and lp:bzr (need to do it twice) | 01:30 |
| * SamB_MacG5 wishes he could start by cloning https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6/+merge/122168 ... | 01:32 | |
| mgrandi | i mean thats pretty much what happens | 01:33 |
| mgrandi | when you click "propose for merging" | 01:34 |
| mgrandi | just link the same bug report | 01:34 |
| mgrandi | actually you don't eve need to do that, the bug is already linked | 01:34 |
| mgrandi | just propose to merge into the trunk bzr branch and the 2.5 one | 01:34 |
| SamB_MacG5 | This really doesn't look right, though... https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6/+merge/122377 | 01:50 |
| SamB_MacG5 | in fact, some irrelevant (for my purposes) changes have conflicts ... | 01:51 |
| * SamB_MacG5 wonders why the 2.5 code from this conflict wasn't backported, rather than being re-written from scratch ... | 01:52 | |
| * SamB_MacG5 realizes that these conflict markers leave out the "ancestor" bits ... | 01:53 | |
| * SamB_MacG5 grumbles at jam, who is evidently not here anyway ... | 02:06 | |
| mgrandi | yeah they are all on in like..5 hours! haha | 02:45 |
| * SamB_MacG5 accidentally adds a second review request ... how did the first one get there? | 03:52 | |
| * SamB_MacG5 specifically left that box unchecked to start with... | 03:53 | |
| PMS | Why is Bazaar better than Mercurial? :) | 07:05 |
| quotemstr | What do I need to do to resolve "bzr: ERROR: Server sent an unexpected error: ('error', 'AppendRevisionsOnlyViolation', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting"? | 07:18 |
| quotemstr | I just added a change to trunk, merged, and then tried to push. | 07:19 |
| quotemstr | I'm not trying to change history. What gives? | 07:19 |
| fullermd | PMS: bzr has 3 A's; hg only has 1. So it's 3x better. | 07:26 |
| fullermd | quotemstr: AppendRevisionsOnly prevents changes to the mainline. So you did something like 'branch off trunk ; make changes ; merge changes to trunk since initial branch ; try pushing over trunk" | 07:27 |
| fullermd | Which means the 'new' revs on trunk are now no longer on your mainline, ergo it disallows it. | 07:28 |
| fullermd | The resolution would be either (a) merge into trunk and push, rather than merging trunk and pushing, or (2) unset a_r_o, if you don't really want it. | 07:29 |
| quotemstr | fullermd: I don't control the remote, so it sounds like I really need two local branches. | 07:30 |
| quotemstr | fullermd: One in which I make changes and occasionally merge from trunk, and another slaved to upstream, into which I only ever merge changes from the first branch, then push. | 07:30 |
| fullermd | Yeah, it's simplest to keep a 'pristine' trunk for gating things upstream. | 07:31 |
| fullermd | Maybe as a checkout; that expresses intent well. | 07:31 |
| vila | fullermd, mgz: bzr.transform.orphan_policy=move | 07:36 |
| quotemstr | So if I merge a change from branch B into branch A, what happens to the commit messages attached to the changes in B? | 07:55 |
| quotemstr | bzr log just displays the merge commit message. | 07:56 |
| quotemstr | Is there a way to make history linear instead | 07:57 |
| quotemstr | ? | 07:57 |
| fullermd | It's in there, log just doesn't expand out the merges by default. | 07:57 |
| fullermd | With '-n0' it'll show all the merged revs. | 07:58 |
| quotemstr | Ah, okay. Thanks. | 07:58 |
| quotemstr | Okay --- I have branches A and B. A is the pristine upstream branch; B is the forked dev branch. | 08:03 |
| quotemstr | I merged B into A, and bzr log -n0 shows B's commit as a child of the merge commit into A. | 08:04 |
| quotemstr | I pushed from A, then pulled into B. Now B's log matches A's and the trunk's. | 08:04 |
| quotemstr | But didn't that pull just silently change the history in B? Now B has a merge commit where it previously had a direct commit. | 08:04 |
| fullermd | Not exactly. It changed the _mainline_, but merely appended to the history. | 08:05 |
| fullermd | Neither push nor pull will ever do more than append new revs (unless you smack it with --overwrite). a_r_o additionally prevents you from appending revs in such a way that the mainline changes. | 08:06 |
| quotemstr | So the mainline is a _linear_ series of commits. Pull only adds commits, but it can change this "mainline" path that connects them. Right? | 08:07 |
| fullermd | Not... exactly. May be close enough for understanding, but I generally feel compelled to over-explain... | 08:13 |
| fullermd | The mainline is a subset of the revisions in the branch, chosen by taking a particular path through the history. | 08:13 |
| fullermd | It winds up creating a purely linear series. In the event of a branch with purely linear history (i.e., no merges), it winds up being equivalent to the whole history. | 08:14 |
| fullermd | But most nontrivial branches have merges, so the mainline goes down one side of that history and elides the other. | 08:14 |
| fullermd | The result, in a loose colloquial sense, becomes a list of "commits made on this branch" (as distinct from "commits made elsewhere and merged into this branch"). | 08:15 |
| fullermd | http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/RevNumbering may be helpful | 08:16 |
| fullermd | Anyway, it happens via backtracking in a certain way from the head rev of the branch. So any time the head changes, the mainline potentially can change (well, it DOES change, by getting new stuff appended to it. It may change by stuff that previously wound up on it not doing so anymore; that's what a_r_o prevents) | 08:18 |
| fullermd | In the case of your pull there, you appended history; the previous head rev is still in the history, which means all the stuff before it is too. You only added new revs to the pile. | 08:19 |
| fullermd | But the mainline changed, because the path you get from walking back using the particular rules from the _new_ head rev doesn't include the old head. | 08:20 |
| * fullermd wanders off for a little while, content that he's thoroughly confused what was once somewhat clear. | 08:21 | |
| quotemstr | No, that makes sense. Thanks. | 08:22 |
| === r0bby is now known as robbyoconnor | ||
| === yofel_ is now known as yofel | ||
| * SamB_MacG5 would have told PMS that bzr has a better command parsing API; mercurial's seems to be all lists of tuples, which presumably makes it hard to improve without breaking existing plugins/extensions | 15:26 | |
| SamB_MacG5 | so, can anyone tell me what to do with https://code.launchpad.net/~naesten/bzr/1044043-2.4-needs-python2.6/+merge/122377 ? | 15:27 |
| * SamB_MacG5 suddenly recalls having dreamed that he ran into water in a channel called #bazaar | 15:31 | |
| jelmer | hi SamB_MacG5 | 15:58 |
| SamB_MacG5 | jelmer: hi | 16:54 |
| jelmer | SamB_MacG5, I'm not sure I follow your comment | 16:54 |
| jelmer | why does this have extra revisions that aren't on lp:bzr/2.5 | 16:55 |
| jelmer | ? | 16:55 |
| SamB_MacG5 | jelmer: because it was originally made for lp:bzr/2.4 | 16:55 |
| SamB_MacG5 | and it hadn't occurred to me to start my branch with a common ancestor of lp:bzr{/2.4,/2.5,} | 16:57 |
| SamB_MacG5 | hmm, how would I even *do* that? | 17:00 |
| * SamB_MacG5 wonders why git makes hard things easy and easy things hard ... | 17:01 | |
| vila | SamB_MacG5: you don't ;) | 17:02 |
| vila | SamB_MacG5: but did you merge lp:bzr/2.5 before making your proposal ? | 17:02 |
| fullermd | Oh, it's easy to get a common ancestor. Just branch rev 1 ;p | 17:03 |
| SamB_MacG5 | fullermd: You know very well that that's not what I meant! | 17:03 |
| fullermd | When has that ever stopped me? O:-} | 17:04 |
| vila | SamB_MacG5: you don't know fullermd very well ;) | 17:04 |
| SamB_MacG5 | fullermd: yeah, usually doesn't stop me, either | 17:04 |
| SamB_MacG5 | Regardless, I was clearly referring to a function like that specified in git-merge-base(1) | 17:08 |
| SamB_MacG5 | er, or not. | 17:09 |
| SamB_MacG5 | I hadn't seen what it did in the more-than-two-args case yet ... | 17:09 |
| fullermd | The usual answer is probably something like "run missing, and backstep manually (mentally)". | 17:10 |
| SamB_MacG5 | I couldn't get missing to work for some reason :-( | 17:10 |
| SamB_MacG5 | it kept telling me everything was up to date | 17:11 |
| fullermd | In this particular case, you could cheat and know that 2.4 gets merged into 2.5 aperiodically (and never the reverse), so just scroll through the 2.5 log until you see the last 2.4 merge and take that rev. | 17:11 |
| SamB_MacG5 | true | 17:11 |
| vila | or just merge lp:bzr/2.5... | 17:11 |
| fullermd | That wouldn't give you something mergeable into 2.4 ;p | 17:11 |
| fullermd | ... well, it WOULD, but you'd have to sneak it through... | 17:12 |
| vila | my understanding is that the patch has already been landed in 2.4 | 17:12 |
| jelmer | SamB_MacG5, just propose a merge to the oldest branch you care about | 17:12 |
| jelmer | SamB_MacG5, that branch will be periodically upmerged | 17:12 |
| SamB_MacG5 | okay, so I should delete this proposal since I already did that? | 17:13 |
| SamB_MacG5 | (In this case, the oldest branch it makes sense for is 2.4, since it's updating documentation to account for the Python dependancy having been upped to Python 2.6 at that point ...) | 17:15 |
| * SamB_MacG5 waits for someone to confirm that he should delete before pushing the button | 17:17 | |
| * SamB_MacG5 wishes bzr had a functional syntax for revisions ... | 17:21 | |
| SamB_MacG5 | jelmer: I should delete my proposal, then, since my branch is already merged into lp:bzr/2.4 ? | 17:22 |
| jelmer | SamB_MacG5, I tihnk so | 17:57 |
| * SamB_MacG5 discovers that his IRC client is under a hilarious dual license | 18:51 | |
| SamB_MacG5 | Oh, it looks like that's just the YAML library ... still ;-) | 19:02 |
| * SamB_MacG5 gripes about Python's broken SIGINT handling | 23:16 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!