| croepha | hello | 15:11 |
|---|---|---|
| croepha | anyone know of an easy way to pull from an upstream mainline? | 15:12 |
| croepha | what I do now, is bzr branch head; cd head; bzr merge ../mybranch; bzr commit; cd .. ; rm -rvf mybranch; bzr branch head mybranch; rm -rvf head | 15:14 |
| fullermd | That... doesn't seem an obviously meaningful action. Can you elaborate a bit more higher-level what you're wanting to do? | 15:23 |
| === beuno_ is now known as beuno | ||
| croepha | so, there is a mainline “head”, and my project branch “mybranch” is to be merged into “head” by the “head” maintainer at some point in the future, but for now, I would like to bring other changes that have been made to the head, and bring them into my project. I would really like to bring those in withourt adding any new commits | 15:27 |
| croepha | fullermd: ^ | 15:28 |
| fullermd | Well, you can't do it "without adding new commits". You've got two separate streams to reconcile, so there has to be a merge revision. | 15:36 |
| croepha | right | 15:36 |
| fullermd | Just 'bzr merge head' in your branch. | 15:36 |
| fullermd | All you're doing with that dance is clumsily manually implementing[1] 'merge --reverse' to swap around the order of the heads, which isn't what you'd want in this case anyway. | 15:37 |
| fullermd | [1] (which of course is all you can do, since nobody's written --reverse, but still) | 15:37 |
| croepha | well, I think there should be a commit that brings mybranch into head, but not head into mybranch, because later on, when people look at the mainline log, they will see people doing these extra commits that were just to get head code into project branches | 15:39 |
| fullermd | When mybranch finally lands, it'll be merged into head. When you're continuing mybranch but keeping up with head, you're merging head into it. | 15:40 |
| croepha | ok, there wont be any cris-cross warnning doing that? | 15:41 |
| croepha | warnings* | 15:41 |
| fullermd | No, that's all fine. Criss-cross merges are something else entirely. | 15:41 |
| fullermd | That has to do with merges lacking a unique MRCA. You can't get that with "separate branch, occasionally merging trunk, eventually merged into trunk" | 15:43 |
| fullermd | You usually get it with two branches repeatedly merging each other, or one branch repeatingly merging another, plus both of them merging a third. | 15:43 |
| fullermd | But in your case, all the merges go one way until the end, so there's no crossing. | 15:43 |
| croepha | if there was continous merges on both sides, a way to solve it would be to do a bzr pull head before doing another commit on mybranch | 15:45 |
| croepha | ? | 15:45 |
| croepha | not merges, commits | 15:46 |
| croepha | if there were continous commits .. | 15:46 |
| fullermd | Once you make a criss-cross, there isn't any way to resolve it but to plow through it (either by manually dealing with spurious conflicts, or using a different merge algorithm that doesn't notice such, etc) | 15:46 |
| fullermd | You can't pull once there's divergeance, so you could do "pull, then commit" before you make your FIRST separate commit on mybranch, but it's not useful after. | 15:47 |
| fullermd | (someday, I'll train my fingers how to spell "divergence"...) | 15:48 |
| croepha | so, once head merges your branch, you throw away your branch and start with a new one | 15:48 |
| fullermd | If the job of that branch is done. Otherwise there's no reason not to keep running with it. | 15:49 |
| fullermd | You could also just 'pull' in that branch then (since head is a superset of what you have). Not much different than "rm -rf ; re-branch", but less running around the block to do it. | 15:49 |
| croepha | well, some times merges happen early, to get some partial new functionality | 15:49 |
| fullermd | You don't get a criss-cross _any_ time two branches merge each other, only in particular cases. | 15:50 |
| croepha | ahh | 15:50 |
| croepha | ok | 15:50 |
| fullermd | In the 2-branch case, it can be roughly expressed as "merging each other at the same time" | 15:50 |
| fullermd | e.g., I'm at rev 60, and you're at rev 70. I merge your 70 to make my 61, you merge my 60 to make your 71. Now we have a criss-cross. | 15:51 |
| croepha | ok, thanks a bunch | 15:51 |
| fullermd | If you merged my _61_, there wouldn't be a cross. | 15:51 |
| croepha | excellect | 15:52 |
| fullermd | (gets a little harder to describe, and more likely to happen, when you have 3 or 4 or 15 branches involved; it's a lot easier to get crosses that way) | 15:52 |
| croepha | it seems like you will have a bunch of commits in the log for head that dont actually contribute any changes to the head, but i can probably live with that | 15:52 |
| fullermd | But as long as you have a fairly hierarchical set of branches where you're not crossing the streams, it won't come up much. | 15:53 |
| fullermd | Well, they'll be in merge commits, so you won't see them in the mainline log unless you expand out the merges. | 15:53 |
| croepha | yea | 15:53 |
| fullermd | Just like in mybranch, you don't see the details of all the things in head in that merge unless you expand, you just see the 'merge head'. | 15:53 |
| fullermd | Of course, if the 90% of the commits in mybranch end up being "merge head"... but that's probably more a sign of your workflow screaming in pain. | 15:54 |
| croepha | eh, it will probably be 10% | 15:55 |
| croepha | Thansk for all the hellp, btw, i just want to mention, that bzr is awesome, im not sure why git is so popular…. I have tried to get non developers to use version control for graphics and web content, and git is very difficult to explain, but everyone in my org finds bzr pretty easy to use | 15:57 |
| fullermd | That's why I'm here instead of in #git 8-} | 15:57 |
| LeoNerd | I much prefer bzr. Mostly for monotonic integer revision numbers, and the fact I know it actually remembers renames | 15:58 |
| croepha | yea | 15:59 |
| fullermd | I find the CLI a lot less obnoxious. But if I had to pick one overriding reason, it'd be respecting and using the chirality of merges. | 15:59 |
| fullermd | I get the impression that git occasionally makes small steps in that direction. Maybe someday... | 16:00 |
| croepha | yep | 16:00 |
| croepha | i think that in the future there will be something that just watches a directory for changes and automatically makes commits, and then the user will occasionally label those commits | 16:01 |
| LeoNerd | Hellno | 16:02 |
| LeoNerd | I want it to commit -only- when I want it to | 16:02 |
| fullermd | I think that's called "VMS" ;p | 16:02 |
| croepha | i know that seems like a bad thing, but for non developers it would be a drop in vc solution | 16:02 |
| LeoNerd | The only -major- thing I miss from git is rebase -i but I'm sure there'll be a plugin somewhere with it... right? ;) | 16:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!