Re: Salvaging borked project history

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 26, 2015, 21:28 UTC
Message-ID: <xmqqioeol5v4.fsf@gitster.dls.corp.google.com>
In-Reply-To: <54EF814D.1020105@free.fr>

Mason <slash.tmp@free.fr> writes:

Show 8 quoted lines

>> Not just passing
>> these options, the code in "git am" to react to the result of patch
>> application to avoid the issue you observed when these options are
>> passed need to be adjusted by changes that started passing them, but
>> I do not think they did, cf. 77e9e496 (am: pass exclude down to
>> apply, 2011-08-03).
>
> Sorry, I could not parse that paragraph :-)

Heh, paraphrasing.

77e9e496 and others tried to teach --exclude/--include to "git am". For "git am" to be able to claim that these options are properly supported, you need two things:

 - The options can be given from the command line and they are
   passed to the underlying "git apply", instead of complaining with
   "no such option".

 - After calling "git mailsplit", "git mailinfo", and "git apply"
   and then these helper programs return, "git am" needs to inspect
   what happened and react.  The patch application may have failed
   due to conflicts, in which case it may have to ask the user to
   resolve.  A patch application may have resulted in no-change,
   which often is a sign that there is something wrong and "am"
   would want to stop and ask the user for confirmation.  If use of
   --include/--exclude introduces a new failure mode (e.g. mailsplit
   and mailinfo may find a patch text and happy without complaint,
   but passing --exclude to apply may cause the remaining patch to
   become essentially empty, which never happens before "am" started
   accepting these options), that codepath needs to be updated to
   cope with the new failure mode it has introduced.

And I think 77e9e496 and the other one that added --include only did the former without doing the latter.

Show 6 quoted lines

> Here is the use-case:
>
> if diff -q A B; then do_X; else do_Y; fi
> ...
> I was planning to write 'git diff -q commit^ commit'
> to test for empty commits.

s/-q/--quiet/ and all is well, no?

"git diff --quiet" doesn't abbreviate down to "git diff -q" primarily because "-q" for the underlying "git diff-files" means something different from "--quiet".