Jakub Narebski wrote: > 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. > Even if you > can automate it somehow (I do wonder how Mercurial manages that), > there could be problem resolving conflicts, unless you happen to touch > different parts of file. This behaviour is by design in Mercurial. It's simple, and it works. I've never had a problem with resolving conflicts here, and I don't see why I ever would. >> And that, I feel, is a problem with Git. In some cases, you can't do >> things how you want -- you have to do things how Git wants. > > Please take into account the fact that when you were creating your > workflow to suit your situation you were "forced" to fit it to > Mercurial abilities and best practices. No wonder that it does not > fit Git-ish workflows. No, I came to the distributed world only recently, from Subversion. I choose to use clones over plain anonymous branching, over bookmarks, and over named branching because I prefer the approach. I can, of course, do "Git branching" in Mercurial very easily if I want (with Mercurial bookmarks). > 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. >> Another example of this is the lack of support for anonymous branching as >> part of a normal workflow in Git. Anonymous branching is very powerful and >> very simple. I use it all the time in Mercurial. > > 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. (Of course, you could also create a Mercurial bookmark at that point, and then you'd essentially have a "Git branch".) > Note that with Git by default pushing "matching" branches, you can > create private local-only branches. The have to have _some_ name > (even if it is 'foo/temp'), but I think that it makes them perhaps > more work to create, but easier to use (to switch branches)... and for > single anonymous branch you can always use "detached HEAD". >From what I read, detached heads are subject to garbage collection. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html