On Wed, 28 Sep 2005, Junio C Hamano wrote:
Have you had a chance to look at the git-merge change to remove
the stupid clean-tree requirements? I have been planning to
inflict the 'use git-merge instead of git-resolve' change on you
sometime soonish (like today ;-).
I don't like doing the diff before-hand, but it looked like the default
was to try just one strategy, and avoid the diff in that case.
Actually, my preference would be to have a unconditional simple case
first. If there's only one possible base, and the trivial merge succeeds
(ie no three-way merges needed at all, just a single git-read-tree), do
that part unconditionally.
That actually matches 90% of all merges I do, and I'd be much happier with
git-merge if it did that first and if it then does something more complex
(including diffs etc) afterwards, I'm much less likely to worry.
Could I have a copy of .git/{branches,remotes,refs}/* from the
primary repository you do your kernel work please?
Heh. My kernel has none of that. Well, it obviously has refs, but even
there it literally has just one head: "master". The rest are the standard
tags you see in public.
So if you clone the public kernel,. you'll actually have a superset of
what I have, since you'll have the "origin" thing ;)
Linus