Re: [PATCH] Use git-update-ref in scripts.

Linus Torvalds [off-list ref] writes:

On Wed, 28 Sep 2005, Junio C Hamano wrote:

quoted

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.

By 'diff before-hand' I take it to mean the savestate for later
rounds to keep the pre-merge state.  You are correct that it is
not done in a single strategy case, and 'git pull' by default
would use only one of Daniel's git-merge-resolve or in the
multi-remote case git-merge-octopus, depending on the number of
heads being merged.  BTW, I decided not to use diff, just in
case somebody has binary blob we cannot reproduce with diff and
patch.

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.

Hmph.  That sort of makes sense but to make the unconditional
simple case really fast it should use read-tree -m -u which
_would_ smudge if things do not go well, which implies you need
savestate before that which would make it slower -- wouldn't it?

I think using Daniel's git-merge-resolve and nothing else by
default would be equivalent of having that unconditional simple
case upfront.