Re: [PATCH] Really fix git-merge-one-file-script this time.

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

quoted

Linus, have you decided to like or dislike the behaviour of
git-merge-one-file-script touching the work tree in some cases
but not in other cases?

LT> I don't care about the _successful_ merge, since a successful merge is 
LT> basically always followed by a "git-checkout-cache -f -a" anyway (and 
LT> update-cache + remove now-stale files etc).

Let me make sure I understand you correctly before I go
further.  In the above sentence, do you mean a merge that is
_successful_ by merges that:

    (1) "git-remove-tree -m" considers them trivial;

or
    (2) in addition to (1), "git-merge-one-file-script"
        considers them trivial.  That is, only one-side changes
        or removes or adds it, or both sides adds it
        identically, or merge/diff3 merges without conflict.

Which one?

LT> Sounds sane.

LT> On the other hand, I think it would actually be easier to just make your 
LT> "magic SHA1" be just another "stage".

I am undecided on this one but having worked on the diff side, I
think the magic SHA1 of 0{40} would match better with what diff
needs to do.  It would mean "cache is stale, look in the work
tree" to them.

On Sun, 1 May 2005, Junio C Hamano wrote:

Let me make sure I understand you correctly before I go
further.  In the above sentence, do you mean a merge that is
_successful_ by merges that:

    (1) "git-remove-tree -m" considers them trivial;

or
    (2) in addition to (1), "git-merge-one-file-script"
        considers them trivial.  That is, only one-side changes
        or removes or adds it, or both sides adds it
        identically, or merge/diff3 merges without conflict.

(2).

But in the more general case _any_ automated merge is the "uninteresting" 
case (except for the fact that we hope for them ;)

In other words, I want this case really designed for the situation where 
automation (_any_ kind) breaks down. 

			Linus