{"thread":{"id":"12820","subject":"What I miss from Cogito...","startedAt":"2008-03-23T17:15:48Z","lastAt":"2008-03-27T02:36:54Z","messageCount":23,"participants":["H. Peter Anvin","Theodore Tso","Luciano Rocha","Johannes Schindelin","Junio C Hamano","Mike Hommey","Bruce Stephens","Florian Weimer","Daniel Barkalow","Björn Steinbrink","Julian Phillips","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72779","messageId":"47E69044.3000207@zytor.com","threadId":"12820","inReplyTo":null,"subject":"What I miss from Cogito...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-03-23T17:15:48Z","receivedAt":"2008-03-23T17:15:48Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"This much later, there are a few minor things I still miss from Cogito. \n I believe fixing either would be quite trivial, so I thought I'd post \na note.\n\n1. The ability to clone into the current directory\n\n cg-clone had a -c option, which allowed cloning into the current\n directory. This is particularly useful, since I keep my common\n dot files in a git repository, so all I need to do to set up a new\n machine is to clone that git repository over my empty home directory.\n\n Native git doesn't have any equivalent, other than:\n\n git clone -n .... tmp\n mv tmp/.git .\n rm -rf tmp\n git checkout HEAD\n\n\n2. cg-restore\n\n Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n issue, but having to type \"git reset --hard -- path\" makes me\n nervous, especially since hitting Enter at the wrong time could have\n serious and irrevocable consequences.\n\n I also note that this particular use of \"git reset\" is actually\n undocumented, but it seems to work.\n\n\nThose are pretty much the only Cogito command I have found myself either \nmissing or using since I made a mental note to track this stuff, a few \nmonths ago.\n\n\t-hpa\n"},{"id":"72784","messageId":"20080323173841.GA24943@mit.edu","threadId":"12820","inReplyTo":"47E69044.3000207@zytor.com","subject":"Re: What I miss from Cogito...","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-03-23T17:38:41Z","receivedAt":"2008-03-23T17:38:41Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:\n> 2. cg-restore\n>\n> Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n> issue, but having to type \"git reset --hard -- path\" makes me\n> nervous, especially since hitting Enter at the wrong time could have\n> serious and irrevocable consequences.\n>\n> I also note that this particular use of \"git reset\" is actually\n> undocumented, but it seems to work.\n\nI didn't think \"git reset --hard -- \" was valid, since it's\nnot documented in the man page.\n\nI have the following in my path as \"git-revert-file\" (which is easier\nto type and less dangerous than typing \"git reset --hard -- \"):\n\n#!/bin/sh\n#\nprefix=$(git rev-parse --show-prefix)\n\nfor i in $*\ndo\n git show HEAD:$prefix$i > $i\ndone\n\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"72785","messageId":"47E6978C.4040207@zytor.com","threadId":"12820","inReplyTo":"20080323173841.GA24943@mit.edu","subject":"Re: What I miss from Cogito...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-03-23T17:46:52Z","receivedAt":"2008-03-23T17:46:52Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Theodore Tso wrote:\n> On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:\n>> 2. cg-restore\n>>\n>> Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n>> issue, but having to type \"git reset --hard -- path\" makes me\n>> nervous, especially since hitting Enter at the wrong time could have\n>> serious and irrevocable consequences.\n>>\n>> I also note that this particular use of \"git reset\" is actually\n>> undocumented, but it seems to work.\n> \n> I didn't think \"git reset --hard -- \" was valid, since it's\n> not documented in the man page.\n> \n> I have the following in my path as \"git-revert-file\" (which is easier\n> to type and less dangerous than typing \"git reset --hard -- \"):\n> \n> #!/bin/sh\n> #\n> prefix=$(git rev-parse --show-prefix)\n> \n> for i in $*\n> do\n> git show HEAD:$prefix$i > $i\n> done\n> \n\nFWIW, cg-restore is a 131-line shell script, so one can assume it's not \njust doing it for fun.\n\n\t-hpa\n"},{"id":"72786","messageId":"20080323182102.GA22551@bit.office.eurotux.com","threadId":"12820","inReplyTo":"20080323173841.GA24943@mit.edu","subject":"Re: What I miss from Cogito...","fromName":"Luciano Rocha","fromEmail":"luciano@eurotux.com","sentAt":"2008-03-23T18:21:02Z","receivedAt":"2008-03-23T18:21:02Z","isPatch":false,"sender":{"key":"luciano@eurotux.com","avatar":null},"body":"On Sun, Mar 23, 2008 at 01:38:41PM -0400, Theodore Tso wrote:\n> On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:\n> > 2. cg-restore\n> >\n> > Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n> > issue, but having to type \"git reset --hard -- path\" makes me\n> > nervous, especially since hitting Enter at the wrong time could have\n> > serious and irrevocable consequences.\n> >\n> > I also note that this particular use of \"git reset\" is actually\n> > undocumented, but it seems to work.\n> \n> I didn't think \"git reset --hard -- \" was valid, since it's\n> not documented in the man page.\n> \n> I have the following in my path as \"git-revert-file\" (which is easier\n> to type and less dangerous than typing \"git reset --hard -- \"):\n> \n> #!/bin/sh\n> #\n> prefix=$(git rev-parse --show-prefix)\n> \n> for i in $*\n> do\n> git show HEAD:$prefix$i > $i\n> done\n\nI use git checkout path ...\n\nIsn't that the same thing?\n\n-- \nLuciano Rocha \nEurotux Informática, S.A. \n"},{"id":"72790","messageId":"alpine.LSU.1.00.0803231930280.4353@racer.site","threadId":"12820","inReplyTo":"47E69044.3000207@zytor.com","subject":"Re: What I miss from Cogito...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T18:31:54Z","receivedAt":"2008-03-23T18:31:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, H. Peter Anvin wrote:\n\n> 1. The ability to clone into the current directory\n> \n> cg-clone had a -c option, which allowed cloning into the current\n> directory. This is particularly useful, since I keep my common\n> dot files in a git repository, so all I need to do to set up a new\n> machine is to clone that git repository over my empty home directory.\n> \n> Native git doesn't have any equivalent, other than:\n> \n> git clone -n .... tmp\n> mv tmp/.git .\n> rm -rf tmp\n> git checkout HEAD\n\nWell, it has:\n\n\t$ git init\n\t$ git remote add -f origin \n\t$ git checkout -b master origin/master\n\nIf you really want to track /etc with Git, you can do that easily, and you \ncan easily take the flak for a not-so-popular workflow.\n\nCiao,\nDscho\n"},{"id":"72792","messageId":"7vzlsp5ly8.fsf@gitster.siamese.dyndns.org","threadId":"12820","inReplyTo":"47E69044.3000207@zytor.com","subject":"Re: What I miss from Cogito...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-23T18:34:07Z","receivedAt":"2008-03-23T18:34:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Native git doesn't have any equivalent, other than:\n>\n> git clone -n .... tmp\n> mv tmp/.git .\n> rm -rf tmp\n> git checkout HEAD\n\nOr\n\n\tgit init\n git add remote -f .....\n\n\n>\n> 2. cg-restore\n>\n> Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n> issue, but having to type \"git reset --hard -- path\" makes me\n> nervous, especially since hitting Enter at the wrong time could have\n> serious and irrevocable consequences.\n\nWhy --hard?\n"},{"id":"72794","messageId":"47E6A850.5060308@zytor.com","threadId":"12820","inReplyTo":"7vzlsp5ly8.fsf@gitster.siamese.dyndns.org","subject":"Re: What I miss from Cogito...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-03-23T18:58:24Z","receivedAt":"2008-03-23T18:58:24Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \"H. Peter Anvin\" writes:\n> \n>> Native git doesn't have any equivalent, other than:\n>>\n>> git clone -n .... tmp\n>> mv tmp/.git .\n>> rm -rf tmp\n>> git checkout HEAD\n> \n> Or\n> \n> \tgit init\n> git add remote -f .....\n> \n>> 2. cg-restore\n>>\n>> Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n>> issue, but having to type \"git reset --hard -- path\" makes me\n>> nervous, especially since hitting Enter at the wrong time could have\n>> serious and irrevocable consequences.\n> \n> Why --hard?\n\nTo make it actually change the file in the working directory (equivalent \nto the -f option in cg-restore.)\n\n\t-hpa\n"},{"id":"72795","messageId":"7vtzix5kr7.fsf@gitster.siamese.dyndns.org","threadId":"12820","inReplyTo":"47E6A850.5060308@zytor.com","subject":"Re: What I miss from Cogito...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-23T18:59:56Z","receivedAt":"2008-03-23T18:59:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Junio C Hamano wrote:\n> ...\n>>> 2. cg-restore\n>>>\n>>> Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n>>> issue, but having to type \"git reset --hard -- path\" makes me\n>>> nervous, especially since hitting Enter at the wrong time could have\n>>> serious and irrevocable consequences.\n>>\n>> Why --hard?\n>\n> To make it actually change the file in the working directory\n> (equivalent to the -f option in cg-restore.)\n\nThen \"git checkout HEAD -- path\"?\n"},{"id":"72796","messageId":"20080323190017.GB16893@glandium.org","threadId":"12820","inReplyTo":"20080323182102.GA22551@bit.office.eurotux.com","subject":"Re: What I miss from Cogito...","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-03-23T19:00:17Z","receivedAt":"2008-03-23T19:00:17Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sun, Mar 23, 2008 at 06:21:02PM +0000, Luciano Rocha wrote:\n> On Sun, Mar 23, 2008 at 01:38:41PM -0400, Theodore Tso wrote:\n> > On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:\n> > > 2. cg-restore\n> > >\n> > > Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n> > > issue, but having to type \"git reset --hard -- path\" makes me\n> > > nervous, especially since hitting Enter at the wrong time could have\n> > > serious and irrevocable consequences.\n> > >\n> > > I also note that this particular use of \"git reset\" is actually\n> > > undocumented, but it seems to work.\n> > \n> > I didn't think \"git reset --hard -- \" was valid, since it's\n> > not documented in the man page.\n> > \n> > I have the following in my path as \"git-revert-file\" (which is easier\n> > to type and less dangerous than typing \"git reset --hard -- \"):\n> > \n> > #!/bin/sh\n> > #\n> > prefix=$(git rev-parse --show-prefix)\n> > \n> > for i in $*\n> > do\n> > git show HEAD:$prefix$i > $i\n> > done\n> \n> I use git checkout path ...\n> \n> Isn't that the same thing?\n\nYes, it does the same. Note there is unfortunately no shorthand for\ngit show $arbitrary_commit:$path > $path\n\nMike\n"},{"id":"72798","messageId":"80eja1uumg.fsf@tiny.isode.net","threadId":"12820","inReplyTo":"20080323190017.GB16893@glandium.org","subject":"Re: What I miss from Cogito...","fromName":"Bruce Stephens","fromEmail":"bruce.stephens@isode.com","sentAt":"2008-03-23T19:07:35Z","receivedAt":"2008-03-23T19:07:35Z","isPatch":false,"sender":{"key":"bruce.stephens@isode.com","avatar":null},"body":"Mike Hommey writes:\n\n> On Sun, Mar 23, 2008 at 06:21:02PM +0000, Luciano Rocha wrote:\n\n[...]\n\n>> I use git checkout path ...\n>> \n>> Isn't that the same thing?\n>\n> Yes, it does the same. Note there is unfortunately no shorthand for\n> git show $arbitrary_commit:$path > $path\n\nIsn't that what \n\n git checkout $arbitrary_commit -- $path\n\ndoes?\n"},{"id":"72799","messageId":"20080323190740.GA17958@glandium.org","threadId":"12820","inReplyTo":"20080323190017.GB16893@glandium.org","subject":"Re: What I miss from Cogito...","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-03-23T19:07:40Z","receivedAt":"2008-03-23T19:07:40Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sun, Mar 23, 2008 at 08:00:17PM +0100, Mike Hommey wrote:\n> On Sun, Mar 23, 2008 at 06:21:02PM +0000, Luciano Rocha wrote:\n> > On Sun, Mar 23, 2008 at 01:38:41PM -0400, Theodore Tso wrote:\n> > > On Sun, Mar 23, 2008 at 10:15:48AM -0700, H. Peter Anvin wrote:\n> > > > 2. cg-restore\n> > > >\n> > > > Cogito separated \"reset\" and \"restore\". This is a syntactic sugar\n> > > > issue, but having to type \"git reset --hard -- path\" makes me\n> > > > nervous, especially since hitting Enter at the wrong time could have\n> > > > serious and irrevocable consequences.\n> > > >\n> > > > I also note that this particular use of \"git reset\" is actually\n> > > > undocumented, but it seems to work.\n> > > \n> > > I didn't think \"git reset --hard -- \" was valid, since it's\n> > > not documented in the man page.\n> > > \n> > > I have the following in my path as \"git-revert-file\" (which is easier\n> > > to type and less dangerous than typing \"git reset --hard -- \"):\n> > > \n> > > #!/bin/sh\n> > > #\n> > > prefix=$(git rev-parse --show-prefix)\n> > > \n> > > for i in $*\n> > > do\n> > > git show HEAD:$prefix$i > $i\n> > > done\n> > \n> > I use git checkout path ...\n> > \n> > Isn't that the same thing?\n> \n> Yes, it does the same. Note there is unfortunately no shorthand for\n> git show $arbitrary_commit:$path > $path\n\nActually, git checkout $arbitrary_commit -- $path works (and puts the\ncontents in the index). Somehow, I thought it didn't work...\n\nMike\n"},{"id":"72800","messageId":"87r6e1b6c8.fsf@mid.deneb.enyo.de","threadId":"12820","inReplyTo":"20080323182102.GA22551@bit.office.eurotux.com","subject":"Re: What I miss from Cogito...","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2008-03-23T19:14:47Z","receivedAt":"2008-03-23T19:14:47Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Luciano Rocha:\n\n>> git show HEAD:$prefix$i > $i\n\n> I use git checkout path ...\n>\n> Isn't that the same thing?\n\nNo, it restores the file version in the index. \"git checkout HEAD --\n$path\" should be the same.\n\nPersonally, I'm not all that happy with the multiple different meanings\nof \"git reset\" and \"git checkout\", either. Depending on the parameters,\nthe two comments manipulate both the contents of the working copy, or\nthe location at which the working copy is hooked in the history. If we\nneed to have two separate commands for this, it would make more sense to\ndraw distinction between the two aspects, and not the mess we have now.\nOTOH, it's probably too late for that.\n"},{"id":"72801","messageId":"alpine.LNX.1.00.0803231509060.19665@iabervon.org","threadId":"12820","inReplyTo":"47E69044.3000207@zytor.com","subject":"Re: What I miss from Cogito...","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-03-23T19:16:15Z","receivedAt":"2008-03-23T19:16:15Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 23 Mar 2008, H. Peter Anvin wrote:\n\n> This much later, there are a few minor things I still miss from Cogito. I\n> believe fixing either would be quite trivial, so I thought I'd post a note.\n> \n> 1. The ability to clone into the current directory\n> \n> cg-clone had a -c option, which allowed cloning into the current\n> directory. This is particularly useful, since I keep my common\n> dot files in a git repository, so all I need to do to set up a new\n> machine is to clone that git repository over my empty home directory.\n> \n> Native git doesn't have any equivalent, other than:\n> \n> git clone -n .... tmp\n> mv tmp/.git .\n> rm -rf tmp\n> git checkout HEAD\n\nMaybe \"git --work-tree=. clone \"? It currently complains about the \ndirectory existing, but we could have a flag to override that. And this \nends up with a sort of neat arrangement where your home directory is \"Not \na git repository\", but if you go into the subdirectory that has the repo \nfiles, you can do all the usual stuff. This helps to avoid the case where \nyou forget to do \"git init\" in a new project and accidentally check things \ninto your dotfiles.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"72802","messageId":"47E6AD48.7090507@zytor.com","threadId":"12820","inReplyTo":"alpine.LNX.1.00.0803231509060.19665@iabervon.org","subject":"Re: What I miss from Cogito...","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-03-23T19:19:36Z","receivedAt":"2008-03-23T19:19:36Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Daniel Barkalow wrote:\n> \n> Maybe \"git --work-tree=. clone \"? It currently complains about the \n> directory existing, but we could have a flag to override that. And this \n> ends up with a sort of neat arrangement where your home directory is \"Not \n> a git repository\", but if you go into the subdirectory that has the repo \n> files, you can do all the usual stuff. This helps to avoid the case where \n> you forget to do \"git init\" in a new project and accidentally check things \n> into your dotfiles.\n> \n> \t-Daniel\n\nThat sounds cumbersome.\n\n\t-hpa\n"},{"id":"72833","messageId":"20080324001617.GB24943@mit.edu","threadId":"12820","inReplyTo":"87r6e1b6c8.fsf@mid.deneb.enyo.de","subject":"Re: What I miss from Cogito...","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-03-24T00:16:17Z","receivedAt":"2008-03-24T00:16:17Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Mar 23, 2008 at 08:14:47PM +0100, Florian Weimer wrote:\n> \n> Personally, I'm not all that happy with the multiple different meanings\n> of \"git reset\" and \"git checkout\", either. Depending on the parameters,\n> the two comments manipulate both the contents of the working copy, or\n> the location at which the working copy is hooked in the history. If we\n> need to have two separate commands for this, it would make more sense to\n> draw distinction between the two aspects, and not the mess we have now.\n> OTOH, it's probably too late for that.\n\nYeah, it's not at all intuitive. I've been using git for quite some\ntime and had *absolutely* *no* *idea* that \"git checkout --\npath\" did what \"bk revert\" and \"hg revert\" does. In fact, I'm pretty\nsure I remember asking for this functionality a while back, and being\ntold the right answer was \"git show HEAD:pathname > pathname\", and I\nkept on typing it until I got sick and tired of it, and so I created\nmy short-hand shell script. \n\nAnd the fact that Peter was using \"git reset --hard -- pathname\" is\nanother hint that it isn't at *all* obvious that \"git checkout\" does\ntwo completely different things, and it's not something that you're\nlikely to intuit from the name or looking at the top-level git man\npage (where the summary in the top-level git manpage is, \"checkout and\nswitch to a branch\").\n\nIf we were going to separate the two commands out, I'd use the name\n\"git revert-file\", because that's what people who are coming from bk\nor hg are used to (where \"revert\" means to undo the local edits done\nto a particular file, as opposed to the git meaning of undoing a\nparticular commit).\n\n\t\t\t\t\t\t- Ted\n"},{"id":"72840","messageId":"20080324014030.GA24695@atjola.homenet","threadId":"12820","inReplyTo":"20080324001617.GB24943@mit.edu","subject":"Re: What I miss from Cogito...","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-03-24T01:40:30Z","receivedAt":"2008-03-24T01:40:30Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.03.23 20:16:17 -0400, Theodore Tso wrote:\n> On Sun, Mar 23, 2008 at 08:14:47PM +0100, Florian Weimer wrote:\n> > \n> > Personally, I'm not all that happy with the multiple different meanings\n> > of \"git reset\" and \"git checkout\", either. Depending on the parameters,\n> > the two comments manipulate both the contents of the working copy, or\n> > the location at which the working copy is hooked in the history. If we\n> > need to have two separate commands for this, it would make more sense to\n> > draw distinction between the two aspects, and not the mess we have now.\n> > OTOH, it's probably too late for that.\n> \n> Yeah, it's not at all intuitive. I've been using git for quite some\n> time and had *absolutely* *no* *idea* that \"git checkout --\n> path\" did what \"bk revert\" and \"hg revert\" does. In fact, I'm pretty\n> sure I remember asking for this functionality a while back, and being\n> told the right answer was \"git show HEAD:pathname > pathname\", and I\n> kept on typing it until I got sick and tired of it, and so I created\n> my short-hand shell script.\n\nThere is a difference between \"checkout HEAD -- $file\" and \"show\nHEAD:$file > $file\". The former will also update the index, while the\nlatter does not. Maybe you asked for not updating the index back then?\nJust guessing...\n\n> And the fact that Peter was using \"git reset --hard -- pathname\" is\n> another hint that it isn't at *all* obvious that \"git checkout\" does\n> two completely different things, and it's not something that you're\n> likely to intuit from the name or looking at the top-level git man\n> page (where the summary in the top-level git manpage is, \"checkout and\n> switch to a branch\").\n\nMaybe it's just a misunderstanding on my side, but to me \"checkout\"\nmeans as much as \"get me something out of the repo\". And git checkout\ndoes exactly that. It can get you a branch (naturally switching your\nHEAD to it), or it can get you trees or blobs. The latter can come from\neither the index (default) or from a specific treeish. To say that you\nwant to revert your local changes is just the same as saying that you\nwant the file as it is in HEAD. And that's what git checkout gives you,\nwithout introducing an extra command for that one special case.\n\n> If we were going to separate the two commands out, I'd use the name\n> \"git revert-file\", because that's what people who are coming from bk\n> or hg are used to (where \"revert\" means to undo the local edits done\n> to a particular file, as opposed to the git meaning of undoing a\n> particular commit).\n\nNah, that would create confusion within git, because it does something\ntotally different from git revert. And checkout can also checkout a\nwhole tree, not just a file. So you would either need revert-tree as\nwell... Or add more confusion, because revert-file \"reverting\" a tree is\nnot quite intuitive.\n\nBjörn\n"},{"id":"72847","messageId":"20080324021411.GE24943@mit.edu","threadId":"12820","inReplyTo":"20080324014030.GA24695@atjola.homenet","subject":"Re: What I miss from Cogito...","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-03-24T02:14:11Z","receivedAt":"2008-03-24T02:14:11Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Mar 24, 2008 at 02:40:30AM +0100, Björn Steinbrink wrote:\n> > If we were going to separate the two commands out, I'd use the name\n> > \"git revert-file\", because that's what people who are coming from bk\n> > or hg are used to (where \"revert\" means to undo the local edits done\n> > to a particular file, as opposed to the git meaning of undoing a\n> > particular commit).\n> \n> Nah, that would create confusion within git, because it does something\n> totally different from git revert. And checkout can also checkout a\n> whole tree, not just a file. So you would either need revert-tree as\n> well... Or add more confusion, because revert-file \"reverting\" a tree is\n> not quite intuitive.\n\nThat's why I said \"git revert-file\" as being different from \"git\nrevert\". If you want to revert the entire tree in the sense of\n\"undoing local edits\", most people today use \"git reset --hard\".\n\n> Maybe it's just a misunderstanding on my side, but to me \"checkout\"\n> means as much as \"get me something out of the repo\". \n\nIf that's true, why is the one-line summary in the git-checkout man\npage and in the git top-level man page read as follows?\n\n git-checkout - Checkout and switch to a branch\n\nAt the very least, will you admit that the summary in the man page is\nperhaps just a wee bit misleading?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"72849","messageId":"7vtziw3k9a.fsf@gitster.siamese.dyndns.org","threadId":"12820","inReplyTo":"20080324021411.GE24943@mit.edu","subject":"Re: What I miss from Cogito...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-24T02:53:37Z","receivedAt":"2008-03-24T02:53:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> git-checkout - Checkout and switch to a branch\n>\n> At the very least, will you admit that the summary in the man page is\n> perhaps just a wee bit misleading?\n\nIt's not \"wee bit misleading\" but it just is outright stale.\n\nBack then, before people realized the operation \"to check out the path out\nof index or tree-ish\" belongs naturally to a command whose name is\n\"checkout\", \"to check out the named branch or a commit\" was the only thing\nthat you could do with the command. The one-line description you quoted\nabove reflects that history.\n\nPatches very much welcome; I did not notice it was kept stale.\n"},{"id":"72850","messageId":"20080324025701.GA25064@atjola.homenet","threadId":"12820","inReplyTo":"20080324021411.GE24943@mit.edu","subject":"Re: What I miss from Cogito...","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-03-24T02:57:01Z","receivedAt":"2008-03-24T02:57:01Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.03.23 22:14:11 -0400, Theodore Tso wrote:\n> On Mon, Mar 24, 2008 at 02:40:30AM +0100, Björn Steinbrink wrote:\n> > > If we were going to separate the two commands out, I'd use the name\n> > > \"git revert-file\", because that's what people who are coming from bk\n> > > or hg are used to (where \"revert\" means to undo the local edits done\n> > > to a particular file, as opposed to the git meaning of undoing a\n> > > particular commit).\n> > \n> > Nah, that would create confusion within git, because it does something\n> > totally different from git revert. And checkout can also checkout a\n> > whole tree, not just a file. So you would either need revert-tree as\n> > well... Or add more confusion, because revert-file \"reverting\" a tree is\n> > not quite intuitive.\n> \n> That's why I said \"git revert-file\" as being different from \"git\n> revert\". If you want to revert the entire tree in the sense of\n> \"undoing local edits\", most people today use \"git reset --hard\".\n\nBut that still leaves out e.g. \"git checkout HEAD -- some_directory/\".\nPassing a directory to git revert-file seems plain broken, but you can\ndo that with checkout, so you would also need a git revert-tree (or come\nup with a better name ;-)). And IMHO the difference between git revert\nand the suggested revert-file has too much potential for confusion\nalready.\n\n> > Maybe it's just a misunderstanding on my side, but to me \"checkout\"\n> > means as much as \"get me something out of the repo\". \n> \n> If that's true, why is the one-line summary in the git-checkout man\n> page and in the git top-level man page read as follows?\n> \n> git-checkout - Checkout and switch to a branch\n> \n> At the very least, will you admit that the summary in the man page is\n> perhaps just a wee bit misleading?\n\nI won't disagree on that one ;-) But I probably won't come up with\nsomething better either. My brain stops somewhere at \"Checkout stuff\",\nand that's even less useful than the current one.\n\nBjörn\n"},{"id":"72852","messageId":"20080324030946.9328.76091.julian@quantumfyre.co.uk","threadId":"12820","inReplyTo":"7vtziw3k9a.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Documentation/git-checkout: Update summary to reflect current abilities","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2008-03-24T03:06:20Z","receivedAt":"2008-03-24T03:06:20Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"For a while now, git-checkout has been more powerful than the man-page\nsummary would suggest (the main text does describe the new features),\nso update the summary to hopefully better reflect the current\nfunctionality.\n\nSigned-off-by: Julian Phillips \n---\n\nOn Sun, 23 Mar 2008, Junio C Hamano wrote:\n\n> Theodore Tso writes:\n>\n>> git-checkout - Checkout and switch to a branch\n>>\n>> At the very least, will you admit that the summary in the man page is\n>> perhaps just a wee bit misleading?\n>\n> It's not \"wee bit misleading\" but it just is outright stale.\n>\n> Back then, before people realized the operation \"to check out the path out\n> of index or tree-ish\" belongs naturally to a command whose name is\n> \"checkout\", \"to check out the named branch or a commit\" was the only thing\n> that you could do with the command. The one-line description you quoted\n> above reflects that history.\n>\n> Patches very much welcome; I did not notice it was kept stale.\n\nSomething like this perhaps?\n\n Documentation/git-checkout.txt | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex 4014e72..1b8caf1 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -3,7 +3,7 @@ git-checkout(1)\n \n NAME\n ----\n-git-checkout - Checkout and switch to a branch\n+git-checkout - Checkout/update/refresh items in the working tree\n \n SYNOPSIS\n --------\n-- \n1.5.4.4\n"},{"id":"72929","messageId":"20080324183347.16465.93600.julian@quantumfyre.co.uk","threadId":"12820","inReplyTo":"7vbq54vzhe.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Documentation/git-checkout: Update summary to reflect current abilities","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2008-03-24T03:06:20Z","receivedAt":"2008-03-24T03:06:20Z","isPatch":true,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"For a while now, git-checkout has been more powerful than the man-page\nsummary would suggest (the main text does describe the new features),\nso update the summary to hopefully better reflect the current\nfunctionality. Also update the glossary description of the word checkout.\n\nSigned-off-by: Julian Phillips \n---\nOn Mon, 24 Mar 2008, Junio C Hamano wrote:\n\n> Julian Phillips writes:\n>\n>> diff --git a/Documentation/git-checkout.txt\nb/Documentation/git-checkout.txt\n>> index 4014e72..1b8caf1 100644\n>> --- a/Documentation/git-checkout.txt\n>> +++ b/Documentation/git-checkout.txt\n>> @@ -3,7 +3,7 @@ git-checkout(1)\n>>\n>> NAME\n>> ----\n>> -git-checkout - Checkout and switch to a branch\n>> +git-checkout - Checkout/update/refresh items in the working tree\n>\n> Hmm.\n>\n> The glossary may be a good place to define what the verb \"checkout\" means.\n> I think using that defined word without adding \"/update/refresh\" to\n> muddy its meaning would be more appropriate, after we establish what\n> \"checkout\" means in the glossary.\n>\n> So how about saying \"Check out a whole branch, or paths to the work tree\"\n> or something like that?\n\nOk, so more like this? I've updated the glossary entry for checkout too,\nthough I'm thinking that there ought to be a clearer way to explain it ...\n\n Documentation/git-checkout.txt | 2 +-\n Documentation/glossary.txt | 9 ++++++---\n 2 files changed, 7 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex 4014e72..e11cddb 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -3,7 +3,7 @@ git-checkout(1)\n \n NAME\n ----\n-git-checkout - Checkout and switch to a branch\n+git-checkout - Checkout a branch or paths to the working tree\n \n SYNOPSIS\n --------\ndiff --git a/Documentation/glossary.txt b/Documentation/glossary.txt\nindex ab4caf4..51b6353 100644\n--- a/Documentation/glossary.txt\n+++ b/Documentation/glossary.txt\n@@ -45,9 +45,12 @@ GIT Glossary\n \t\"changesets\" with git.\n \n [[def_checkout]]checkout::\n-\tThe action of updating the <> to a\n-\t<> which was stored in the\n-\t<>.\n+\tThe action of updating all or part of the\n+\t<> with a <>\n+\tor <> from the\n+\t<>, and updating the\n+\t<> and <> if the whole working tree has\n+\tbeen pointed at a new <>.\n \n [[def_cherry-picking]]cherry-picking::\n \tIn <> jargon, \"cherry pick\" means to choose a subset of\n-- \n1.5.4.4\n"},{"id":"72914","messageId":"7vbq54vzhe.fsf@gitster.siamese.dyndns.org","threadId":"12820","inReplyTo":"20080324030946.9328.76091.julian@quantumfyre.co.uk","subject":"Re: [PATCH] Documentation/git-checkout: Update summary to reflect current abilities","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-24T16:49:33Z","receivedAt":"2008-03-24T16:49:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips writes:\n\n>> Theodore Tso writes:\n>>\n>>> git-checkout - Checkout and switch to a branch\n>>>\n>>> At the very least, will you admit that the summary in the man page is\n>>> perhaps just a wee bit misleading?\n>>\n>> It's not \"wee bit misleading\" but it just is outright stale.\n>>\n>> Back then, before people realized the operation \"to check out the path out\n>> of index or tree-ish\" belongs naturally to a command whose name is\n>> \"checkout\", \"to check out the named branch or a commit\" was the only thing\n>> that you could do with the command. The one-line description you quoted\n>> above reflects that history.\n>>\n>> Patches very much welcome; I did not notice it was kept stale.\n>\n> Something like this perhaps?\n>\n> Documentation/git-checkout.txt | 2 +-\n> 1 files changed, 1 insertions(+), 1 deletions(-)\n>\n> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\n> index 4014e72..1b8caf1 100644\n> --- a/Documentation/git-checkout.txt\n> +++ b/Documentation/git-checkout.txt\n> @@ -3,7 +3,7 @@ git-checkout(1)\n> \n> NAME\n> ----\n> -git-checkout - Checkout and switch to a branch\n> +git-checkout - Checkout/update/refresh items in the working tree\n\nHmm.\n\nThe glossary may be a good place to define what the verb \"checkout\" means.\nI think using that defined word without adding \"/update/refresh\" to\nmuddy its meaning would be more appropriate, after we establish what\n\"checkout\" means in the glossary.\n\nSo how about saying \"Check out a whole branch, or paths to the work tree\"\nor something like that?\n"},{"id":"73175","messageId":"20080327023654.GE6803@machine.or.cz","threadId":"12820","inReplyTo":"47E6978C.4040207@zytor.com","subject":"Re: What I miss from Cogito...","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-03-27T02:36:54Z","receivedAt":"2008-03-27T02:36:54Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Mar 23, 2008 at 10:46:52AM -0700, H. Peter Anvin wrote:\n> Theodore Tso wrote:\n>> #!/bin/sh\n>> #\n>> prefix=$(git rev-parse --show-prefix)\n>> for i in $*\n>> do\n>> git show HEAD:$prefix$i > $i\n>> done\n>\n> FWIW, cg-restore is a 131-line shell script, so one can assume it's not \n> just doing it for fun.\n\nActually, such an assumption is not safe, simply since it was written\nlong before the :-syntax and many other nice features were invented; if\none wants to do things in Git sanely these days, it's not even safe to\nlook at Cogito's source code for inspiration anymore as it had to work\nonly with really hardcore primitives.\n\n(And 38 lines is documentation. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWhatever you can do, or dream you can, begin it.\nBoldness has genius, power, and magic in it.\t-- J. W. von Goethe\n"}]}