On Fri, 15 Apr 2005, Linus Torvalds wrote:
> On Fri, 15 Apr 2005, Daniel Barkalow wrote:
> >
> > Is there some reason you don't commit before merging? All of the current
> > merge theory seems to want to merge two commits, using the information git
> > keeps about them.
>
> Note that the 3-way merge would _only_ merge the committed state. The
> thing is, 99% of all merges end up touching files that I never touch
> myself (ie other architectures), so me being able to merge them even when
> _I_ am in the middle of something is a good thing.
>
> So even when I have dirty state, the "merge" would only merge the clean
> state. And then before the merge information is put back into my working
> directory, I'd do a "check-files" on the result, making sure that nothing
> that got changed by the merge isn't up-to-date.
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?
> > How much do you care about the situation where there is no best common
> > ancestor
>
> 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? I have the feeling that the former isn't going to be
useful, because there will be lines you're considering merging which go
back to ancient kernels, where they keep merging in your changes, but
they still have a lineage back to 2.6.0 or something.
For the latter, there are sometimes multiple ancestors which fit this
criterion, and different ones of them are most helpful for different
portions of the merge. I think this primarily happens when a branch you
want to merge has accepted multiple patches that you've also
accepted (and the history identifies this fact); this may or may not be a
situation you want to allow on a regular basis.
-Daniel
*This .sig left intentionally blank*
-
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
