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

From: Sam Vilain <sam@vilain.net>
Date: Oct 30, 2008, 17:44 UTC
Message-ID: <1225388666.19891.22.camel@maia.lan>
In-Reply-To: <20081030164357.GJ24098@artemis.corp>

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.