Thread (36 messages) flat view 36 messages, 15 authors, 2016-08-13

Re: [PATCH] Documentation: add a planning document for the next CLI revamp

From: Sam Vilain <hidden>
Date: 2016-06-15 22:45:33

On Thu, 2008-10-30 at 17:43 +0100, Pierre Habouzit wrote:
In fact I believe that what we lack is a shorthand for:

$sha1^..$sha1 because that would solve both of your issues, and it's
something that has bothered me in the past too for other commands.
There is already a shorthand for that;

  $sha1^!

Indeed passing that to git-format-patch has the intended effect; it
causes it to save a patch for just the commit in question.

I agree that it would make more sense for the current behaviour to be
changed;

  git format-patch origin/master..

Isn't that much more to type than:

  git format-patch origin/master

And it makes the case where you just want to format a single patch work
better.

However, I worry about the backwards incompatibility.  The other changes
I listed didn't really violate existing expectations.

That being said, the case where a single commit reference is passed,
with no range, should be relatively easy to detect.  In this situation
it could return an error, and encourage the user to use "--since" or
"--only"; or to configure one of those to be the default.

I'm wondering whether it's worth building some kind of mechanism to
notice that settings like this have not been set, and to print a warning
like "warning: you are using a git that introduced minor command
changes; use 'git config --new' to pick your defaults" - that way,
changes to command operation could be introduced that would not annoy
older users so much.

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