{"thread":{"id":"19763","subject":"EasyGit Integration","startedAt":"2009-06-09T18:59:08Z","lastAt":"2009-06-13T01:24:31Z","messageCount":49,"participants":["Scott Chacon","Nicolas Pitre","Avery Pennarun","Björn Steinbrink","Elijah Newren","Junio C Hamano","Linus Torvalds","Mark Lodato","Miles Bader","Sam Vilain","Theodore Tso","Jakub Narebski","Matthieu Moy","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"115938","messageId":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","threadId":"19763","inReplyTo":null,"subject":"EasyGit Integration","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2009-06-09T18:59:08Z","receivedAt":"2009-06-09T18:59:08Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey all,\n\nI have been playing with the EasyGit project lately and I have been\nreally impressed. I looked back to the last announcement here and the\nconversation didn't really go anywhere, sadly. I thought it might be\nnice to adopt or at least consider a number of the design decisions\nthey made in modifying the defaults and commands available. Perhaps\nas a 1.7 goal or something? I like it because it addresses a lot of\nthe issues that I hear from beginning users:\n\n* breaks the various things that 'checkout' does into separate\ncommands - moves 'revert' to doing what 'checkout -- path' does, moves\ncurrent 'revert' to 'cherry-pick --revert' (which someone mentioned\nwas a good idea at the last GitTogether), and adds 'unstage' for\n'reset HEAD file'. also adds a '-s' option to 'branch' to switch to\nthe branch after you create it, which many people expect rather than\n'checkout -b'.\n\n* adds 'git resolved' for 'git add', which I hear all the time as\nbeing confusing\n\n* adds 'git publish' for creating a bare repo from your current repo\nand scp/rsync-ing it to a server (which is nice if you're not using\nGitHub/repo.or.cz where remote repo seeding is easier)\n\n* adds 'git info' which shows a bunch of basic information about the\nrepo, which is actually pretty cool\n\n* more verbose and easily scannable default help output - groups the\ncommands into categories, etc.\n\nSome other things that might be nice:\n\n* 'git backout' for 'git reset HEAD^'\n\n* 'git push origin --delete ' for 'git push origin :branch'\n\nThese things may seem pretty simple and even sort of stupid if you're\nused to Git as we are - most of them you can just setup an alias\npretty easily, but you would be amazed at how many people go nuts\nbecause of this stuff. If these simple things were in as defaults,\nsooo many of the remaining 'git is hard and obtuse' arguments would\nbecome obsolete. 'checkout', 'add' and 'reset' seem to be where\npeople have the most difficulty, due to their overloading.\n\nDoes this resonate with anyone else? Does 1.7 seem like a good goal\nfor amending some of these things? Completely redefining 'revert'\nseems like the only backward incompatible change - everything else is\njust wrappers and whatnot, I think.\n\nThanks,\nScott\n"},{"id":"115946","messageId":"alpine.LFD.2.00.0906091535520.31536@xanadu.home","threadId":"19763","inReplyTo":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-06-09T19:43:32Z","receivedAt":"2009-06-09T19:43:32Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 9 Jun 2009, Scott Chacon wrote:\n\n> Hey all,\n> \n> I have been playing with the EasyGit project lately and I have been\n> really impressed. I looked back to the last announcement here and the\n> conversation didn't really go anywhere, sadly. I thought it might be\n> nice to adopt or at least consider a number of the design decisions\n> they made in modifying the defaults and commands available. Perhaps\n> as a 1.7 goal or something? I like it because it addresses a lot of\n> the issues that I hear from beginning users:\n[...]\n> Does this resonate with anyone else? Does 1.7 seem like a good goal\n> for amending some of these things? Completely redefining 'revert'\n> seems like the only backward incompatible change - everything else is\n> just wrappers and whatnot, I think.\n\nCompletely agreed.\n\nThis is indeed refreshing to see some of the git UI warts being \naddressed by people who simply aren't too used to them like I am.\n\nAnd like you said, most of those changes don't create any \nincompatibilities and therefore could be fed back _piecemeal_ into the \nmain git repository today without even requiring a major version bump.\n\n\nNicolas\n"},{"id":"115947","messageId":"32541b130906091252i6c96c44buc148bb525d7cde14@mail.gmail.com","threadId":"19763","inReplyTo":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-06-09T19:52:46Z","receivedAt":"2009-06-09T19:52:46Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Jun 9, 2009 at 2:59 PM, Scott Chacon wrote:\n> * breaks the various things that 'checkout' does into separate\n> commands - moves 'revert' to doing what 'checkout -- path' does, moves\n> current 'revert' to 'cherry-pick --revert' (which someone mentioned\n> was a good idea at the last GitTogether), and adds 'unstage' for\n> 'reset HEAD file'.  also adds a '-s' option to 'branch' to switch to\n> the branch after you create it, which many people expect rather than\n> 'checkout -b'.\n\nThis would definitely make it easier to explain things to svn users.\nTo be honest, I'm not convinced svn's use of the word \"revert\" is\nreally right, though. Git's isn't *really* right either, since it\nactually makes a new commit, it doesn't remove the old one like it\nsounds like it does. Maybe 'reverse' would be a better name for what\ngit does, and we should just introduce another word for what svn does.\n (With CVS, you just deleted the file and then did a checkout/update\non it again, which made sense to me. That works in git too.)\n\nCrazy idea: we could actually make 'git revert' do both: given a\ncommit, it applies the reverse as it does now. Given filenames, it\nsimply brings them back to HEAD. But maybe that's too crazy.\n\n> * adds 'git resolved' for 'git add', which I hear all the time as\n> being confusing\n\nThis one doesn't really do it for me. svn's need to \"resolve\" a file\nafter removing its conflicts always annoyed me. Look, you can see\nI've screwed around with the file. The file contains no more\nconflicts. It's resolved, already!\n\nMaybe it's heresy, but I really liked CVS's way of dealing with this:\nif the file still has conflict markers in it, it's not resolved. If\nit doesn't, then it's resolved. Very hard to mess up. And I've\ndefinitely messed up (and known other people to mess up) with both\nsvn's method and git's method, both of which allow you to commit files\nwith conflict markers without getting warned.\n\n> * adds 'git publish' for creating a bare repo from your current repo\n> and scp/rsync-ing it to a server (which is nice if you're not using\n> GitHub/repo.or.cz where remote repo seeding is easier)\n\nVery cool, and this has been seriously hard to explain to people. I'm\nnot even sure there *is* a good way to do this without running a\nseries of several commands.\n\n> * adds 'git info' which shows a bunch of basic information about the\n> repo, which is actually pretty cool\n\nLess important to me, but sounds fine just due to svn compatibility.\n\n> * 'git push origin --delete ' for 'git push origin :branch'\n\nThis would help a lot of people too, I think. Although some might\nargue that \"helping\" them to delete branches is maybe not a great\nidea.\n\nHave fun,\n\nAvery\n"},{"id":"115949","messageId":"20090609201200.GA13781@atjola.homenet","threadId":"19763","inReplyTo":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-06-09T20:12:00Z","receivedAt":"2009-06-09T20:12:00Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:\n> * breaks the various things that 'checkout' does into separate\n> commands - moves 'revert' to doing what 'checkout -- path' does\n\nLooking through the \"eg revert\" docs [1], I can't seem to find how you can\ndo \"checkout -- path\" with it at all. \"eg revert foo\" seems to be \"git\ncheckout HEAD -- foo\". The \"eg revert\" looks really confusing to me.\n\"eg revert --unstaged --in HEAD~8\". Hu? Revert unstaged changes in\nHEAD~8? Am I missing something?\n\nBjörn\n\n[1] http://www.gnome.org/~newren/eg/documentation/revert.html\n"},{"id":"115952","messageId":"20090609203747.GB13781@atjola.homenet","threadId":"19763","inReplyTo":"32541b130906091252i6c96c44buc148bb525d7cde14@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-06-09T20:37:47Z","receivedAt":"2009-06-09T20:37:47Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.06.09 15:52:46 -0400, Avery Pennarun wrote:\n> On Tue, Jun 9, 2009 at 2:59 PM, Scott Chacon wrote:\n> > * breaks the various things that 'checkout' does into separate\n> > commands - moves 'revert' to doing what 'checkout -- path' does, moves\n> > current 'revert' to 'cherry-pick --revert' (which someone mentioned\n> > was a good idea at the last GitTogether), and adds 'unstage' for\n> > 'reset HEAD file'.  also adds a '-s' option to 'branch' to switch to\n> > the branch after you create it, which many people expect rather than\n> > 'checkout -b'.\n> \n> This would definitely make it easier to explain things to svn users.\n> To be honest, I'm not convinced svn's use of the word \"revert\" is\n> really right, though. Git's isn't *really* right either, since it\n> actually makes a new commit, it doesn't remove the old one like it\n> sounds like it does. Maybe 'reverse' would be a better name for what\n> git does, and we should just introduce another word for what svn does.\n> (With CVS, you just deleted the file and then did a checkout/update\n> on it again, which made sense to me. That works in git too.)\n> \n> Crazy idea: we could actually make 'git revert' do both: given a\n> commit, it applies the reverse as it does now. Given filenames, it\n> simply brings them back to HEAD. But maybe that's too crazy.\n\nDoesn't seem that crazy to me. But maybe a bit problematic if you want\nto support both, \"git checkout -- .\" and \"git checkout HEAD -- .\". And\nadding DWIMmery there seems dangerous, as in:\n\ngit revert == git checkout -- .\n\ngit revert HEAD ==\n no uncommitted changes = revert commit HEAD\n uncommitted changes = revert to HEAD\n\nBjörn\n"},{"id":"115953","messageId":"51419b2c0906091340i11965efcr5cf5bb4a71108fa6@mail.gmail.com","threadId":"19763","inReplyTo":"20090609201200.GA13781@atjola.homenet","subject":"Re: EasyGit Integration","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-06-09T20:40:33Z","receivedAt":"2009-06-09T20:40:33Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\n2009/6/9 Björn Steinbrink :\n> On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:\n>> * breaks the various things that 'checkout' does into separate\n>> commands - moves 'revert' to doing what 'checkout -- path' does\n>\n> Looking through the \"eg revert\" docs [1], I can't seem to find how you can\n> do \"checkout -- path\" with it at all. \"eg revert foo\" seems to be \"git\n> checkout HEAD -- foo\".\n\nIf you want to revert only the unstaged changes to path:\n \"checkout -- path\" OR \"revert --unstaged path\"\nIf you want to revert both staged and unstaged changes to foo:\n \"checkout HEAD -- foo\" OR \"revert foo\"\n\n> The \"eg revert\" looks really confusing to me.\n> \"eg revert --unstaged --in HEAD~8\". Hu? Revert unstaged changes in\n> HEAD~8? Am I missing something?\n\nHmm. Bad ordering, I guess -- it's revert changes in HEAD~8 to the\nworking copy only (by default, revert tries to apply changes to both\nthe working copy and the index). Yeah, it doesn't read very well.\n\nI'm not sure I like having \"--in\" as part of revert, partially because\nof this confusion (and partially because I don't think it's\nimplementation is correct anyway). However, I do occasionally really\nlike being able to revert the change _to a single file_ made in some\nprevious commit, so I haven't removed it from eg (yet?). *shrug*\n\n\n\nElijah\n"},{"id":"115954","messageId":"32541b130906091342s7dd6064fud2205bee8af95aab@mail.gmail.com","threadId":"19763","inReplyTo":"20090609203747.GB13781@atjola.homenet","subject":"Re: EasyGit Integration","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-06-09T20:42:33Z","receivedAt":"2009-06-09T20:42:33Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"2009/6/9 Björn Steinbrink :\n> On 2009.06.09 15:52:46 -0400, Avery Pennarun wrote:\n>> To be honest, I'm not convinced svn's use of the word \"revert\" is\n>> really right, though.  Git's isn't *really* right either, since it\n>> actually makes a new commit, it doesn't remove the old one like it\n>> sounds like it does.  Maybe 'reverse' would be a better name for what\n>> git does, and we should just introduce another word for what svn does.\n>>  (With CVS, you just deleted the file and then did a checkout/update\n>> on it again, which made sense to me.  That works in git too.)\n>>\n>> Crazy idea: we could actually make 'git revert' do both: given a\n>> commit, it applies the reverse as it does now.  Given filenames, it\n>> simply brings them back to HEAD.  But maybe that's too crazy.\n>\n> Doesn't seem that crazy to me. But maybe a bit problematic if you want\n> to support both, \"git checkout -- .\" and \"git checkout HEAD -- .\". And\n> adding DWIMmery there seems dangerous, as in:\n>\n> git revert == git checkout -- .\n>\n> git revert HEAD ==\n>  no uncommitted changes = revert commit HEAD\n>  uncommitted changes = revert to HEAD\n\nWell, that's what I meant by \"crazy\" :)\n\nSince so many of the other suggestions in eg are so simple and\nnon-conflicting, perhaps it's best to drop this branch of discussion\nuntil the non-controversial bits are adopted. It would be bad to lose\nother great improvements just because this one command is\nproblematic...\n\nHave fun,\n\nAvery\n"},{"id":"115955","messageId":"51419b2c0906091349j6ecd7d34x10ef92d42fee4a1e@mail.gmail.com","threadId":"19763","inReplyTo":"20090609203747.GB13781@atjola.homenet","subject":"Re: EasyGit Integration","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-06-09T20:49:41Z","receivedAt":"2009-06-09T20:49:41Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"2009/6/9 Björn Steinbrink :\n>> Crazy idea: we could actually make 'git revert' do both: given a\n>> commit, it applies the reverse as it does now.  Given filenames, it\n>> simply brings them back to HEAD.  But maybe that's too crazy.\n\nProbably too crazy (too much potential for confusion), but an\ninteresting thing about the way eg revert was written is that any\nvalid git revert command passed to eg revert is invalid syntax, so I\ncan print the simple error message:\n If you are used to git revert, try 'eg cherry-pick -R '...\n\nThat prevents accidental misuse and misunderstandings, such as these:\n\n> Doesn't seem that crazy to me. But maybe a bit problematic if you want\n> to support both, \"git checkout -- .\" and \"git checkout HEAD -- .\". And\n> adding DWIMmery there seems dangerous, as in:\n>\n> git revert == git checkout -- .\n>\n> git revert HEAD ==\n>  no uncommitted changes = revert commit HEAD\n>  uncommitted changes = revert to HEAD\n\nI was thinking that if people had too much heartburn over changing the\nmeaning of revert from \"revert-commit\" to \"revert-edits\", then we\ncould always submit the eg revert functionality as git-revert-edits.\n"},{"id":"115957","messageId":"20090609211806.GC13781@atjola.homenet","threadId":"19763","inReplyTo":"51419b2c0906091340i11965efcr5cf5bb4a71108fa6@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-06-09T21:18:06Z","receivedAt":"2009-06-09T21:18:06Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.06.09 14:40:33 -0600, Elijah Newren wrote:\n> Hi,\n> \n> 2009/6/9 Björn Steinbrink :\n> > On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:\n> >> * breaks the various things that 'checkout' does into separate\n> >> commands - moves 'revert' to doing what 'checkout -- path' does\n> >\n> > Looking through the \"eg revert\" docs [1], I can't seem to find how you can\n> > do \"checkout -- path\" with it at all. \"eg revert foo\" seems to be \"git\n> > checkout HEAD -- foo\".\n> \n> If you want to revert only the unstaged changes to path:\n> \"checkout -- path\" OR \"revert --unstaged path\"\n> If you want to revert both staged and unstaged changes to foo:\n> \"checkout HEAD -- foo\" OR \"revert foo\"\n\nOK, so --unstaged doesn't just select the destination, but also the\nsource, unless you explicitly override it, right?\n\neg revert [--since HEAD] path\n ==> source: HEAD, destination: working tree, index\n\neg revert --unstaged path\n ==> source: index, destination: working tree\n\neg revert --unstaged --since HEAD path\n ==> source: HEAD, destination: working tree\n\n\n> \n> > The \"eg revert\" looks really confusing to me.\n> > \"eg revert --unstaged --in HEAD~8\". Hu? Revert unstaged changes in\n> > HEAD~8? Am I missing something?\n> \n> Hmm. Bad ordering, I guess -- it's revert changes in HEAD~8 to the\n> working copy only (by default, revert tries to apply changes to both\n> the working copy and the index). Yeah, it doesn't read very well.\n> \n> I'm not sure I like having \"--in\" as part of revert, partially because\n> of this confusion (and partially because I don't think it's\n> implementation is correct anyway). However, I do occasionally really\n> like being able to revert the change _to a single file_ made in some\n> previous commit, so I haven't removed it from eg (yet?). *shrug*\n\nI'm not sure that \"--in\" is the worst thing here. To me, --unstaged is\nworse, because I apply the attribute \"unstaged\" to the changes to be\nreverted. And that makes no sense when I supply a commit, a commit\ncannot have unstaged changes. I guess that if --unstaged wasn't used to\nselect the destination, I might have come up with \"eg revert --unstaged\"\nmyself, just from seeing the options. But seeing that --unstaged can be\nused with a commit confused me.\n\nBjörn\n"},{"id":"115958","messageId":"20090609212748.GD13781@atjola.homenet","threadId":"19763","inReplyTo":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-06-09T21:27:48Z","receivedAt":"2009-06-09T21:27:48Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:\n> * adds 'git resolved' for 'git add', which I hear all the time as\n> being confusing\n\nIs \"resolve\" a plain alias, like \"stage\", or smart in deciding which\nfiles it accepts? My gut feeling is that a plain alias might cause\ntrouble again when users get lazy and start to do \"git resolve .\" and\nwonder why that adds new files.\n\nIff such a \"resolve\" command is added, it should IMHO only serve the\npurpose of changing the status of index entries marked as \"unstaged\",\nand do nothing else that \"add\" can do. When someone asks why \"git add\"\nis used for telling git that a conflict was resolved, I can say that\n\"git add\" means \"add this to the things to be committed\" and that that\nimplies that conflicts have been resolved (I like to describe \"git add\"\nas \"tell git that 'this is good to commit'\"). So I can give some logical\nexplanation. But if someone would ask me why \"git resolve\" can add new\nfiles, which never had a merge conflict, to the index, I'd be pretty\nstumped.\n\nBjörn\n"},{"id":"115959","messageId":"7veittjdiu.fsf@alter.siamese.dyndns.org","threadId":"19763","inReplyTo":"20090609212748.GD13781@atjola.homenet","subject":"Re: EasyGit Integration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-09T21:36:09Z","receivedAt":"2009-06-09T21:36:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:\n>> * adds 'git resolved' for 'git add', which I hear all the time as\n>> being confusing\n>\n> Is \"resolve\" a plain alias, like \"stage\", or smart in deciding which\n> files it accepts? My gut feeling is that a plain alias might cause\n> trouble again when users get lazy and start to do \"git resolve .\" and\n> wonder why that adds new files.\n>\n> Iff such a \"resolve\" command is added, it should IMHO only serve the\n> purpose of changing the status of index entries marked as \"unstaged\",\n> and do nothing else that \"add\" can do.\n\nVery good point (modulo s/unstaged/unmerged/ I think).\n"},{"id":"115960","messageId":"51419b2c0906091448r1d45705he06f34bf9da1f797@mail.gmail.com","threadId":"19763","inReplyTo":"20090609212748.GD13781@atjola.homenet","subject":"Re: EasyGit Integration","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-06-09T21:48:43Z","receivedAt":"2009-06-09T21:48:43Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"2009/6/9 Björn Steinbrink :\n> On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:\n>> * adds 'git resolved' for 'git add', which I hear all the time as\n>> being confusing\n>\n> Is \"resolve\" a plain alias, like \"stage\", or smart in deciding which\n> files it accepts? My gut feeling is that a plain alias might cause\n> trouble again when users get lazy and start to do \"git resolve .\" and\n> wonder why that adds new files.\n\nIn eg it's currently a plain alias, but I like your arguments for\nmaking it only handle unmerged entries.\n\n> Iff such a \"resolve\" command is added, it should IMHO only serve the\n> purpose of changing the status of index entries marked as \"unstaged\",\n> and do nothing else that \"add\" can do. When someone asks why \"git add\"\n> is used for telling git that a conflict was resolved, I can say that\n> \"git add\" means \"add this to the things to be committed\" and that that\n> implies that conflicts have been resolved (I like to describe \"git add\"\n> as \"tell git that 'this is good to commit'\"). So I can give some logical\n> explanation. But if someone would ask me why \"git resolve\" can add new\n> files, which never had a merge conflict, to the index, I'd be pretty\n> stumped.\n"},{"id":"115962","messageId":"51419b2c0906091500q6aaff225q42bd79e6349a1143@mail.gmail.com","threadId":"19763","inReplyTo":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-06-09T22:00:14Z","receivedAt":"2009-06-09T22:00:14Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Tue, Jun 9, 2009 at 12:59 PM, Scott Chacon wrote:\n> Hey all,\n>\n> I have been playing with the EasyGit project lately and I have been\n> really impressed.\n\nThanks for bringing this up. I should have done better at proposing\nsome of these changes upstream...\n\n> * breaks the various things that 'checkout' does into separate\n> commands - moves 'revert' to doing what 'checkout -- path' does, moves\n> current 'revert' to 'cherry-pick --revert' (which someone mentioned\n> was a good idea at the last GitTogether), and adds 'unstage' for\n\nAs a side note, the mapping from eg revert to git commands is not so\nsimple; you'll miss a lot of cases if you were to make a simple alias.\n :-)\n\n\n\nI'll note that you can run 'eg changes --details' to get a (hopefully\nup-to-date and) complete list...\n\n> Some other things that might be nice:\n>\n> * 'git backout' for 'git reset HEAD^'\n\nMay cause confusion for mercurial users (hg backout == current git\nrevert). I don't have a better proposal, though. 'uncommit'?\n\n\nAlso, a consistency proposal that I have not yet gotten to\nimplementing in eg; It'd be nice to add more consistency with these\ncommands:\n - continue incomplete am: git am --resolved\n - continue incomplete rebase: git rebase --continue\n - continue incomplete merge: git commit\nso that it looks like this (while still allowing the old ways for\nbackward compatibility):\n => continue incomplete am: git am --continue\n => continue incomplete rebase: git rebase --continue\n => continue incomplete merge: git merge --continue (or is this\ngoing overboard?)\n\nAnd to change this:\n - abort incomplete am: git am --abort\n - abort incomplete bisect: git bisect reset\n - abort incomplete merge: git reset --hard HEAD\n - abort incomplete rebase: git rebase --abort\nso that it looks like this (again still allowing old ways):\n => abort incomplete am: git am --abort\n => abort incomplete bisect: git bisect --abort\n => abort incomplete merge: git merge --abort\n => abort incomplete rebase: git rebase --abort\n\n> These things may seem pretty simple and even sort of stupid if you're\n> used to Git as we are - most of them you can just setup an alias\n> pretty easily, but you would be amazed at how many people go nuts\n> because of this stuff.  If these simple things were in as defaults,\n> sooo many of the remaining 'git is hard and obtuse' arguments would\n> become obsolete.  'checkout', 'add' and 'reset' seem to be where\n> people have the most difficulty, due to their overloading.\n>\n> Does this resonate with anyone else?  Does 1.7 seem like a good goal\n> for amending some of these things?  Completely redefining 'revert'\n> seems like the only backward incompatible change - everything else is\n> just wrappers and whatnot, I think.\n\nMostly just wrappers, yes. There are two other big incompatible\nchanges, both to push: (1) 'eg push' is basically hardcoded to do what\npush.default=tracking now does (although now that push.default exists,\nI'm considering dropping this change in eg), and (2) eg push will try\nto check whether the remote repository is bare and deny the push\nunless one of the arguments is a refspec that has a ':' character in\nit (i.e. a push-side check, rather than git's recent receive-side\ncheck; having both probably doesn't make sense, so it's another thing\nI'm reconsidering).\n\nAlso, I wondered whether others would consider the different defaults\nfor commit & diff to be a big backward incompatible change, though the\nfact that you didn't seem to notice it and lots of others don't either\nsuggest it's not that big (for experienced users). There are also\nmore minor changes to the defaults of bundle, log, and status, but\nthose are innocuous enough that they hardly qualify as backward\nincompatible.\n\n\nThanks,\nElijah\n"},{"id":"115963","messageId":"alpine.LFD.2.01.0906091512350.6847@localhost.localdomain","threadId":"19763","inReplyTo":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-06-09T22:14:58Z","receivedAt":"2009-06-09T22:14:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 Jun 2009, Scott Chacon wrote:\n> \n> * breaks the various things that 'checkout' does into separate\n> commands - moves 'revert' to doing what 'checkout -- path' does\n\nNo.\n\nNAK on this one. \n\nThe fact that some idiotic SVN usage exists is not an excuse to break \nlong-standing git users. \"revert\" comes from bk, and quite frankly, I \nobject _very_ strongly to taking naming from something that is very \nobviously the inferior system (SVN) over something very obviously superior \n(BK and git).\n\nFeel free to add other \"helper\" aliases that are actually _new_ and have \nno pre-existing git meaning, but not things like this. Not breaking \nexisting git usage just because somebody is too stupid and/or lazy to try \nto learn a new word.\n\n\t\tLinus\n"},{"id":"115964","messageId":"51419b2c0906091530t3dfa5267s2262f979f1e9982a@mail.gmail.com","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906091512350.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-06-09T22:30:11Z","receivedAt":"2009-06-09T22:30:11Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jun 9, 2009 at 4:14 PM, Linus\nTorvalds wrote:\n> On Tue, 9 Jun 2009, Scott Chacon wrote:\n>>\n>> * breaks the various things that 'checkout' does into separate\n>> commands - moves 'revert' to doing what 'checkout -- path' does\n>\n> No.\n\n> Feel free to add other \"helper\" aliases that are actually _new_ and have\n> no pre-existing git meaning, but not things like this. Not breaking\n> existing git usage just because somebody is too stupid and/or lazy to try\n> to learn a new word.\n\nDo you object to using 'revert' in the name of the new command or just\nto having the new command take over the exact name 'revert'? I'd like\nto propose making the reverting of edits functionality available under\nthe command name 'revert-edits', while leaving the existing reverting\nof commits functionality under 'revert', but I'm not sure if that\nwould run afoul of your objections as well.\n\n\nElijah\n"},{"id":"115965","messageId":"alpine.LFD.2.01.0906091535410.6847@localhost.localdomain","threadId":"19763","inReplyTo":"51419b2c0906091530t3dfa5267s2262f979f1e9982a@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-06-09T22:40:35Z","receivedAt":"2009-06-09T22:40:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 Jun 2009, Elijah Newren wrote:\n> \n> Do you object to using 'revert' in the name of the new command or just\n> to having the new command take over the exact name 'revert'?\n\nI object to changing existing meaning.\n\n> I'd like to propose making the reverting of edits functionality \n> available under the command name 'revert-edits'\n\nThat's fine.\n\nI also don't mind per se having the \"git checkout\" kind of semantics, \nwhere different kinds of arguments result in different kinds of behavior. \nI'm not convinced it's a wonderful design, but I would not object to\n\n - old behavior: revert the commit by creating an \"anti-commit\":\n\n\tgit revert \n\n - new extension: revert the state of the working tree to the HEAD:\n\n\tgit revert [--] pathspec\n\nwhich would kind of match the semantics of \"git checkout\" does.\n\nSo it's not that I object to \"git revert\" as a name. I just object to \nchanging existing (and sane) semantics just for some silly person who \nthinks that git is just \"SVN done right\". \n\nGit is _soo_ much more than just that. People need to live with the fact \nthat it's not just a SVN clone.\n\n\t\tLinus\n"},{"id":"115971","messageId":"ca433830906091740m76f74951j170608c9d9757272@mail.gmail.com","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906091535410.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-06-10T00:40:17Z","receivedAt":"2009-06-10T00:40:17Z","isPatch":false,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"I too would like to see some of the improved UI aspects of EasyGit\nmerged into git.\n\n\nOn Tue, Jun 9, 2009 at 6:40 PM, Linus\nTorvalds wrote:\n> So it's not that I object to \"git revert\" as a name. I just object to\n> changing existing (and sane) semantics just for some silly person who\n> thinks that git is just \"SVN done right\".\n>\n> Git is _soo_ much more than just that. People need to live with the fact\n> that it's not just a SVN clone.\n\nI do not think \"revert\" to mean \"checkout --\" is just an SVN idiom. I\nhave heard similar suggestions by people first learning git who have\nnever used SVN or CVS before. To me, \"revert\" is a very natural name\nfor a command to undo changes in the working directory. \"Checkout,\"\non the other hand, usually means to switch branches, which is\nlogically distinct from undoing changes in the working tree. In fact,\nif one tries to use \"checkout\" to switch a branch while there are\nlocal changes, git will refuse!\n\nAt the same time, \"revert\" also is a fine name for making an inverse\ncommit, as revert currently does. So perhaps overloading revert as\nyou suggest is a good idea. It is wise, as you suggest, to keep\nbackwards compatibility for existing users.\n\n\n\nMark\n"},{"id":"115972","messageId":"buoy6s07v30.fsf@dhlpc061.dev.necel.com","threadId":"19763","inReplyTo":"32541b130906091252i6c96c44buc148bb525d7cde14@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-06-10T01:09:55Z","receivedAt":"2009-06-10T01:09:55Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Avery Pennarun writes:\n> This would definitely make it easier to explain things to svn users.\n> To be honest, I'm not convinced svn's use of the word \"revert\" is\n> really right, though. Git's isn't *really* right either, since it\n> actually makes a new commit, it doesn't remove the old one like it\n> sounds like it does.\n\nI think both definitions are quite reasonable.\n\nThe sense in which git uses the word -- \"make a change reversing an\nearlier change\" -- is actually very common in programming.\n\n-Miles\n\n-- \nWould you like fries with that?\n"},{"id":"115973","messageId":"4A2F0B8A.9010203@vilain.net","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906091512350.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-06-10T01:25:30Z","receivedAt":"2009-06-10T01:25:30Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> On Tue, 9 Jun 2009, Scott Chacon wrote:\n> \n>> * breaks the various things that 'checkout' does into separate\n>> commands - moves 'revert' to doing what 'checkout -- path' does\n>> \n>\n> No.\n>\n> NAK on this one. \n>\n> The fact that some idiotic SVN usage exists is not an excuse to break \n> long-standing git users. \"revert\" comes from bk, and quite frankly, I \n> object _very_ strongly to taking naming from something that is very \n> obviously the inferior system (SVN) over something very obviously superior \n> (BK and git).\n> \n\nWe talked about this much at GitTogether '08. It's true that for\n'reverting' a change in the past, that is the right thing to do. However\nI don't think there is a first principles case that this is always what\npeople mean by 'revert'. And it is not just SVN - Mercurial, Monotone,\nBazaar, Darcs all use 'revert' in this way. By comparison with those\nsystems, the number of users coming from BK is quite low.\n\nWe talked about making a 'git revert-file' and 'git revert-commit', with\n'git revert' printing a message encouraging the user to specify which\none they wanted (or potentially pointing them to the correct\nincantations of 'git checkout' or 'git cherry-pick').\n\nI think as long as there is a deprecation cycle, and that users can\nselect the old behaviour (either via an alias or a config option), then\nwe shouldn't upset many long-time users of revert. Do you agree?\n\nSam.\n"},{"id":"115974","messageId":"alpine.LFD.2.01.0906091857210.6847@localhost.localdomain","threadId":"19763","inReplyTo":"4A2F0B8A.9010203@vilain.net","subject":"Re: EasyGit Integration","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-06-10T01:59:40Z","receivedAt":"2009-06-10T01:59:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 10 Jun 2009, Sam Vilain wrote:\n> \n> We talked about making a 'git revert-file' and 'git revert-commit', with\n> 'git revert' printing a message encouraging the user to specify which\n> one they wanted (or potentially pointing them to the correct\n> incantations of 'git checkout' or 'git cherry-pick').\n> \n> I think as long as there is a deprecation cycle, and that users can\n> select the old behaviour (either via an alias or a config option), then\n> we shouldn't upset many long-time users of revert. Do you agree?\n\nNo. I disagree. What the hell is the point in making an _inferior_ name \nfor what we already have?\n\nI violently disagree with making git worse just because somebody cannot \nbother to learn it. And it really is about \"bother\" - it's clearly not \nabout anything else.\n\nI also don't see why you'd also then advocate a clearly inferior model \nwith two different commands, when you _could_ just do the \"commitname\" vs \n\"pathspec\" model. \n\n\t\tLinus\n"},{"id":"115975","messageId":"7vws7khlvj.fsf@alter.siamese.dyndns.org","threadId":"19763","inReplyTo":"4A2F0B8A.9010203@vilain.net","subject":"Re: EasyGit Integration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-10T02:18:40Z","receivedAt":"2009-06-10T02:18:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain writes:\n\n> We talked about this much at GitTogether '08. It's true that for\n> 'reverting' a change in the past, that is the right thing to do. However\n> I don't think there is a first principles case that this is always what\n> people mean by 'revert'....\n\nSorry; what you think people mean by 'revert' does not matter at this\npoint, unless you are building a brand-new system from scratch.\n\n> I think as long as there is a deprecation cycle, and that users can\n> select the old behaviour (either via an alias or a config option), then\n> we shouldn't upset many long-time users of revert. Do you agree?\n\nI actually don't.\n\nI do not think introducing \"git revert-file\" (or \"git revert -- path\") is\na problem at all. But \"git revert $commit\" has been and is an integral\npart of the established git workflow, and I do not see a point in changing\nit to mean something else, with any deprecation period.\n\nBy the way, I have a bigger issue.\n\nSome changes in \"eg\" may port well as a new command to git-core, and some\nchange (like this \"revert\" thing that has different semantics and breaks\nestablished workflow) will never be in git-core. People may think that it\nwould not cause many problems if we picked only the non-conflicting bits,\nbut I actually have some reservations about that.\n\nIt will bloat the total number of subcommands you can give git, with the\nend result being\n\n (1) old timers won't use \"revert-commit\" and \"revert-file\" at all but use\n \"revert\" and \"checkout -- path\"; while\n\n (2) new people will behave the other way; and\n\n (3) the documentation will list all of commands from these two disjoint\n sets under \"git\".\n\nWhen a \"eg\" minded person teaches git, the students may have to be told to\nignore \"revert\" and \"checkout -- path\", because there are other ways to do\nthe same thing in the lingo they are being taught, which is a subset of\ngit commands. The manual pages will be littered with descriptions like\n\"this command, when used this way, is synonymous to using that other\ncommand with this option\", leaving the reader wondering why there are so\nmany ways to do the same thing.\n\nIf \"eg\" (I do not have _anything_ against it; the discussion applies to\nother Porcelains as well) were kept independent _and_ offered complete set\nof features that users need without resorting to git-core, on the other\nhand, the students do not have to know about \"revert\", and the manuals\nthey need to consult will not have to talk about \"if you are using\ngit-core, this is done differently in this way\". The learning curve will\nget a lot smoother for new people.\n\nIf new and useful features (e.g. \"creating a remote repository over SSH in\none shot\") are supported by another Porcelain (e.g. \"eg\") they may be\nworth porting over to git-core, in order to make git-core more usable.\nThere is a precedent for that kind of side port (e.g. \"filter-branch\" that\ncame from Cogito).\n\nBut aliases for doing essentially the same thing in slightly different\nsyntax? I'd rather not to see them called \"git foo\". In the end, I think\nit will harm the users, both new and old.\n\nIf you go back to the list archive, you will find me suggesting a new set\nof commands with \"gh\" prefix, back in 1.3.X days, I think.\n\nI was not joking. The reasoning was exactly the same, and it remains so.\n"},{"id":"115976","messageId":"4A2F1FD0.8060303@vilain.net","threadId":"19763","inReplyTo":"7vws7khlvj.fsf@alter.siamese.dyndns.org","subject":"Re: EasyGit Integration","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-06-10T02:52:00Z","receivedAt":"2009-06-10T02:52:00Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n>> I think as long as there is a deprecation cycle, and that users can\n>> select the old behaviour (either via an alias or a config option), then\n>> we shouldn't upset many long-time users of revert. Do you agree?\n>> \n>\n> I actually don't.\n>\n> I do not think introducing \"git revert-file\" (or \"git revert -- path\") is\n> a problem at all. But \"git revert $commit\" has been and is an integral\n> part of the established git workflow, and I do not see a point in changing\n> it to mean something else, with any deprecation period.\n> \n\nOk. Off-hand I can't remember why we excluded \"git revert -- path\" as\nworkable. Whatever that reason was led to the group of core developers\ncoming up with these \"clearly\" \"_inferior_\" names.\n\nThat could solve the problem, switching behaviour on the type of\nargument passed rather than including it in the command name. I think\nthat was my preferred option at the time, too. Perhaps some other\nattendees can recall more clearly...\n\n> Some changes in \"eg\" may port well as a new command to git-core, and some\n> change (like this \"revert\" thing that has different semantics and breaks\n> established workflow) will never be in git-core. People may think that it\n> would not cause many problems if we picked only the non-conflicting bits,\n> but I actually have some reservations about that.\n>\n> It will bloat the total number of subcommands you can give git, with the\n> end result being\n>\n> (1) old timers won't use \"revert-commit\" and \"revert-file\" at all but use\n> \"revert\" and \"checkout -- path\"; while\n>\n> (2) new people will behave the other way; and\n>\n> (3) the documentation will list all of commands from these two disjoint\n> sets under \"git\".\n>\n> When a \"eg\" minded person teaches git, the students may have to be told to\n> ignore \"revert\" and \"checkout -- path\", because there are other ways to do\n> the same thing in the lingo they are being taught, which is a subset of\n> git commands. The manual pages will be littered with descriptions like\n> \"this command, when used this way, is synonymous to using that other\n> command with this option\", leaving the reader wondering why there are so\n> many ways to do the same thing.\n> \n\nYes, I agree that if the old behaviour is not being deprecated it\nprobably shouldn't be replicated as well.\n\nIn fact that may have been the argument for excluding 'git revert\nfilename' - because you can already do that with 'git checkout HEAD --\nfilename'; but perhaps in this case it is acceptable, because the\n'checkout' command can also check out from other revisions, but revert\ncan't.\n\nSam.\n"},{"id":"115977","messageId":"buoski87pgt.fsf@dhlpc061.dev.necel.com","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906091535410.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-06-10T03:11:14Z","receivedAt":"2009-06-10T03:11:14Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Linus Torvalds writes:\n> I'm not convinced it's a wonderful design, but I would not object to\n>\n> - old behavior: revert the commit by creating an \"anti-commit\":\n> \tgit revert \n> - new extension: revert the state of the working tree to the HEAD:\n> \tgit revert [--] pathspec\n>\n> which would kind of match the semantics of \"git checkout\" does.\n\nThat seems even more confusing, to _both_ svn users and git users...\n\nThe similar overloading of \"checkout\" (to have two completely different\nmeanings depending on whether a branch or pathname is specified) also\nfeels very awkward to me.\n\nI sort of assumed that the \"checkout -- pathname\" form was added as a\nsop to cvs/svn users, for which that's a very common idiom...\n\n-Miles\n\n-- \nIn New York, most people don't have cars, so if you want to kill a person, you\nhave to take the subway to their house. And sometimes on the way, the train\nis delayed and you get impatient, so you have to kill someone on the subway.\n [George Carlin]\n"},{"id":"115979","messageId":"alpine.LFD.2.00.0906092252210.31536@xanadu.home","threadId":"19763","inReplyTo":"7vws7khlvj.fsf@alter.siamese.dyndns.org","subject":"Re: EasyGit Integration","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-06-10T03:27:23Z","receivedAt":"2009-06-10T03:27:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 9 Jun 2009, Junio C Hamano wrote:\n\n> Some changes in \"eg\" may port well as a new command to git-core, and some\n> change (like this \"revert\" thing that has different semantics and breaks\n> established workflow) will never be in git-core. People may think that it\n> would not cause many problems if we picked only the non-conflicting bits,\n> but I actually have some reservations about that.\n> \n> It will bloat the total number of subcommands you can give git, with the\n> end result being\n> \n> (1) old timers won't use \"revert-commit\" and \"revert-file\" at all but use\n> \"revert\" and \"checkout -- path\"; while\n> \n> (2) new people will behave the other way; and\n> \n> (3) the documentation will list all of commands from these two disjoint\n> sets under \"git\".\n\nNah. This doesn't have to be so extreme. Your example above is \nrelevant, and I agree with you that this is unnecessary bloat.\n\nHowever there are many other examples, such as \"git branch -s\" being \nequivalent to \"git checkout -b\" which I think are rather nice to have.\n\nThe 'git resolved' command for staging resolved conflicts is also nice.\n\nAlso does the streamlining of --abort/--continue for a couple commands.\n\nThis is why I said that such additions should be proposed piecemeal and \njudged separately.\n\n> When a \"eg\" minded person teaches git, the students may have to be told to\n> ignore \"revert\" and \"checkout -- path\", because there are other ways to do\n> the same thing in the lingo they are being taught, which is a subset of\n> git commands. The manual pages will be littered with descriptions like\n> \"this command, when used this way, is synonymous to using that other\n> command with this option\", leaving the reader wondering why there are so\n> many ways to do the same thing.\n\nThis is not necessarily a good strategy to always list all equivalences. \nIf someone learns from the git-branch man page that -s also switches to \nthe newly created branch, then that person won't gain anything nor care \nto know that 'git checkout -b' does the same.\n\n> If \"eg\" (I do not have _anything_ against it; the discussion applies to\n> other Porcelains as well) were kept independent _and_ offered complete set\n> of features that users need without resorting to git-core, on the other\n> hand, the students do not have to know about \"revert\", and the manuals\n> they need to consult will not have to talk about \"if you are using\n> git-core, this is done differently in this way\". The learning curve will\n> get a lot smoother for new people.\n\nOn the other hand, having multiple porcelains simply divide the user \nbase which is not always a good thing. Look at what happened to cogito \nfor example: some people were using it, some people didn't and those two \ngroups couldn't help each other efficiently. Yet git used to do things \nbadly that cogito did well, and the other way around too, which gave the \nimpression that each system was suboptimal. When git picked up the good \nthings in cogito and cogito finally died then everybody was focusing on \na single command-line-based porcelain for the better health of git which \nreally gained momentum at that point.\n\nIn that sense, an alternative (command line) porcelain is effectively a \nfork. Forks are good for experimental stuff and the like, but \neventually it is always best for everyone involved if the better parts \nof the fork are merged back. Any project with a fork that grew big and \ndidn't merge back made the whole community weaker in the long run.\n\n> If new and useful features (e.g. \"creating a remote repository over SSH in\n> one shot\") are supported by another Porcelain (e.g. \"eg\") they may be\n> worth porting over to git-core, in order to make git-core more usable.\n> There is a precedent for that kind of side port (e.g. \"filter-branch\" that\n> came from Cogito).\n> \n> But aliases for doing essentially the same thing in slightly different\n> syntax? I'd rather not to see them called \"git foo\". In the end, I think\n> it will harm the users, both new and old.\n\nAgain this should be evaluated on a case by case basis. I think this is \nclear already that re-targeting commands like revert is _not_ a good \nidea. But some other examples are not so controversial.\n\n> If you go back to the list archive, you will find me suggesting a new set\n> of commands with \"gh\" prefix, back in 1.3.X days, I think.\n> \n> I was not joking. The reasoning was exactly the same, and it remains so.\n\nAnd my opinion as explained above is that it is not a good idea. Your \nsuggestion didn't take off for a good reason.\n\n\nNicolas\n"},{"id":"115978","messageId":"20090610033211.GA7411@mit.edu","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906091535410.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2009-06-10T03:32:11Z","receivedAt":"2009-06-10T03:32:11Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jun 09, 2009 at 03:40:35PM -0700, Linus Torvalds wrote:\n> I also don't mind per se having the \"git checkout\" kind of semantics, \n> where different kinds of arguments result in different kinds of behavior. \n> I'm not convinced it's a wonderful design, but I would not object to\n> \n> - old behavior: revert the commit by creating an \"anti-commit\":\n> \n> \tgit revert \n> \n> - new extension: revert the state of the working tree to the HEAD:\n> \n> \tgit revert [--] pathspec\n> \n> which would kind of match the semantics of \"git checkout\" does.\n\nMy personal opinion is this kind of overloading is actually more\nconfusing than simply adding a new name, such as \"git revert-file\".\nOf course, you can do that already using a git alias.... So IMHO the\nbest way of handling this issue is to have git tutorials use this as a\nteachable moment, so people can create their own git alias for \"git\ncheckout HEAD --\".\n\n \t \t \t \t \t - Ted\n"},{"id":"115980","messageId":"alpine.LFD.2.01.0906092058430.6847@localhost.localdomain","threadId":"19763","inReplyTo":"20090610033211.GA7411@mit.edu","subject":"Re: EasyGit Integration","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-06-10T04:03:54Z","receivedAt":"2009-06-10T04:03:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 9 Jun 2009, Theodore Tso wrote:\n> \n> My personal opinion is this kind of overloading is actually more\n> confusing than simply adding a new name, such as \"git revert-file\".\n\nI'd agree, except I think it actually worked pretty well in \"git \ncheckout\". \n\nThe alternative was to add yet another command for that, or to teach \npeople about the internal commands we did have. Adding the capability for \ncheckout to check out individual files - in addition to commits and \nbranches - I think worked pretty well.\n\nAnd \"git checkout\" in many ways is an even more complicated case, much \nmore so than the suggested \"git revert\".\n\nNow, I also happen to think that \"git checkout [cmit] -- pathspec\" is a \nmuch more _logical_ name for what the SVN people apparently call \"revert\", \nbut hey, whatever. If SVN people feel happier about writing \"git revert \n\", then why not?\n\nBut I certainly won't argue very sternuously for adding that whole new \n\"git revert [cmit] [--] \" syntax. I can certainly live without \nit. I don't think it would be a disaster, though.\n\n\t\tLinus\n"},{"id":"115981","messageId":"51419b2c0906092120o56db640cg2fcf77c11e7b7f42@mail.gmail.com","threadId":"19763","inReplyTo":"20090610033211.GA7411@mit.edu","subject":"Re: EasyGit Integration","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-06-10T04:20:45Z","receivedAt":"2009-06-10T04:20:45Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jun 9, 2009 at 9:32 PM, Theodore Tso wrote:\n> My personal opinion is this kind of overloading is actually more\n> confusing than simply adding a new name, such as \"git revert-file\".\n> Of course, you can do that already using a git alias....  So IMHO the\n> best way of handling this issue is to have git tutorials use this as a\n> teachable moment, so people can create their own git alias for \"git\n> checkout HEAD --\".\n\nSo I have a few problems with such an alias:\n* It fails to work during an initial commit (\"git revert-files\nnew-file\" -> \"fatal: invalid reference: HEAD\")\n* When not working on the initial commit, it will silently do nothing\nwhen given a newly added file rather than undoing the add\n* As a side effect of the above, trying to undo all changes via \"git\nrevert-files .\" does not actually work; any newly added files will\nstill remain staged.\n* It makes no sense during an incomplete merge (why is HEAD more\nspecial than other refs in $git_dir/MERGE_HEAD? Shouldn't the user\nneed to specify which ref to revert relative to in such a case?)\n* It can't be used to revert a file back to a revision prior to HEAD\n(and 'git checkout OLDER_COMMIT -- FILE' in such a case isn't always\nthe right match either as it can leave the file in the working copy\nwhen it should be removed).\n* It provides no option to make the changes to just the index or just\nthe working copy; it always affects both (which is the right default,\nbut sometimes I like making changes to just one of those two places).\n\n\"git checkout -- ...\" really is a different command\nthan the \"revert\" of svn, bzr, darcs, or mercurial. There's clearly a\nlot of overlap, but they're not the same. I fear that claiming they\nare equivalent will at some point just cause extra confusion for new\ngit users.\n\n\nElijah\n"},{"id":"115984","messageId":"m3hbyo4mis.fsf@localhost.localdomain","threadId":"19763","inReplyTo":"4A2F1FD0.8060303@vilain.net","subject":"Re: EasyGit Integration","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-06-10T06:43:14Z","receivedAt":"2009-06-10T06:43:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain writes:\n> Junio C Hamano wrote:\n>>\n>>> I think as long as there is a deprecation cycle, and that users can\n>>> select the old behaviour (either via an alias or a config option), then\n>>> we shouldn't upset many long-time users of revert. Do you agree?\n>>> \n>>\n>> I actually don't.\n>>\n>> I do not think introducing \"git revert-file\" (or \"git revert -- path\") is\n>> a problem at all. But \"git revert $commit\" has been and is an integral\n>> part of the established git workflow, and I do not see a point in changing\n>> it to mean something else, with any deprecation period.\n>> \n> \n> Ok. Off-hand I can't remember why we excluded \"git revert -- path\" as\n> workable. Whatever that reason was led to the group of core developers\n> coming up with these \"clearly\" \"_inferior_\" names.\n\n\"git revert -- path\" is perhaps not unambiguous (but for the fact\nwhether it reverts from index, or from HEAD), but \"git revert -- path\"\ncan be understood as \"git cherry-pick -R -- path\" i.e. reverting\nchanges to given file or files in a commit.\n\nAnd we have \"git reset -- file\", don't we.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"116005","messageId":"20090610121349.GA27679@atjola.homenet","threadId":"19763","inReplyTo":"32541b130906091342s7dd6064fud2205bee8af95aab@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-06-10T12:13:49Z","receivedAt":"2009-06-10T12:13:49Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.06.09 16:42:33 -0400, Avery Pennarun wrote:\n> 2009/6/9 Björn Steinbrink :\n> > On 2009.06.09 15:52:46 -0400, Avery Pennarun wrote:\n> >> To be honest, I'm not convinced svn's use of the word \"revert\" is\n> >> really right, though.  Git's isn't *really* right either, since it\n> >> actually makes a new commit, it doesn't remove the old one like it\n> >> sounds like it does.  Maybe 'reverse' would be a better name for what\n> >> git does, and we should just introduce another word for what svn does.\n> >>  (With CVS, you just deleted the file and then did a checkout/update\n> >> on it again, which made sense to me.  That works in git too.)\n> >>\n> >> Crazy idea: we could actually make 'git revert' do both: given a\n> >> commit, it applies the reverse as it does now.  Given filenames, it\n> >> simply brings them back to HEAD.  But maybe that's too crazy.\n> >\n> > Doesn't seem that crazy to me. But maybe a bit problematic if you want\n> > to support both, \"git checkout -- .\" and \"git checkout HEAD -- .\". And\n> > adding DWIMmery there seems dangerous, as in:\n> >\n> > git revert == git checkout -- .\n> >\n> > git revert HEAD ==\n> >  no uncommitted changes = revert commit HEAD\n> >  uncommitted changes = revert to HEAD\n> \n> Well, that's what I meant by \"crazy\" :)\n\nOK, thinking about it, I really dislike the idea of \"revert --since\",\nas that is IMHO better thought of as \"get the old version back\", and for\n\"get something out of the repo\" we have checkout. That would leave us\nwith \"revert changes from a commit\" and \"revert uncommitted/unstaged\nchanges\". For that \"limited\" thing, I could live with:\n\ngit revert # As is\ngit revert --unstaged # git checkout -- \ngit revert --uncommitted # git checkout HEAD -- / git rm --cached\n\nIOW: Mode of operation is chosen by a flag, which has a meaning that is\nsomewhat similar to --cached for diff/rm, it chooses what to use as the\nsource for the operation. And as at least \"revert --uncommitted\" isn't\n100% the same as \"checkout HEAD --\", I think the overlap that we'd have\nwith a small subset of the checkout functionality might be ok.\n\nBjörn\n"},{"id":"116006","messageId":"vpqljo045ex.fsf@bauges.imag.fr","threadId":"19763","inReplyTo":"51419b2c0906091500q6aaff225q42bd79e6349a1143@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-06-10T12:52:38Z","receivedAt":"2009-06-10T12:52:38Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Elijah Newren writes:\n\n>> Some other things that might be nice:\n>>\n>> * 'git backout' for 'git reset HEAD^'\n>\n> May cause confusion for mercurial users (hg backout == current git\n> revert).\n\nYes, and a bit of consistency between the various (D)VCS would be good\n(for regular-hg-users which are also occasional-git-users and so).\n\n> I don't have a better proposal, though. 'uncommit'?\n\nI like 'uncommit'. That's what bzr uses.\n\n-- \nMatthieu\n"},{"id":"116012","messageId":"vpqzlcgxid5.fsf@bauges.imag.fr","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906091535410.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-06-10T14:40:06Z","receivedAt":"2009-06-10T14:40:06Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> I would not object to\n>\n> - old behavior: revert the commit by creating an \"anti-commit\":\n>\n> \tgit revert \n>\n> - new extension: revert the state of the working tree to the HEAD:\n>\n> \tgit revert [--] pathspec\n>\n> which would kind of match the semantics of \"git checkout\" does.\n\nThat's subjective, but I would find this more misleading than the\ncurrent behavior. To me, that would let beginners think that both\ncommands do similar things, and then \"why the hell does git revert\nHEAD^^ create a commit while git revert -- foo.c doesn't???\"-kind of\nquestions.\n\nmy 2 cents,\n\n-- \nMatthieu\n"},{"id":"116018","messageId":"d411cc4a0906100948qd499996o8d092686a1643167@mail.gmail.com","threadId":"19763","inReplyTo":"7vws7khlvj.fsf@alter.siamese.dyndns.org","subject":"Re: EasyGit Integration","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2009-06-10T16:48:22Z","receivedAt":"2009-06-10T16:48:22Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Tue, Jun 9, 2009 at 7:18 PM, Junio C Hamano wrote:\n> I do not think introducing \"git revert-file\" (or \"git revert -- path\") is\n> a problem at all.  But \"git revert $commit\" has been and is an integral\n> part of the established git workflow, and I do not see a point in changing\n> it to mean something else, with any deprecation period.\n\nI would vote for simply adding 'revert-file' rather than overloading\nanother command with two completely different actions.\n\n> It will bloat the total number of subcommands you can give git, with the\n> end result being\n\nIt just seems that this is sort of a paving the cow paths practice - I\nsee a lot of people creating aliases for 'unstage' and 'revert-file'\nand 'uncommit' and things that are relatively common but difficult to\nremember how to do because they have very obscure syntaxes\n(syntaxen?).\n\nWorrying about subcommand bloat seems a tad silly at this point given\nthat there are over 150 valid verbs now, right? If existing commands\ndo categorically different things depending on input values, doesn't\nit make sense to simply have different verbs exist for each separate\naction? I mean, worrying about the usability issue of having too many\ncommands but not thinking that making users learn 'git reset HEAD\npath' is an issue seems really strange to me.\n\n> If \"eg\" (I do not have _anything_ against it; the discussion applies to\n> other Porcelains as well) were kept independent _and_ offered complete set\n> of features that users need without resorting to git-core, on the other\n> hand, the students do not have to know about \"revert\", and the manuals\n> they need to consult will not have to talk about \"if you are using\n> git-core, this is done differently in this way\".  The learning curve will\n> get a lot smoother for new people.\n\nI think I understand the argument here, but I really, really don't\nwant to suggest to people to install Git and then install a separate\nporcelain, and then have them spend time learning a command set that\nis completely absent from other machines that have Git installed. I\nrealize this is also an issue with adding new commands (in that they\nwould be absent from machines with older Git installed) but that issue\nfades away after a few years, where the previous does not - in fact,\nit becomes a far more difficult problem.\n\nIf it's not installed with 'apt-get git-core' or what have you, then I\n(and I assume others) are never going to waste everyones time teaching\nthem a niche tool they will never find elsewhere.\n\n> But aliases for doing essentially the same thing in slightly different\n> syntax?  I'd rather not to see them called \"git foo\".  In the end, I think\n> it will harm the users, both new and old.\n\nIt would be one thing if I were suggesting that 'git revert' be\nchanged to 'git regress' or something - it's not a simple naming\nissue. It's more that things like \"git reset HEAD ...\" to\nunstage simply makes no sense unless you have a pretty technical\nunderstanding of reset, the index and HEAD - none of which a beginning\nuser should need to learn right off the bat. Unstaging files _is_,\nhowever, something that a brand new user will need to do right off the\nbat. The only paths left to them, then, are either learning the\ntechnical details of the index and 'reset' to understand why that\ncommand makes sense, or to simply learn the command by rote - which is\nnearly always what ends up happening, since it's incredibly difficult\nto learn the index well. Hell, I've been using Git pretty extensively\nfor years now and I still have a hard time remembering exactly what\n'reset' will do in different circumstances.\n\nEasy things that users have to do a lot should be easy, is all.\nBesides just being nice for users, it would probably save a lot of\ngrief for you guys with people asking and complaining about these\nthings on this list and the IRC channel.\n\n> If you go back to the list archive, you will find me suggesting a new set\n> of commands with \"gh\" prefix, back in 1.3.X days, I think.\n> I was not joking.  The reasoning was exactly the same, and it remains so.\n\nAgain, having to explain to people \"most of the time you use gh for\nall this stuff, but occasionally you use 'git'\" or vice-versa is just\nconfusing and error prone. Introducing some command denormalization\nfor the sake of getting new users on their feet with less friction\nseems less painful both for the developers and experts having to help\nsaid users and for the users themselves.\n\nI wasn't suggesting a core rewrite, I just thought that hitting some\nof this low hanging fruit - again, paving the cow paths as it were -\nmight be relatively painless and save everyone a lot of time.\n\nScott\n"},{"id":"116032","messageId":"7vab4fn7dm.fsf@alter.siamese.dyndns.org","threadId":"19763","inReplyTo":"alpine.LFD.2.00.0906092252210.31536@xanadu.home","subject":"Re: EasyGit Integration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-10T20:47:33Z","receivedAt":"2009-06-10T20:47:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On the other hand, having multiple porcelains simply divide the user \n> base which is not always a good thing.\n\nThe addition of new synonymous commands or options has the same issue of\ndividing the user base between revert-commit/revert-file folks and\nrevert/checkout people. In addition, it has the subcommand bloat issue I\nalready mentioned. If anything, we should be aiming for _reducing_ them\nfrom the current set of ~150; it is silly to dismiss it, saying \"one extra\nadded to 150 is less than 1%\".\n\nAs long as the \"fork\" is feature complete and the user does not have to\nresort to git-core, even though it may share the same issue of user base\ndivision, at least that would _help_ the users who choose the forked one,\nwho does not have to know the old-timer lingo and concepts. It would be a\nmuch better solution than adding stupid synonyms to the existing system.\n\nBut coming up with a consistent and complete fork that does not show\ngit-core (not just phrases but also underlying concepts) is a lot of work.\nThat is the primary reason why nobody did \"gh\".\n\n>> But aliases for doing essentially the same thing in slightly different\n>> syntax? I'd rather not to see them called \"git foo\". In the end, I think\n>> it will harm the users, both new and old.\n>\n> Again this should be evaluated on a case by case basis. I think this is \n> clear already that re-targeting commands like revert is _not_ a good \n> idea. But some other examples are not so controversial.\n\nI do not think there is any disagreement here; each proposal must be\njudged separately, and no backward compatibility is allowed, unless there\nis a compelling reason, a clear migration plan, and understanding of how\nexpensive such a backward incompatibility is by all the parties involved.\n\nI do not see how \"git branch -s\" is an improvement, unless our motto is\n\"we will support any and all conceivable permutations of what is done to\nwhat\". It says \"while creating a branch, switch to it\". We say \"while\nswitching to a new commit, start a branch by given name there\".\n\nI'd throw it into \"if we did not have X in the beginning, instead of\nadding X, we could have added Y and it would have worked equally well\"\ncategory.\n\nBut we already have X.\n\nA rule of thumb I use for judging such a case is that Y must be at least\n10 times better than X to replace it, and that has to happen with some\ndeprecation period. Supporting Y in addition to X may probably have lower\nhurdle, but still Y must be much better than X for that to happen.\n\nIf \"git resolved\" is \"git add $(git ls-files -u --name-only)\" or even more\nthan that (say, check if the files from the work tree indeed have lost\nconflict markers), I think that is a wonderful improvement. It does not\neven fall into the \"Y would have worked equally well but we have X\"\ncategory, as it is something different from the existing command, and does\nit better (if it works as advertised without funny corner cases, that is).\n"},{"id":"116043","messageId":"94a0d4530906101504j7928b0aaqff4c30c5136eec44@mail.gmail.com","threadId":"19763","inReplyTo":"d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-10T22:04:32Z","receivedAt":"2009-06-10T22:04:32Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Jun 9, 2009 at 9:59 PM, Scott Chacon wrote:\n> Hey all,\n>\n> I have been playing with the EasyGit project lately and I have been\n> really impressed.  I looked back to the last announcement here and the\n> conversation didn't really go anywhere, sadly.  I thought it might be\n> nice to adopt or at least consider a number of the design decisions\n> they made in modifying the defaults and commands available.  Perhaps\n> as a 1.7 goal or something?  I like it because it addresses a lot of\n> the issues that I hear from beginning users:\n>\n> * breaks the various things that 'checkout' does into separate\n> commands - moves 'revert' to doing what 'checkout -- path' does, moves\n> current 'revert' to 'cherry-pick --revert' (which someone mentioned\n> was a good idea at the last GitTogether), and adds 'unstage' for\n> 'reset HEAD file'.  also adds a '-s' option to 'branch' to switch to\n> the branch after you create it, which many people expect rather than\n> 'checkout -b'.\n\nI like 'git unstage', but not the rest.\n\n> * adds 'git resolved' for 'git add', which I hear all the time as\n> being confusing\n\nI would prefer 'git stage'; 'git resolved' seems to be meant for a\nvery particular case: resolve conflicts, it would be much better to\nlearn that you can do 'git stage' at any time.\n\n\n\n> * 'git backout' for 'git reset HEAD^'\n\nI don't like that. Looks like a very specialized case. It's much\nbetter to learn this particular use of 'git reset'.\n\n> * 'git push origin --delete ' for 'git push origin :branch'\n\nThat would be really good, it took me a lot of time to find that idiom.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"116044","messageId":"94a0d4530906101515k3656a895kd36f8477d3a37b5f@mail.gmail.com","threadId":"19763","inReplyTo":"7vws7khlvj.fsf@alter.siamese.dyndns.org","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-10T22:15:16Z","receivedAt":"2009-06-10T22:15:16Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Jun 10, 2009 at 5:18 AM, Junio C Hamano wrote:\n> Sam Vilain writes:\n>\n>> We talked about this much at GitTogether '08. It's true that for\n>> 'reverting' a change in the past, that is the right thing to do. However\n>> I don't think there is a first principles case that this is always what\n>> people mean by 'revert'....\n>\n> Sorry; what you think people mean by 'revert' does not matter at this\n> point, unless you are building a brand-new system from scratch.\n\nSubversion is by far the most widely used VCS, it's quite likely that\nnew git users will come from the svn camp (I know I did), and it's\nquite likely they will assume 'revert' is doing what svn does. Do you\nthink that doesn't matter at all?\n\nYou might think that 'git revert' is superior to 'svn revert' (and I\nhappen to agree with that statement), but at least you should take\ninto consideration the huge amount of users that would find this\nbehavior strange.\n\nPersonally, I would add a note to the 'git revert' documentation to be\nextra-clear what 'git revert' is not.\n\n-- \nFelipe Contreras\n"},{"id":"116046","messageId":"51419b2c0906101528k66d99f7avfbb5adb8972a6fe1@mail.gmail.com","threadId":"19763","inReplyTo":"7vab4fn7dm.fsf@alter.siamese.dyndns.org","subject":"Re: EasyGit Integration","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-06-10T22:28:35Z","receivedAt":"2009-06-10T22:28:35Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Jun 10, 2009 at 2:47 PM, Junio C Hamano wrote:\n> As long as the \"fork\" is feature complete and the user does not have to\n> resort to git-core, even though it may share the same issue of user base\n> division, at least that would _help_ the users who choose the forked one,\n> who does not have to know the old-timer lingo and concepts.  It would be a\n> much better solution than adding stupid synonyms to the existing system.\n>\n> But coming up with a consistent and complete fork that does not show\n> git-core (not just phrases but also underlying concepts) is a lot of work.\n> That is the primary reason why nobody did \"gh\".\n\nWhat would you think of adding eg to contrib?\n"},{"id":"116045","messageId":"94a0d4530906101531ja6f1deeob703f546d62e7599@mail.gmail.com","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906092058430.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-10T22:31:57Z","receivedAt":"2009-06-10T22:31:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Jun 10, 2009 at 7:03 AM, Linus\nTorvalds wrote:\n>\n>\n> On Tue, 9 Jun 2009, Theodore Tso wrote:\n>>\n>> My personal opinion is this kind of overloading is actually more\n>> confusing than simply adding a new name, such as \"git revert-file\".\n>\n> I'd agree, except I think it actually worked pretty well in \"git\n> checkout\".\n>\n> The alternative was to add yet another command for that, or to teach\n> people about the internal commands we did have. Adding the capability for\n> checkout to check out individual files - in addition to commits and\n> branches - I think worked pretty well.\n\nWhy? What makes 'git checkout ' and 'git checkout --\n' similar at all? I would expect 'git checkout ' to be\nthe same as 'git checkout -- .'\n\nIn my mind these are 2 completely different commands.\n\n-- \nFelipe Contreras\n"},{"id":"116048","messageId":"alpine.LFD.2.01.0906101555590.6847@localhost.localdomain","threadId":"19763","inReplyTo":"94a0d4530906101531ja6f1deeob703f546d62e7599@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-06-10T23:04:49Z","receivedAt":"2009-06-10T23:04:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 11 Jun 2009, Felipe Contreras wrote:\n\n> On Wed, Jun 10, 2009 at 7:03 AM, Linus\n> Torvalds wrote:\n> >\n> >\n> > On Tue, 9 Jun 2009, Theodore Tso wrote:\n> >>\n> >> My personal opinion is this kind of overloading is actually more\n> >> confusing than simply adding a new name, such as \"git revert-file\".\n> >\n> > I'd agree, except I think it actually worked pretty well in \"git\n> > checkout\".\n> >\n> > The alternative was to add yet another command for that, or to teach\n> > people about the internal commands we did have. Adding the capability for\n> > checkout to check out individual files - in addition to commits and\n> > branches - I think worked pretty well.\n> \n> Why? What makes 'git checkout ' and 'git checkout --\n> ' similar at all? I would expect 'git checkout ' to be\n> the same as 'git checkout -- .'\n\nYou don't understand.\n\n\"git checkout\" would be similar to \"git revert\", if we did that change. \n\nIOW, both would be \"if you give it a commit, it acts at a commit level\", \nand \"if you give it pathnames, it acts on a pathname level\".\n\nThat is totally obvious, and not in the least confusing. They are two \ndifferent things, but at the same time, there is no question about which \nis which. \n\n> In my mind these are 2 completely different commands.\n\nThey are two different things, but they both make sense within the \n_context_.\n\nOnly earthworms and FOX news have no concept of \"in context\". So it does \nmake sense to say \"git checkout filename\" (and expect it to check out that \n_filename_ - surprise surprise), and also say \"git checkout branch\" (and \nexpect it to check out that branch - again, big surprise).\n\nHumans are generally _very_ good at seeing the same word in two different \ncontexts, and not being confused at all. There is no confusion when I talk \nabout SCM's in the context of git, even though \"SCM\" could also mean a \nSceme interpreter, or \"Saskatchewan College of Midwives\".\n\nIn fact, it is often *much* better to accept context-awareness, than to \ntry too hard to be \"uniquely identifying\" even without context. \n\nOf course, you do want things to also be unambiguous. But that's why we \nhave things like that \"--\" thing, when we want to specify pathspecs \nexplicitly and don't want to accept any kind of ambiguity. Most humans \ntend to leave them out, and that \"--\" thing shows up mostly in git \nscripts.\n\n\t\t\tLinus\n"},{"id":"116049","messageId":"d411cc4a0906101657v601aba20q5708e114fc7d4bca@mail.gmail.com","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906101555590.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2009-06-10T23:57:03Z","receivedAt":"2009-06-10T23:57:03Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Wed, Jun 10, 2009 at 4:04 PM, Linus\nTorvalds wrote:\n>\n> IOW, both would be \"if you give it a commit, it acts at a commit level\",\n> and \"if you give it pathnames, it acts on a pathname level\".\n>\n> That is totally obvious, and not in the least confusing. They are two\n> different things, but at the same time, there is no question about which\n> is which.\n>\n>> In my mind these are 2 completely different commands.\n>\n> They are two different things, but they both make sense within the\n> _context_.\n>\n> Only earthworms and FOX news have no concept of \"in context\". So it does\n> make sense to say \"git checkout filename\" (and expect it to check out that\n> _filename_ - surprise surprise), and also say \"git checkout branch\" (and\n> expect it to check out that branch - again, big surprise).\n\nThe problem here is that you're using 'check out' in your descriptions\nof the expectations to mean two different things. One means 'switch\nbranches' and the other means 'extract content'. If you provide both\na branch and a filename, what happens? It still means 'extract\ncontent'. Not everyone assumes that 'checkout' can or should mean\nboth of these things depending on context. I mean honestly, the\n'context' of 'git checkout branch' and 'git checkout branch file'\ndoesn't really look that much different, but the command completely\nswitches semantics from 'switch active branch' to 'extract content'.\nIt's not that the command assumes some subtle defaults depending on\nwhat arguments you give it - it's that it completely changes the\nnature of what it does depending on the arguments. It only makes\nsense to us because we specifically learned that it did this, not\nbecause it makes sense intuitively. Hell, _neither_ of these meanings\nare what SVN-inbound users are used to, which they map to 'extract\ncontent _from a remote server_'.\n\n>\n> Humans are generally _very_ good at seeing the same word in two different\n> contexts, and not being confused at all. There is no confusion when I talk\n> about SCM's in the context of git, even though \"SCM\" could also mean a\n> Sceme interpreter, or \"Saskatchewan College of Midwives\".\n>\n> In fact, it is often *much* better to accept context-awareness, than to\n> try too hard to be \"uniquely identifying\" even without context.\n\nThis may be generally true for conversational language, but that\ndoesn't really cleanly apply here. If your vocabulary is only like 15\nwords (common porcelain commands), why would one of them be ambiguous\noutside of context? Even given proper context, we're still being\narbitrary about how that command is interpreted - what if they wanted\nto 'extract content' of all the files from another branch? Having\nlearned that 'git checkout ' extracts content of that file and\n'git checkout ' extracts the contents of that file from\nthat branch, why wouldn't one assume that 'git checkout '\nextracts the content of all the files in that branch? Wouldn't that\nmake more sense than arbitrarily doing something completely unrelated\n('switching active branch')?\n\nI'm not just arguing for arguments sake - I'm relaying from\nindividuals I'm trying to teach this to that they find it confusing.\nThis is not a theoretical argument, it is real world user feedback. I\nprobably struggled with things like this a bit at first and then\nlearned the idiosyncrasies of the tool and just accepted it like most\nof the rest of us have - but many people honestly get confused and\nfrustrated by it. I see many of us helping people on IRC and whatnot\nwith this type of thing all the time.\n\nI understand that clarity and ease of use is not really of primary\nimportance to this project. However, is it not slightly ironic that\nthe Git project is so obsessed with squeezing 5% or 10% of raw speed\nout of each command, yet feels that the onus should be on each user to\nstudy for hours to memorize a bunch of arbitrary idiosyncrasies of the\ntool? Can we not obsess a little about flattening the learning curve\n10% as well (possibly at the slight expense of command normalization\nor verb bloat)?\n\nScott\n"},{"id":"116051","messageId":"m38wjz4odq.fsf@localhost.localdomain","threadId":"19763","inReplyTo":"d411cc4a0906101657v601aba20q5708e114fc7d4bca@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-06-11T00:15:53Z","receivedAt":"2009-06-11T00:15:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Scott Chacon writes:\n> On Wed, Jun 10, 2009 at 4:04 PM, Linus\n> Torvalds wrote:\n> >\n> > IOW, both would be \"if you give it a commit, it acts at a commit level\",\n> > and \"if you give it pathnames, it acts on a pathname level\".\n> >\n> > That is totally obvious, and not in the least confusing. They are two\n> > different things, but at the same time, there is no question about which\n> > is which.\n> >\n> >> In my mind these are 2 completely different commands.\n> >\n> > They are two different things, but they both make sense within the\n> > _context_.\n> >\n> > Only earthworms and FOX news have no concept of \"in context\". So it does\n> > make sense to say \"git checkout filename\" (and expect it to check out that\n> > _filename_ - surprise surprise), and also say \"git checkout branch\" (and\n> > expect it to check out that branch - again, big surprise).\n> \n> The problem here is that you're using 'check out' in your descriptions\n> of the expectations to mean two different things. One means 'switch\n> branches' and the other means 'extract content'.\n\nIn both cases it means getting something out of repository (checking\nout) and into working area.\n\n> If you provide both\n> a branch and a filename, what happens? It still means 'extract\n> content'. \n\nIf there is a filename, then it is checking out a file or files.\nIf there is no filename, then it is checking out a commit.\n\nChecking out commit means switching branch if it is branch name,\ndetaching HEAD if it is not branch name.\n\nWhen you are checking out a file or set of files, you cannot change\nbranch; commit is state of a whole project, not of individual files.\n\n> Not everyone assumes that 'checkout' can or should mean\n> both of these things depending on context. I mean honestly, the\n> 'context' of 'git checkout branch' and 'git checkout branch file'\n> doesn't really look that much different, but the command completely\n> switches semantics from 'switch active branch' to 'extract content'.\n\nNote that \"git checkout \" was first (well, it was only \n\"git checkout \" then.\n\n> It's not that the command assumes some subtle defaults depending on\n> what arguments you give it - it's that it completely changes the\n> nature of what it does depending on the arguments. It only makes\n> sense to us because we specifically learned that it did this, not\n> because it makes sense intuitively. Hell, _neither_ of these meanings\n> are what SVN-inbound users are used to, which they map to 'extract\n> content _from a remote server_'.\n\nSo perhaps _understanding_ those commands require understanding git\nmodel. I don't see how this is a bad thing. You would have to learn\nit anyway... ;-)\n\n[...]\n> I understand that clarity and ease of use is not really of primary\n> importance to this project. However, is it not slightly ironic that\n> the Git project is so obsessed with squeezing 5% or 10% of raw speed\n> out of each command, yet feels that the onus should be on each user to\n> study for hours to memorize a bunch of arbitrary idiosyncrasies of the\n> tool? Can we not obsess a little about flattening the learning curve\n> 10% as well (possibly at the slight expense of command normalization\n> or verb bloat)?\n\nThe problem is bakcward compatibility and the fact that git was not as\nmuch as designed, as it has grown. Which is very good solution for\ngetting good feature set, but not so much for an UI...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"116052","messageId":"94a0d4530906101718r4bd6b127y40e6e524afc5f38f@mail.gmail.com","threadId":"19763","inReplyTo":"alpine.LFD.2.01.0906101555590.6847@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-11T00:18:47Z","receivedAt":"2009-06-11T00:18:47Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 11, 2009 at 2:04 AM, Linus\nTorvalds wrote:\n>\n>\n> On Thu, 11 Jun 2009, Felipe Contreras wrote:\n>\n>> On Wed, Jun 10, 2009 at 7:03 AM, Linus\n>> Torvalds wrote:\n>> >\n>> >\n>> > On Tue, 9 Jun 2009, Theodore Tso wrote:\n>> >>\n>> >> My personal opinion is this kind of overloading is actually more\n>> >> confusing than simply adding a new name, such as \"git revert-file\".\n>> >\n>> > I'd agree, except I think it actually worked pretty well in \"git\n>> > checkout\".\n>> >\n>> > The alternative was to add yet another command for that, or to teach\n>> > people about the internal commands we did have. Adding the capability for\n>> > checkout to check out individual files - in addition to commits and\n>> > branches - I think worked pretty well.\n>>\n>> Why? What makes 'git checkout ' and 'git checkout --\n>> ' similar at all? I would expect 'git checkout ' to be\n>> the same as 'git checkout -- .'\n>\n> You don't understand.\n>\n> \"git checkout\" would be similar to \"git revert\", if we did that change.\n>\n> IOW, both would be \"if you give it a commit, it acts at a commit level\",\n> and \"if you give it pathnames, it acts on a pathname level\".\n>\n> That is totally obvious, and not in the least confusing. They are two\n> different things, but at the same time, there is no question about which\n> is which.\n\nI'm opposed to 'git revert -- ' for many reasons, one of which\nis; you might want to grab some files that are in a future commit.\nReverting to the future is weird, unless you did a previous revert\nbackwards.\n\nI do understand the two different 'git checkout' modes, that's not the\npoint, my point is the question you didn't answer; what does 'git\ncheckout ' and 'git checkout -- ' have in common?\n\nTo me it seems the only thing they have in common is the name.\n\n>> In my mind these are 2 completely different commands.\n>\n> They are two different things, but they both make sense within the\n> _context_.\n>\n> Only earthworms and FOX news have no concept of \"in context\". So it does\n> make sense to say \"git checkout filename\" (and expect it to check out that\n> _filename_ - surprise surprise), and also say \"git checkout branch\" (and\n> expect it to check out that branch - again, big surprise).\n>\n> Humans are generally _very_ good at seeing the same word in two different\n> contexts, and not being confused at all. There is no confusion when I talk\n> about SCM's in the context of git, even though \"SCM\" could also mean a\n> Sceme interpreter, or \"Saskatchewan College of Midwives\".\n\nSuppose you have a 'debian' branch, and a 'debian' directory, what\ndoes this command do?\ngit checkout debian\n\nSure, I'm not an earthworm, so I can guess that command means checkout\nthe debian branch because it's a much more common action. But git\ndoesn't know that, you need to do:\ngit checkout debian --\n\nIf I know I want to checkout a branch I would like to do:\ngit debian\n\n> In fact, it is often *much* better to accept context-awareness, than to\n> try too hard to be \"uniquely identifying\" even without context.\n>\n> Of course, you do want things to also be unambiguous. But that's why we\n> have things like that \"--\" thing, when we want to specify pathspecs\n> explicitly and don't want to accept any kind of ambiguity. Most humans\n> tend to leave them out, and that \"--\" thing shows up mostly in git\n> scripts.\n\nYeah, unless git finds it ambiguous and the user is forced to learn a\nnew idiom in order to get rid of the ambiguity.\n\n-- \nFelipe Contreras\n"},{"id":"116053","messageId":"94a0d4530906101730p22053cbbl347eddd31b347c3c@mail.gmail.com","threadId":"19763","inReplyTo":"m38wjz4odq.fsf@localhost.localdomain","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-11T00:30:36Z","receivedAt":"2009-06-11T00:30:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski wrote:\n> Scott Chacon writes:\n>> On Wed, Jun 10, 2009 at 4:04 PM, Linus\n>> Torvalds wrote:\n>> >\n>> > IOW, both would be \"if you give it a commit, it acts at a commit level\",\n>> > and \"if you give it pathnames, it acts on a pathname level\".\n>> >\n>> > That is totally obvious, and not in the least confusing. They are two\n>> > different things, but at the same time, there is no question about which\n>> > is which.\n>> >\n>> >> In my mind these are 2 completely different commands.\n>> >\n>> > They are two different things, but they both make sense within the\n>> > _context_.\n>> >\n>> > Only earthworms and FOX news have no concept of \"in context\". So it does\n>> > make sense to say \"git checkout filename\" (and expect it to check out that\n>> > _filename_ - surprise surprise), and also say \"git checkout branch\" (and\n>> > expect it to check out that branch - again, big surprise).\n>>\n>> The problem here is that you're using 'check out' in your descriptions\n>> of the expectations to mean two different things.  One means 'switch\n>> branches' and the other means 'extract content'.\n>\n> In both cases it means getting something out of repository (checking\n> out) and into working area.\n\n'git reset' also gets something out of the repository and into the\nworking area, that's not reason enough to put them under the same\n'checkout' command, is it?\n\n> [...]\n>> I understand that clarity and ease of use is not really of primary\n>> importance to this project.  However, is it not slightly ironic that\n>> the Git project is so obsessed with squeezing 5% or 10% of raw speed\n>> out of each command, yet feels that the onus should be on each user to\n>> study for hours to memorize a bunch of arbitrary idiosyncrasies of the\n>> tool?  Can we not obsess a little about flattening the learning curve\n>> 10% as well (possibly at the slight expense of command normalization\n>> or verb bloat)?\n>\n> The problem is bakcward compatibility and the fact that git was not as\n> much as designed, as it has grown.  Which is very good solution for\n> getting good feature set, but not so much for an UI...\n\nBackwards compatibility must be broken at some point or another,\notherwise people will start to create their own aliases, alternative\nUI's and even forks. Sure, it must be done carefully and planned in\nadvance, that's why it's a good idea to keep a list of things to\nchange in the next interface break.\n\n-- \nFelipe Contreras\n"},{"id":"116054","messageId":"200906110242.57475.jnareb@gmail.com","threadId":"19763","inReplyTo":"94a0d4530906101730p22053cbbl347eddd31b347c3c@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-06-11T00:42:55Z","receivedAt":"2009-06-11T00:42:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 11 June 2009, Felipe Contreras wrote:\n> On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski wrote:\n>> Scott Chacon writes:\n>>> On Wed, Jun 10, 2009 at 4:04 PM, Linus\n>>> Torvalds wrote:\n>>>>\n>>>> IOW, both would be \"if you give it a commit, it acts at a commit level\",\n>>>> and \"if you give it pathnames, it acts on a pathname level\".\n>>>>\n>>>> That is totally obvious, and not in the least confusing. They are two\n>>>> different things, but at the same time, there is no question about which\n>>>> is which.\n>>>>\n>>>>> In my mind these are 2 completely different commands.\n>>>>\n>>>> They are two different things, but they both make sense within the\n>>>> _context_.\n>>>>\n>>>> Only earthworms and FOX news have no concept of \"in context\". So it does\n>>>> make sense to say \"git checkout filename\" (and expect it to check out that\n>>>> _filename_ - surprise surprise), and also say \"git checkout branch\" (and\n>>>> expect it to check out that branch - again, big surprise).\n>>>\n>>> The problem here is that you're using 'check out' in your descriptions\n>>> of the expectations to mean two different things.  One means 'switch\n>>> branches' and the other means 'extract content'.\n>>\n>> In both cases it means getting something out of repository (checking\n>> out) and into working area.\n> \n> 'git reset' also gets something out of the repository and into the\n> working area, that's not reason enough to put them under the same\n> 'checkout' command, is it?\n\nNope. 'git reset' resets something to the state in repository (to given\ncommit). The fact that some combination of options for 'git reset' gives\nthe same result as some specific combination of options of 'git checkout'\nmeans only that one can arrive at some destination in two different ways.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"116181","messageId":"94a0d4530906121357h63723278i7663c25707d3c754@mail.gmail.com","threadId":"19763","inReplyTo":"200906110242.57475.jnareb@gmail.com","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-12T20:57:44Z","receivedAt":"2009-06-12T20:57:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Jun 11, 2009 at 3:42 AM, Jakub Narebski wrote:\n> On Thu, 11 June 2009, Felipe Contreras wrote:\n>> On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski wrote:\n>>> Scott Chacon writes:\n>>>> On Wed, Jun 10, 2009 at 4:04 PM, Linus\n>>>> Torvalds wrote:\n>>>>>\n>>>>> IOW, both would be \"if you give it a commit, it acts at a commit level\",\n>>>>> and \"if you give it pathnames, it acts on a pathname level\".\n>>>>>\n>>>>> That is totally obvious, and not in the least confusing. They are two\n>>>>> different things, but at the same time, there is no question about which\n>>>>> is which.\n>>>>>\n>>>>>> In my mind these are 2 completely different commands.\n>>>>>\n>>>>> They are two different things, but they both make sense within the\n>>>>> _context_.\n>>>>>\n>>>>> Only earthworms and FOX news have no concept of \"in context\". So it does\n>>>>> make sense to say \"git checkout filename\" (and expect it to check out that\n>>>>> _filename_ - surprise surprise), and also say \"git checkout branch\" (and\n>>>>> expect it to check out that branch - again, big surprise).\n>>>>\n>>>> The problem here is that you're using 'check out' in your descriptions\n>>>> of the expectations to mean two different things.  One means 'switch\n>>>> branches' and the other means 'extract content'.\n>>>\n>>> In both cases it means getting something out of repository (checking\n>>> out) and into working area.\n>>\n>> 'git reset' also gets something out of the repository and into the\n>> working area, that's not reason enough to put them under the same\n>> 'checkout' command, is it?\n>\n> Nope. 'git reset' resets something to the state in repository (to given\n> commit).  The fact that some combination of options for 'git reset' gives\n> the same result as some specific combination of options of 'git checkout'\n> means only that one can arrive at some destination in two different ways.\n\nYou can describe what 'git reset' does in many ways, but in the\nprocess it's still getting something out of the repository and into\nthe working directory, does it not? 'git checkout ' and\n'git checkout -- ' also do that.\n\nIs that relevant? No. What is relevant is the final action the user is\nexpecting to achieve.\n\nTherefore, the fact that 'git checkout ' modifies the\nworking directory is irrelevant, it's still doing an extra step;\nupdate HEAD, and that final action is what is important for this\nparticular command; it switches to another commitish.\n\n-- \nFelipe Contreras\n"},{"id":"116182","messageId":"200906122321.57479.jnareb@gmail.com","threadId":"19763","inReplyTo":"94a0d4530906121357h63723278i7663c25707d3c754@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-06-12T21:21:55Z","receivedAt":"2009-06-12T21:21:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 12 Jun 2009, Felipe Contreras wrote:\n> On Thu, Jun 11, 2009 at 3:42 AM, Jakub Narebski wrote:\n>> On Thu, 11 June 2009, Felipe Contreras wrote:\n\n>>> 'git reset' also gets something out of the repository and into the\n>>> working area, that's not reason enough to put them under the same\n>>> 'checkout' command, is it?\n>>\n>> Nope. 'git reset' resets something to the state in repository (to given\n>> commit).  The fact that some combination of options for 'git reset' gives\n>> the same result as some specific combination of options of 'git checkout'\n>> means only that one can arrive at some destination in two different ways.\n> \n> You can describe what 'git reset' does in many ways, but in the\n> process it's still getting something out of the repository and into\n> the working directory, does it not? 'git checkout ' and\n> 'git checkout -- ' also do that.\n\nNope. 'git reset' always reset some part of state to a given commit,\nHEAD by default. It can reset current branch with --soft, branch plus\nindex with --mixed (default), and branch plus index plus working \ndirectory with --hard. Source is always commit.\n\n'git checkout' however checks out something into working directory.\nIt can be branch, in which turns it sets HEAD to point to it, and\nindex too. It can be file, in which it gets version of file from\nindex or (if specified) from given commit. Destination is always\nworking area (and sometimes something else beside it).\n\n> \n> Is that relevant? No. What is relevant is the final action the user is\n> expecting to achieve.\n> \n> Therefore, the fact that 'git checkout ' modifies the\n> working directory is irrelevant, it's still doing an extra step;\n> update HEAD, and that final action is what is important for this\n> particular command; it switches to another commitish.\n\nIt is not uncommon for a word to have different meaning depending on\ncontext, or on some auxiliary word used in addition...\n-- \nJakub Narebski\nPoland\n"},{"id":"116184","messageId":"94a0d4530906121448m57f272eej32e8d57e48002f1f@mail.gmail.com","threadId":"19763","inReplyTo":"200906122321.57479.jnareb@gmail.com","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-12T21:48:36Z","receivedAt":"2009-06-12T21:48:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski wrote:\n> On Fri, 12 Jun 2009, Felipe Contreras wrote:\n>> On Thu, Jun 11, 2009 at 3:42 AM, Jakub Narebski wrote:\n>>> On Thu, 11 June 2009, Felipe Contreras wrote:\n>\n>>>> 'git reset' also gets something out of the repository and into the\n>>>> working area, that's not reason enough to put them under the same\n>>>> 'checkout' command, is it?\n>>>\n>>> Nope. 'git reset' resets something to the state in repository (to given\n>>> commit).  The fact that some combination of options for 'git reset' gives\n>>> the same result as some specific combination of options of 'git checkout'\n>>> means only that one can arrive at some destination in two different ways.\n>>\n>> You can describe what 'git reset' does in many ways, but in the\n>> process it's still getting something out of the repository and into\n>> the working directory, does it not? 'git checkout ' and\n>> 'git checkout -- ' also do that.\n>\n> Nope. 'git reset' always reset some part of state to a given commit,\n> HEAD by default.  It can reset current branch with --soft, branch plus\n> index with --mixed (default), and branch plus index plus working\n> directory with --hard.  Source is always commit.\n\nYou said it: 'git reset --hard' gets something out of the repository\nand into the working directory.\n\nTry this:\ngit checkout \n\nThen what is the difference between:\ngit checkout HEAD^\ngit reset --hard HEAD^\n\nIn this case they do exactly the same thing, don't they?\n\n> 'git checkout' however checks out something into working directory.\n> It can be branch, in which turns it sets HEAD to point to it, and\n> index too.  It can be file, in which it gets version of file from\n> index or (if specified) from given commit.  Destination is always\n> working area (and sometimes something else beside it).\n>\n>>\n>> Is that relevant? No. What is relevant is the final action the user is\n>> expecting to achieve.\n>>\n>> Therefore, the fact that 'git checkout ' modifies the\n>> working directory is irrelevant, it's still doing an extra step;\n>> update HEAD, and that final action is what is important for this\n>> particular command; it switches to another commitish.\n>\n> It is not uncommon for a word to have different meaning depending on\n> context, or on some auxiliary word used in addition...\n\nWe are talking about a command here, not a command that has two slight\nvariations of the same main action, a command that is doing *two*\ncompletely unrelated actions depending on the context.\n\nThink about these 3 actions:\na) get a path out of a commit in the repository and into the working directory\nb) switch to another commit, reseting the working directory\nc) reset current branch to certain commit, and checkout into the\nworking directory\n\nThe 3 actions require putting something into the working directory;\nwhat makes a) and b) so similar they belong to the same command?\n\n-- \nFelipe Contreras\n"},{"id":"116187","messageId":"200906130005.20790.jnareb@gmail.com","threadId":"19763","inReplyTo":"94a0d4530906121448m57f272eej32e8d57e48002f1f@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-06-12T22:05:19Z","receivedAt":"2009-06-12T22:05:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 12 Jun 2009, Felipe Contreras wrote:\n> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski wrote:\n\n>> Nope. 'git reset' always reset some part of state to a given commit,\n>> HEAD by default.  It can reset current branch with --soft, branch plus\n>> index with --mixed (default), and branch plus index plus working\n>> directory with --hard.  Source is always commit.\n> \n> You said it: 'git reset --hard' gets something out of the repository\n> and into the working directory.\n> \n> Try this:\n> git checkout \n> \n> Then what is the difference between:\n> git checkout HEAD^\n> git reset --hard HEAD^\n> \n> In this case they do exactly the same thing, don't they?\n\nNo, they don't. \"git checkout HEAD^\" modifies HEAD detaching it.\n\"git reset --hard HEAD^\" modifies branch that HEAD points to (well,\nunless HEAD is detached).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"116190","messageId":"94a0d4530906121530m22dbfcb5ye63a0ecb400c4a59@mail.gmail.com","threadId":"19763","inReplyTo":"200906130005.20790.jnareb@gmail.com","subject":"Re: EasyGit Integration","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-06-12T22:30:38Z","receivedAt":"2009-06-12T22:30:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Jun 13, 2009 at 1:05 AM, Jakub Narebski wrote:\n> On Fri, 12 Jun 2009, Felipe Contreras wrote:\n>> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski wrote:\n>\n>>> Nope. 'git reset' always reset some part of state to a given commit,\n>>> HEAD by default.  It can reset current branch with --soft, branch plus\n>>> index with --mixed (default), and branch plus index plus working\n>>> directory with --hard.  Source is always commit.\n>>\n>> You said it: 'git reset --hard' gets something out of the repository\n>> and into the working directory.\n>>\n>> Try this:\n>> git checkout \n>>\n>> Then what is the difference between:\n>> git checkout HEAD^\n>> git reset --hard HEAD^\n>>\n>> In this case they do exactly the same thing, don't they?\n>\n> No, they don't.  \"git checkout HEAD^\" modifies HEAD detaching it.\n> \"git reset --hard HEAD^\" modifies branch that HEAD points to (well,\n> unless HEAD is detached).\n\nRead again:\n>> git checkout \n\nThe HEAD is detached, so they do exactly the same in this case.\n\n-- \nFelipe Contreras\n"},{"id":"116210","messageId":"20090613012431.GA1578@atjola.homenet","threadId":"19763","inReplyTo":"94a0d4530906121530m22dbfcb5ye63a0ecb400c4a59@mail.gmail.com","subject":"Re: EasyGit Integration","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-06-13T01:24:31Z","receivedAt":"2009-06-13T01:24:31Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.06.13 01:30:38 +0300, Felipe Contreras wrote:\n> On Sat, Jun 13, 2009 at 1:05 AM, Jakub Narebski wrote:\n> > On Fri, 12 Jun 2009, Felipe Contreras wrote:\n> >> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski wrote:\n> >\n> >>> Nope. 'git reset' always reset some part of state to a given commit,\n> >>> HEAD by default.  It can reset current branch with --soft, branch plus\n> >>> index with --mixed (default), and branch plus index plus working\n> >>> directory with --hard.  Source is always commit.\n> >>\n> >> You said it: 'git reset --hard' gets something out of the repository\n> >> and into the working directory.\n> >>\n> >> Try this:\n> >> git checkout \n> >>\n> >> Then what is the difference between:\n> >> git checkout HEAD^\n> >> git reset --hard HEAD^\n> >>\n> >> In this case they do exactly the same thing, don't they?\n> >\n> > No, they don't.  \"git checkout HEAD^\" modifies HEAD detaching it.\n> > \"git reset --hard HEAD^\" modifies branch that HEAD points to (well,\n> > unless HEAD is detached).\n> \n> Read again:\n> >> git checkout \n> \n> The HEAD is detached, so they do exactly the same in this case.\n\nNot if there are uncommitted changes to tracked files.\n\nBjörn\n"}]}