On Thu, Oct 30, 2008 at 02:39:18PM +0000, 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. This is what is currently proposed for undo, but yeah, revert-file or maybe rather revert-changes may be suitable. > * 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 origin/next.. works already. I'm used to the asymetric git format-patch origin/next syntax, and I would be sorry if it disappeared though, and I see no really good reason to get rid of it. -- ·O· Pierre Habouzit ··O madcoder@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgpIdLamWMD2O.pgp
Description: PGP signature
