Thread (1 message) 1 message, 1 author, 2016-06-15
  • (off-list ancestor, not in this archive)
  • Re: My patches · Junio C Hamano <hidden> · 2016-06-15

Re: My patches

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:59:02

Theodore Ts'o [off-list ref] writes:
Over the past 5+ years, I've observed that I
think the way commit selection in "git format-patch" is inconsistent
with how we handle commit selection for other commands, e.g., "git log
<commit>" vs and "git format-patch <commit>".  Even if you think that
this is a matter of self-inherent "truth", versus just a matter of
taste, there is also the consideration of backwards compatibility, and
the question of how important consistency and easy of learning gets
traded off against backwards compatibility and invalidating
potentially huge numbers of shell scripts and documentation.  So it's
not something where I've made a nuisance of myself, because it's a
settled issue.
The original syntax to select of commits by format-patch is very
inconsistent from the log family because it was done way before the
log family's way has been established as the best practice. It has
annoyed enough people that we spent effort to teach recent Git
to accept

	$ git format-patch master..next

as well.

So it indeed is a settled issue, but you are correct to point out
that we had to find a way to do so while still keeping the original
syntax working for people who have scripts and people who work from
random and stale documents we have not much control over updating.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help