Theodore Tso wrote:
On Wed, Oct 29, 2008 at 08:48:05PM -0700, Sam Vilain wrote:
From: Sam Vilain <samv@xxxxxxxxxx>
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.
* 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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
