Re: More Beginning Git Questions
- From
- tactical <a5158017@nepwk.com>
- Date
- Sep 25, 2011, 21:07 UTC
- Message-ID
- <1ttmqsxtaj98i$.hv6s5shjeugr.dlg@40tude.net>
- In-Reply-To
- <m3oby8pcfz.fsf@localhost.localdomain>
Jakub Narebski wrote:
Show 13 quoted lines
>>> With merging into branch with uncomitted changes your fairly well >>> understood 3-way merge (sometimes virtual 3-way merge in the case of >>> multiple common ancestors) would turn into 4-way merge. >> >> I don't see why it would be a four-way merge rather than a three-way merge. > > You have four version: "base" (ancestor version), "theirs" > (branch/clone being merged), "ours" (comitted changes on current > branch) and "new" (uncomitted changes on current branch). > > Unless Mercurial does 3-way merge of "new", "theirs" and "base"... > with transaction based atomicity (saving "new" before attempting > merge) they can do that.
I've not read the code, but surely Mercurial does a three-way merge here. It wouldn't be sane to do anything else.
Show 9 quoted lines
>>> What you use uncomitted changes for, I would use is a separate branch, >>> and keep it rebasing (something like using 'mq' in Mercurial). >> >> Yes, but, as I mentioned, rebasing is less flexible. A rebase here is >> effectively a merge and a commit in one step, whereas my approach separates >> the merge and the commit. > > Errr... what? You first commit your changes, then keep it rebasing to > keep them up to date on top of fresh version.
Like I said before, with my approach, after I merge, I can check that everything still compiles, that unit tests still pass, and so on, before finally checking in. Rebasing, on the other hand, is essentially merging and checking in in one step. *After* you've rebased, you can run unit tests, etc., but you've *already* checked in at that point. (Sure, you could then mutate history if need be, but it's rather less flexible than my approach, where the check-in is not made until desired.)
Show 11 quoted lines
>>> What do you use anonymous branching for? >> >> Anonymous branching is great for minor divergence that isn't really >> significant enough to deserve a name. It's also great for branches that >> *are* significant enough to deserve a name, but where you want to defer >> naming the branch right up until you merge it into another branch. At that >> point you can 'name' the branch in the commit message. > > I think you can use detached HEAD for that, at least when working on > one issue at a time (you have to name branch when switching to some > other work).
But in Mercurial I can switch between anonymous branches as much as I like without anything ever being deleted.
Show 5 quoted lines
>> From what I read, detached heads are subject to garbage collection. > > No, HEAD is protected against garbage collecting. To be sure you > should name a branch when switching branches, though reflog would > protect you for 30 days (by default) even if you don't do that.
So Git doesn't really support anonymous branching as part of a normal workflow.