Re: Salvaging borked project history

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Salvaging borked project history

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:03:56

Mason [off-list ref] writes:
quoted
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.
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".

Re: Salvaging borked project history

From: Mason <hidden>
Date: 2016-06-15 23:03:56

Junio C Hamano wrote:
Mason wrote:
quoted
I was planning to write 'git diff -q commit^ commit'
to test for empty commits.
s/-q/--quiet/ and all is well, no?
Doh! I've no idea how I missed these...

--exit-code
  Make the program exit with codes similar to diff(1). That is, it
  exits with 1 if there were differences and 0 means no differences.

--quiet
  Disable all output of the program. Implies --exit-code.

Thanks for walking me through it.

Regards.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help