Thread (6 messages) flat view 6 messages, 2 authors, 2016-06-15

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

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:07

Possibly related (same subject, not in this thread)


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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help