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

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 28, 2005, 17:13 UTC
Message-ID: <Pine.LNX.4.58.0509281007200.3308@g5.osdl.org>
In-Reply-To: <7vek79w2ps.fsf@assigned-by-dhcp.cox.net>

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

Show 5 quoted lines

> 
> 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