Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, 26 Jun 2008, Petr Baudis wrote:

> On Wed, Jun 25, 2008 at 04:38:22PM -0400, Theodore Tso wrote:
> > On Wed, Jun 25, 2008 at 04:04:47PM -0400, Avery Pennarun wrote:
> > > How about making "git checkout" default to HEAD if no revision is 
> > > supplied?  There's precedent for this in, say, git-diff (and I think 
> > > a few others).
> > > 
> > > Incidentally, "checkout <filename>" was also the way to do a revert 
> > > operation in CVS.  And the way to switch branches, too, iirc.  So 
> > > git isn't being too unusual here.  That said, the commands were 
> > > deliberately renamed in svn because CVS was considered largely 
> > > insane.
> > 
> > The one thing I would worry about is the potential ambiguity if you do 
> > something like "git checkout FOOBAR", and FOOBAR was both a branch 
> > name as well as a file name.  How should it be interpreted?  I'd argue 
> > the real problem was we conflated two distinct operations: "switching 
> > to a new branch", and "reverting a file" to the same name, checkout.
> > 
> > Hence the suggestion to add a new command, "git revert-file", where 
> > there would be no ambiguity.
> 
> Just to chime in, this reminds me of Cogito - it had cg-switch for
> switching branches (like git checkout) and cg-restore for restoring
> files in working copy (like git checkout, too; but you would pass -f if
> you wanted to overwrite existing copy).

Yeah, I was kinda disappointed that this part of Cogito never was picked 
up by Git "core".

I really liked the fact that Cogito was a test-bed for UI enhancements, 
and miss it a bit.  It was nice how it drove the UI enhancements of Git, 
and I am a little sad that Cogito was discontinued.  (And no, I do not see 
any contender picking up the task of driving Git's UI in the right 
direction.)
 
> (Though, Cogito didn't quite get it right either since it tried to 
> overload cg-switch with the git branch functionality of creating new 
> branches. I still didn't quite come in terms with any UI model of the 
> branches I know about.)

To the contrary, I think that "git branch --create <branch>" _should_ 
switch to the newly created branch.  That is what users expect, and Cogito 
got that right.

Ciao,
Dscho

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux