Re: git log -z doesn't separate commits with NULs

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 24, 2012, 20:03 UTC
Message-ID: <7vsji0xalg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120224095253.GC11846@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

>> DESCRIPTION
>> -----------
>> @@ -219,6 +220,12 @@ you can use `--suffix=-patch` to get
>> `0001-description-of-my-change-patch`.
>> range are always formatted as creation patches, independently
>> of this flag.
>> 
>> +[\--] <path>...::
>> + Put in patches only those modifications that affect specified files
>> + and folders. It's important to understand that log message of the
>> + commit may become inappropriate because some parts of patch may be
>> + cut off.
>> +
>
> I think that text looks OK. But to my mind, it is not that format-patch
> accepts a path parameter, but rather that it takes arbitrary log-like
> arguments.

The above text is not telling the entire truth, though.

When the command is run with the "--full-diff" option, seleted commits will be shown in full. This is useful for example when you want to pick commits that add a new "frotz" driver, which obviously needs to include "drivers/frotz/" subdirectory, without missing necessary changes to the Makefiles in the higher level (e.g. "drivers/Makefile"), e.g.

	git format-patch --full-diff v1.0..v1.1 -- drivers/frotz

In such a case, "some parts may be cut off" does not make the log message inappropriate.

On the other hand, people often do not use the resulting history of taking partial patches (i.e. without --full-diff) and feeding them to "am" as-is. The operation is used merely to give them a starting point for working on (possibly) an unrelated topic, and the history is further tweaked with "rebase -i" or even "commit --amend". It is not "inappropriate" that the log says more than what the patch does in such a use case. What the log says is irrelevant.

> I don't know how well tested every option is, though, so maybe it's not
> a good idea to encourage the use of random options.

I obviously agree and also suspect that the real question is not "how well tested" but "if it makes sense".

I am reasonably sure that over time the options and features that make sense in the context of producing something that is useful with "am" have been already made to work well, but I also am fairly certain that the coverage of the code to explicitly reject options that do not make sense in that context would be spotty at best. For example, did we carefully design and implement how format-patch should behave when "-z" is given, or does the code happen to do whatever it happens to do? If the latter, did we consider rejecting "-z" when given from the command line and implement such safety?