(Jonathan, sorry if you got this multiple times, it seems I forgot to Cc list)

On Mon, Oct 21, 2013 at 8:40 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> Should the git-diff(1) manpage get a note about this setting as
> well (perhaps in a new CONFIGURATION section)?

I'll add a reference to the documentation for the -O option at least.
That is how --check, --color, --dirstat and others do it, I guess that
could be moved to a CONFIGURATION section later?

> Should Documentation/technical/api-diff.txt be tweaked to mention that
> the options set by diff_setup() depend on configuration now?

It already did, didn't it? At least diff.context, diff.renames and
diff.color seems to affect diff_setup(), no?

> If a caller wants to parse diff config and also wants to make a diff
> without using the config (the example I'm imagining is an alternative
> implemention fo "git log -p --cherry-pick"), can they do that?  It's
> tempting to move handling of configuration into a separate function.
> (Perhaps it's not worth worrying about that until someone needs the
> flexibility, though.)

Right, patch-ids are not stable wrt ordering. That might be a problem
if some tool stores patch-ids. But maybe that even is a separate bug?
Should patch-id always reorder the files internally? Is it expected
that "git diff -Oorder1  | git patch-id" and "git diff -Oorder2 | git
patch-id" gives same patch id?

It gets very interesting in an imaginative "git log -p --cherry-pick"
which caches patch-ids on disk, one would want one stable ordering for
calculating the patchid, while the displayed patch should respect the
user requested order.

I guess that in most cases one would want to respect user configured
ordering. Should diff_setup grow an argument "ignore_config"? Or
should we maybe add an --no-order-file option that easily be set as a
flag in diff_options in those cases?

> Hope that helps,

It does. Thanks! I have updated patch as per your other comments.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to