On Fri, 15 Apr 2005, Daniel Barkalow wrote:
>
> So you want to merge someone else's tree into your committed state, and
> then merge the result with your working directory to get the working
> directory you continue with, provided that the second merge is trivial?
No, you don't even "merge" the working directory.
The low-level tools should entirely ignore the working directory. To a
low-level merge, the working directory doesn't even exist. It just gets
three commits (or trees) and merges two of them with the third as a
parent, and does all of it in it's own temporary "merge working
directory".
So on a technical level, the "plumbing" part really really doesn't care at
all.
However, from a _usability_ part, you expect after a merge that your
working directory has been updated to be the merged tree. And that's where
the "if I have a working tree that is dirty, I want that part to fail"
comes in. In other words, the final phase (after the "tree-merge" has
actually successfully already finished) is to go back to the working
directory, and check out the merged results.
But that checkout would be a variation on "checkout-cache -a" which first
checks that none of the files it is going to overwrite are dirty.
Don't worry about this part. It's really totally separate from the true
merge itself. The "real work" has already been done by the time we notice
that "oops, we can't actually show him the newly merged tree, because he
has got dirty data where we want to show it".
> > I care. Even if the best common parent is 3 months ago, I care. I'd much
> > rather get a big explicit conflict than a "clean merge" that ends up being
> > debatable because people played games with per-file merging or something
> > questionable like that.
>
> Are you thinking that the best common ancestor is the one that ties up
> absolutely all of the chains of commits, or the closest one that the sides
> have in common?
The closest common one.
> For the latter, there are sometimes multiple ancestors which fit this
> criterion
Yes. Let's just pick one at random (or more likely, the latest one by
date - let's not actually be _random_ random) at first.
There are other heuristics we can try, ie if it turns out that it's common
to have a couple of alternatives (but no more than some small number, say
five or so), we can literally just -try- to do a tree-only merge, and see
how many lines out common output you get from "diff-tree".
Because that "how mnay files do we need to merge" is the number you want
to minimize, and doing a couple of extra "diff-tree" + "join" operations
should be so fast that nobody will notice that we actually tried five
different merges to see which one looked the best.
But hey, especially if the merge fails with real clashes (ie there are
changes in common and running "merge" leaves conflicts), and there were
other alternate parents to choose, there's nothing wrong with just
printing them out and saying "you might try to specify one of these
manually".
I really don't think we should worry too much about this until we've
actually used the system for a while and seen what it does. So just start
with "nearest common parent with most recent date". Which I think you
already implemented, no?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
