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

From: Andreas Ericsson <ae@op5.se>
Date: Oct 30, 2008, 15:02 UTC
Message-ID: <4909CC85.1080803@op5.se>
In-Reply-To: <20081030143918.GB14744@mit.edu>

Theodore Tso wrote:

Show 22 quoted lines

> On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
>> From: Sam Vilain <samv@vilain.net>
>>
>> For cross-command CLI changes to be effective, they need to be
>> cohesively planned.  Add a planning document for this next set of
>> changes.
> 
> Here are my favorites:
> 
> * Add the command "git revert-file <files>" which is syntactic sugar for:
> 
>         git checkout HEAD -- <files>
> 
>   Rationale: Many other SCM's have a way of undoing local edits to a
>   file very simply, i.e."hg revert <file>" or "svn revert <file>", and
>   for many developers's workflow, it's useful to be able to undo local
>   edits to a single file, but not to everything else in the working
>   directory.  And "git checkout HEAD -- <file>" is rather cumbersome
>   to type, and many beginning users don't find it intuitive to look in
>   the "git-checkout" man page for instructions on how to revert a
>   local file.
>

I like it, although I guess one would have to add a "--staged" flag to git revert-file to be able to checkout files from index as well, or people will wonder why that can't be done.

Show 11 quoted lines

> * Change the argument handling for "git format-patch" so it is
>   consistent with everything else which takes a set of commits.  Yes,
>   it means that where people have gotten used to typing "git
>   format-patch origin", they'll have to type instead: "git
>   format-patch origin..", but's much more consistent.  We've done the
>   best we can by documenting the existing behavior, but if'we re going
>   to make major, potentially incompatible, CLI changes, this is
>   something to at least consider.  Maybe with a config file for people
>   who really don't want to retrain their fingers to type the two extra
>   periods?
>

"git format-patch" does exactly the same thing as other commit-range handling commands do, which is assume that the missing commit end-point is HEAD, so it actually is consistent, although it doesn't quite look as if it is.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231