{"thread":{"id":"36457","subject":"What is missing from Git v2.0","startedAt":"2014-04-20T22:41:05Z","lastAt":"2014-04-25T19:27:15Z","messageCount":77,"participants":["Felipe Contreras","Sebastian Schuberth","Junio C Hamano","Theodore Ts'o","brian m. carlson","David Aguilar","Matthieu Moy","David Kastrup","David Lang","James Denholm","Andreas Krey","Stefan Beller","tytso@mit.edu","Jonathan Nieder","Jeff King","luc.linux@mailoo.org","Javier Domingo Cansino","Philippe Vaucher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"239195","messageId":"CAMP44s17h4Tjg+VaMF0atLep8t-0HVp4UDr1WE2wYnEuZ07eaQ@mail.gmail.com","threadId":"36457","inReplyTo":null,"subject":"What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-20T22:41:05Z","receivedAt":"2014-04-20T22:41:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nI had already given up on merging important features to Git upstream,\nand then one of the features I've had in git-fc (my fork) for quite\nsome time suddenly got attention (the @{publish} branch), but\neverybody forgot I already did the work. So maybe there's other\nfeatures in a similar situation.\n\n= The publish tracking branch =\n\nGit's triangular workflow support is definitely lacking, and although\nthere are many ideas and workarounds, the simplest and most\nuser-friendly way to fix the issues is by introducing the concept of a\npublish tracking branch, similar to the upstream tracking branch.\n\nFortunately this might actually get into v2.0.\n\n[1][2]\n\n= Reject non-fast-forward pulls by default =\n\nMany new-comers end up making merges by mistake when they pull because\nthey don't understand what is a non-fast-forward and what they should\nactually be doing. Most people, even Linus Torvalds, agreed that by\ndefault `git pull` should fail and guide the user, instead of silently\nmaking a merge which might not be what the user wants (even though he\ndoesn't know it), and messing up the project's history, which affects\nother people.\n\nThe patches were sent, the issues were addressed, people agreed, and\nyet nothing happened.\n\n[3][4]\n\n= Use \"stage\" instead of \"index\" =\n\nEverybody, and by everybody I literally mean everyone except Junio,\nhave agreed that \"index\" is a horrible name of the high-level concept\n(not the actual index file) of the pace where the user drafts a\ncommit. Different actions were proposed to move towards a saner name,\nand the simplest sensible one seems to be to start renaming the\nconfusing --cached and --index options to --stage and --no-work, and\nalso to add a new `git stage` command.\n\nNothing happened.\n\n[5][6][7][8]\n\n= Default aliases =\n\nEvery single version control tool out there has default aliases (e.g.\nco = checkout) except Git.\n\nEvery argument against default aliases was basically refuted, yet my\npatches went nowhere. And the users still expect these aliases.\n\n[9]\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/235981\n[2] http://thread.gmane.org/gmane.comp.version-control.git/240030\n[3] http://thread.gmane.org/gmane.comp.version-control.git/240030\n[4] http://thread.gmane.org/gmane.comp.version-control.git/235981\n[5] http://thread.gmane.org/gmane.comp.version-control.git/233295\n[6] http://thread.gmane.org/gmane.comp.version-control.git/197111\n[7] http://thread.gmane.org/gmane.comp.version-control.git/166675\n[8] http://thread.gmane.org/gmane.comp.version-control.git/115666\n[9] http://thread.gmane.org/gmane.comp.version-control.git/235145\n\n-- \nFelipe Contreras\n"},{"id":"239196","messageId":"CAMP44s0NfKW8Qo1uA0=iE8qHNm4GOXp9yC+sbgsRtmXaN625gw@mail.gmail.com","threadId":"36457","inReplyTo":"CAMP44s17h4Tjg+VaMF0atLep8t-0HVp4UDr1WE2wYnEuZ07eaQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-20T22:47:59Z","receivedAt":"2014-04-20T22:47:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Apr 20, 2014 at 5:41 PM, Felipe Contreras\n wrote:\n\n> [3] http://thread.gmane.org/gmane.comp.version-control.git/240030\n> [4] http://thread.gmane.org/gmane.comp.version-control.git/235981\n\nActually:\n\n[3] http://thread.gmane.org/gmane.comp.version-control.git/233554\n[4] http://thread.gmane.org/gmane.comp.version-control.git/234295\n\n-- \nFelipe Contreras\n"},{"id":"239221","messageId":"53557071.5040500@gmail.com","threadId":"36457","inReplyTo":"CAMP44s17h4Tjg+VaMF0atLep8t-0HVp4UDr1WE2wYnEuZ07eaQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2014-04-21T19:24:33Z","receivedAt":"2014-04-21T19:24:33Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On 21.04.2014 00:41, Felipe Contreras wrote:\n\n> = Default aliases =\n>\n> Every single version control tool out there has default aliases (e.g.\n> co = checkout) except Git.\n>\n> Every argument against default aliases was basically refuted, yet my\n> patches went nowhere. And the users still expect these aliases.\n\n+1 about having default aliases in general, and I'd also add these:\n\nbr = branch\ncp = cherry-pick\ndt = difftool\nmt = mergetool\n\nBTW, in my experience people tend to stick to predefined aliases instead \nof redefining them to something (completely) different. This means that \nhaving default aliases will very likely enable one to use the same short \ncommands on one's colleague's PC (instead of you running into issues \nbecause the same alias was defined to a different command).\n\nIf we don't standardize this now people will come up with their own \ndefinitions [1] [2] (and many others if you just search GitHub) which \nare again likely to differ (slightly), hindering interoperability.\n\n[1] https://github.com/github/msysgit/pull/27\n[2] https://github.com/sschuberth/dev-scripts/blob/master/git/.gitconfig\n\n-- \nSebastian Schuberth\n"},{"id":"239224","messageId":"535572b73183b_414c80b30863@nysa.notmuch","threadId":"36457","inReplyTo":"53557071.5040500@gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T19:34:15Z","receivedAt":"2014-04-21T19:34:15Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sebastian Schuberth wrote:\n> On 21.04.2014 00:41, Felipe Contreras wrote:\n> \n> > = Default aliases =\n> >\n> > Every single version control tool out there has default aliases (e.g.\n> > co = checkout) except Git.\n> >\n> > Every argument against default aliases was basically refuted, yet my\n> > patches went nowhere. And the users still expect these aliases.\n> \n> +1 about having default aliases in general, and I'd also add these:\n> \n> br = branch\n> cp = cherry-pick\n> dt = difftool\n> mt = mergetool\n\nI have these aliases as well, except br => b, and cp => pi. 'br' is probably\nbetter, but not sure as 'cp' which can be confusing.\n\n> BTW, in my experience people tend to stick to predefined aliases instead \n> of redefining them to something (completely) different. This means that \n> having default aliases will very likely enable one to use the same short \n> commands on one's colleague's PC (instead of you running into issues \n> because the same alias was defined to a different command).\n> \n> If we don't standardize this now people will come up with their own \n> definitions [1] [2] (and many others if you just search GitHub) which \n> are again likely to differ (slightly), hindering interoperability.\n> \n> [1] https://github.com/github/msysgit/pull/27\n> [2] https://github.com/sschuberth/dev-scripts/blob/master/git/.gitconfig\n\nFTR color.ui = true is not needed any more, also hopefully mergetool.prompt =\nfalse wouldn't be either [1].\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/246601\n\n-- \nFelipe Contreras\n"},{"id":"239223","messageId":"xmqqtx9m8obr.fsf@gitster.dls.corp.google.com","threadId":"36457","inReplyTo":"53557071.5040500@gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-21T19:39:04Z","receivedAt":"2014-04-21T19:39:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sebastian Schuberth writes:\n\n>> Every argument against default aliases was basically refuted, yet my\n>> patches went nowhere. And the users still expect these aliases.\n>\n> +1 about having default aliases in general, and I'd also add these:\n\nI think it might be OK to implement them as the lowest priority\nfallback alias, so that '[alias] co = \"user's definition\"' anywhere\nin the various configuration locations will override it. I am a bit\nhesitant about adding start-up overhead, though. Also I am not sure\nif people can agree with (1) a broadly wide selection of aliases and\n(2) the actual definitions for them (I am OK with \"co === checkout\"\nmyself, but I'd rather not to even think about my Git wasting cycles\nparsing extra configuration items to support \"br === branch\" at all,\nfor example).\n\nIf we squat on \"co\" and other short-and-sweet friends by adding them\nas built-in aliases (i.e by adding them to git.c:commands[]), the\nonly effect would be to annoy people who have them defined somewhat\nslightly differently, so that won't fly well.\n\n> If we don't standardize this now people will come up with their own\n> definitions [1] [2] (and many others if you just search GitHub) which\n> are again likely to differ (slightly), hindering interoperability.\n\nI am afraid that that ship has sailed long time ago, though.\n"},{"id":"239225","messageId":"CAHGBnuM3TVMbow7Zbb9QnEeJOR9aZY1dwj2CWqs-Ti_HDppE1w@mail.gmail.com","threadId":"36457","inReplyTo":"535572b73183b_414c80b30863@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2014-04-21T19:47:57Z","receivedAt":"2014-04-21T19:47:57Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras\n wrote:\n\n> I have these aliases as well, except br => b, and cp => pi. 'br' is probably\n> better, but not sure as 'cp' which can be confusing.\n\nIf by confusing you refer to \"cp\" to copy files, that's actually what\nI like about it: cherry-pick is somewhat like copying commits, thus\n\"cp\" makes much sense to me.\n\n> FTR color.ui = true is not needed any more, also hopefully mergetool.prompt =\n> false wouldn't be either [1].\n\nThanks!\n\n-- \nSebastian Schuberth\n"},{"id":"239229","messageId":"20140421204506.GD5105@thunk.org","threadId":"36457","inReplyTo":"CAHGBnuM3TVMbow7Zbb9QnEeJOR9aZY1dwj2CWqs-Ti_HDppE1w@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-04-21T20:45:06Z","receivedAt":"2014-04-21T20:45:06Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:\n> On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras\n> wrote:\n> \n> > I have these aliases as well, except br => b, and cp => pi. 'br' is probably\n> > better, but not sure as 'cp' which can be confusing.\n> \n> If by confusing you refer to \"cp\" to copy files, that's actually what\n> I like about it: cherry-pick is somewhat like copying commits, thus\n> \"cp\" makes much sense to me.\n\nThe problem is that between \"git rm\" and \"git mv\", if we default \"git\ncp\" to mean \"cherry-pick\" there could easily be user confusion.\n\nI'm not sure that cherry-pick is used that often it really needs a two\ncharacter shortcut. Maybe just \"git pick\"?\n\nPersonally, \"git branch\" and \"git checkout\" are finger macros that I\ntype very quickly, so creating two character alias probably wouldn't\nsave me that much time. But I do appreicate that there are folks for\nwhich such aliases might be useful.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"239234","messageId":"535583c0caa69_5c94d452ec6c@nysa.notmuch","threadId":"36457","inReplyTo":"20140421204506.GD5105@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-21T20:46:56Z","receivedAt":"2014-04-21T20:46:56Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Theodore Ts'o wrote:\n> On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:\n> > On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras\n> > wrote:\n> > \n> > > I have these aliases as well, except br => b, and cp => pi. 'br' is probably\n> > > better, but not sure as 'cp' which can be confusing.\n> > \n> > If by confusing you refer to \"cp\" to copy files, that's actually what\n> > I like about it: cherry-pick is somewhat like copying commits, thus\n> > \"cp\" makes much sense to me.\n> \n> The problem is that between \"git rm\" and \"git mv\", if we default \"git\n> cp\" to mean \"cherry-pick\" there could easily be user confusion.\n> \n> I'm not sure that cherry-pick is used that often it really needs a two\n> character shortcut. Maybe just \"git pick\"?\n\nI'm in favor of having both 'git pick', and 'git pi'.\n\n> Personally, \"git branch\" and \"git checkout\" are finger macros that I\n> type very quickly, so creating two character alias probably wouldn't\n> save me that much time. But I do appreicate that there are folks for\n> which such aliases might be useful.\n\nI bet I can type 'g b' and 'g co' faster :)\n\n-- \nFelipe Contreras\n"},{"id":"239282","messageId":"20140422021256.GC86681@vauxhall.crustytoothpaste.net","threadId":"36457","inReplyTo":"53557071.5040500@gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-04-22T02:12:56Z","receivedAt":"2014-04-22T02:12:56Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote:\n> BTW, in my experience people tend to stick to predefined aliases instead of\n> redefining them to something (completely) different. This means that having\n> default aliases will very likely enable one to use the same short commands\n> on one's colleague's PC (instead of you running into issues because the same\n> alias was defined to a different command).\n> \n> If we don't standardize this now people will come up with their own\n> definitions [1] [2] (and many others if you just search GitHub) which are\n> again likely to differ (slightly), hindering interoperability.\n\nUnfortunately, that's already happened. Some people alias ci to commit,\nand some people alias it to commit -a. There is literally no choice you\ncan make there that will make everyone happy.\n\nIf you provide default aliases, people will expect them to work\neverywhere, and then be confused when they don't. It's much better to\nlet people alias what they want on their own. I understand the\nfrustration of having to work on others' machines when they don't have\nyour aliases, because every time I type \"git pff\"[0] and it fails, it\ndrives me crazy, but there's just no sane defaults.\n\n[0] Aliased to git pull --ff-only. I probably run this at least twenty\ntimes a day.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"239291","messageId":"5355f9c16b665_15b012f3310d5@nysa.notmuch","threadId":"36457","inReplyTo":"20140422021256.GC86681@vauxhall.crustytoothpaste.net","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T05:10:25Z","receivedAt":"2014-04-22T05:10:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote:\n> > BTW, in my experience people tend to stick to predefined aliases instead of\n> > redefining them to something (completely) different. This means that having\n> > default aliases will very likely enable one to use the same short commands\n> > on one's colleague's PC (instead of you running into issues because the same\n> > alias was defined to a different command).\n> > \n> > If we don't standardize this now people will come up with their own\n> > definitions [1] [2] (and many others if you just search GitHub) which are\n> > again likely to differ (slightly), hindering interoperability.\n> \n> Unfortunately, that's already happened. Some people alias ci to commit,\n> and some people alias it to commit -a. There is literally no choice you\n> can make there that will make everyone happy.\n\nOf course we can:\na) The people that have 'alias.co = git commit' will keep their alias\nb) The people that have 'alias.co = git commit -a' will keep their alias\nc) The people that haven't set alias.co, will get the default\n\n> If you provide default aliases, people will expect them to work\n> everywhere, and then be confused when they don't.\n\nThis argument was already brought up, and already proved to be false.\n\nMercurial allows not only to override the default alias, but to override the\ncore commands, so you can alias 'hg push' to 'hg push --force'. According to\nyour hypothesis people using Mercurial would get confused when basic commands\nwork on certain machines and not others. This is not the case. I challenge you\nto find a single instance when people got confused because of the configured\naliases.\n\n> It's much better to let people alias what they want on their own. I\n> understand the frustration of having to work on others' machines when they\n> don't have your aliases, because every time I type \"git pff\"[0] and it fails,\n> it drives me crazy, but there's just no sane defaults.\n\nYes there are sane defaults.\n\n co = checkout\n ci = commit\n rb = rebase\n st = status\n br = branch\n dt = difftool\n mt = mergetool\n\n-- \nFelipe Contreras\n"},{"id":"239290","messageId":"20140422051918.GC60610@gmail.com","threadId":"36457","inReplyTo":"CAMP44s17h4Tjg+VaMF0atLep8t-0HVp4UDr1WE2wYnEuZ07eaQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2014-04-22T05:19:39Z","receivedAt":"2014-04-22T05:19:39Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:\n> = Reject non-fast-forward pulls by default =\n> \n> Many new-comers end up making merges by mistake when they pull because\n> they don't understand what is a non-fast-forward and what they should\n> actually be doing. Most people, even Linus Torvalds, agreed that by\n> default `git pull` should fail and guide the user, instead of silently\n> making a merge which might not be what the user wants (even though he\n> doesn't know it), and messing up the project's history, which affects\n> other people.\n> \n> The patches were sent, the issues were addressed, people agreed, and\n> yet nothing happened.\n\nWe can currently set pull.ff = only to get this behavior.\nI would like it if this were the default (but I am biased).\n\n> = Use \"stage\" instead of \"index\" =\n\nI'm probably biased about this one too, but I should probably speak up.\n\ngit-cola has used \"Staged\", \"Modified\", \"Untracked\", etc. since\nthe beginning of time. Sorry 'bout that, but it seemed like the\nsimplest word to use.\n\nI often hear users talking about \"staging\" files.\nI'm probably in an echo chamber, but I never really had to\nexplain \"the staging area\" since the concept is pretty natural\nwhen interacting with the GUI.\n\nJust my $.02.\n\nciao,\n-- \nDavid\n"},{"id":"239293","messageId":"535600656ba3_1c81125730c6e@nysa.notmuch","threadId":"36457","inReplyTo":"20140422051918.GC60610@gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T05:38:45Z","receivedAt":"2014-04-22T05:38:45Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Aguilar wrote:\n> On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote:\n> > = Reject non-fast-forward pulls by default =\n> > \n> > Many new-comers end up making merges by mistake when they pull because\n> > they don't understand what is a non-fast-forward and what they should\n> > actually be doing. Most people, even Linus Torvalds, agreed that by\n> > default `git pull` should fail and guide the user, instead of silently\n> > making a merge which might not be what the user wants (even though he\n> > doesn't know it), and messing up the project's history, which affects\n> > other people.\n> > \n> > The patches were sent, the issues were addressed, people agreed, and\n> > yet nothing happened.\n> \n> We can currently set pull.ff = only to get this behavior.\n\nIt is not the same behavior as my patch series, you get:\n\n fatal: Not possible to fast-forward, aborting.\n\nWith that message we certainly cannot make it the default. In my patch series you get:\n\n The pull was not fast-forward, please either merge or rebase.\n If unsure, run 'git pull --merge'.\n\n> I would like it if this were the default (but I am biased).\n\nI don't know if you followed the discussion, but virtually everyone (including\nLinus) agreed this should be the default.\n\n> > = Use \"stage\" instead of \"index\" =\n> \n> I'm probably biased about this one too, but I should probably speak up.\n> \n> git-cola has used \"Staged\", \"Modified\", \"Untracked\", etc. since\n> the beginning of time. Sorry 'bout that, but it seemed like the\n> simplest word to use.\n> \n> I often hear users talking about \"staging\" files.\n> I'm probably in an echo chamber, but I never really had to\n> explain \"the staging area\" since the concept is pretty natural\n> when interacting with the GUI.\n\nAgain, virtually everyone (except Junio) agrees.\n\n-- \nFelipe Contreras\n"},{"id":"239305","messageId":"CAHGBnuMty-86jfUto=L3muhgEVwVE70FQQY2FJ1bn7AUjfEtLQ@mail.gmail.com","threadId":"36457","inReplyTo":"xmqqtx9m8obr.fsf@gitster.dls.corp.google.com","subject":"Re: What is missing from Git v2.0","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2014-04-22T07:19:40Z","receivedAt":"2014-04-22T07:19:40Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote:\n\n>> If we don't standardize this now people will come up with their own\n>> definitions [1] [2] (and many others if you just search GitHub) which\n>> are again likely to differ (slightly), hindering interoperability.\n>\n> I am afraid that that ship has sailed long time ago, though.\n\nThat's most likely true, but it does not get better by postponing this\neven more. I still think there's value in introducing this now, Git\nstill attracts new developers every day. In fact, I currently see a\nleap forwarding in the Windows world towards Git, caused by some\nrethinking and structural changes in some big companies.\n\n-- \nSebastian Schuberth\n"},{"id":"239306","messageId":"CAHGBnuNFW7HCC2U418TC11CKqbB66EtXV_SOs7w0p5RcqAPuLw@mail.gmail.com","threadId":"36457","inReplyTo":"535583c0caa69_5c94d452ec6c@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2014-04-22T07:23:53Z","receivedAt":"2014-04-22T07:23:53Z","isPatch":false,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras\n wrote:\n\n>> The problem is that between \"git rm\" and \"git mv\", if we default \"git\n>> cp\" to mean \"cherry-pick\" there could easily be user confusion.\n>>\n>> I'm not sure that cherry-pick is used that often it really needs a two\n>> character shortcut. Maybe just \"git pick\"?\n>\n> I'm in favor of having both 'git pick', and 'git pi'.\n\nPlease let's stick to one clear default alias for some central\ncommands, and not introduce ambiguity between aliases. That said, I'd\nprefer pick over pi, but still cp would be my personal favorite.\n\n-- \nSebastian Schuberth\n"},{"id":"239314","messageId":"5356244680af3_3d2216372ec4@nysa.notmuch","threadId":"36457","inReplyTo":"CAHGBnuMty-86jfUto=L3muhgEVwVE70FQQY2FJ1bn7AUjfEtLQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T08:11:50Z","receivedAt":"2014-04-22T08:11:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sebastian Schuberth wrote:\n> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote:\n> \n> >> If we don't standardize this now people will come up with their own\n> >> definitions [1] [2] (and many others if you just search GitHub) which\n> >> are again likely to differ (slightly), hindering interoperability.\n> >\n> > I am afraid that that ship has sailed long time ago, though.\n> \n> That's most likely true, but it does not get better by postponing this\n> even more. I still think there's value in introducing this now, Git\n> still attracts new developers every day. In fact, I currently see a\n> leap forwarding in the Windows world towards Git, caused by some\n> rethinking and structural changes in some big companies.\n\nExactly. If one thinks in terms of years, sure, it might make sense to not\nchange the status quo created by years back. But think about Git in a decade or\ntwo, at that point surely you would have wished that you had considered these\nkinds of changes sooner.\n\nJunio at some point suggested to think about features for v1.8.0 as if we were\nstarting from scratch[1]. I'd say if there has every been a time to add default\naliases after v1.0 it's certainly v2.0.\n\nOur future users who might have not touched Git yet would certainly welcome\nthis.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/165735\n\n-- \nFelipe Contreras\n"},{"id":"239315","messageId":"53562535f130b_3d2216372ec2a@nysa.notmuch","threadId":"36457","inReplyTo":"CAHGBnuNFW7HCC2U418TC11CKqbB66EtXV_SOs7w0p5RcqAPuLw@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T08:15:49Z","receivedAt":"2014-04-22T08:15:49Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sebastian Schuberth wrote:\n> On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras\n> wrote:\n> \n> >> The problem is that between \"git rm\" and \"git mv\", if we default \"git\n> >> cp\" to mean \"cherry-pick\" there could easily be user confusion.\n> >>\n> >> I'm not sure that cherry-pick is used that often it really needs a two\n> >> character shortcut. Maybe just \"git pick\"?\n> >\n> > I'm in favor of having both 'git pick', and 'git pi'.\n> \n> Please let's stick to one clear default alias for some central\n> commands, and not introduce ambiguity between aliases. That said, I'd\n> prefer pick over pi, but still cp would be my personal favorite.\n\nI think porcelain commands should eventually change names (and maybe become\nmore friendly) 'git ls-files' => 'git ls', 'git cherry-pick' => 'git pick', and\nso on.\n\nIf 'cherry-pick' evolves into 'pick', it would make sense to have the 'pi'\nalias, and in preparation for that I don't see why a temporary 'pick' alias\nwould hurt.\n\n-- \nFelipe Contreras\n"},{"id":"239358","messageId":"xmqqk3ah5i55.fsf@gitster.dls.corp.google.com","threadId":"36457","inReplyTo":"CAHGBnuMty-86jfUto=L3muhgEVwVE70FQQY2FJ1bn7AUjfEtLQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-22T18:33:10Z","receivedAt":"2014-04-22T18:33:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sebastian Schuberth writes:\n\n> On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote:\n>\n>>> If we don't standardize this now people will come up with their own\n>>> definitions [1] [2] (and many others if you just search GitHub) which\n>>> are again likely to differ (slightly), hindering interoperability.\n>>\n>> I am afraid that that ship has sailed long time ago, though.\n>\n> That's most likely true, but it does not get better by postponing this\n> even more.\n\nAs I already said:\n\n I think it might be OK to implement them as the lowest priority\n fallback alias, so that '[alias] co = \"user's definition\"'\n anywhere in the various configuration locations will override\n it. I am a bit hesitant about adding start-up overhead, though.\n Also I am not sure if people can agree with (1) a broadly wide\n selection of aliases and (2) the actual definitions for them (I\n am OK with \"co === checkout\" myself, but I'd rather not to even\n think about my Git wasting cycles parsing extra configuration\n items to support \"br === branch\" at all, for example).\n\nI am not fundamentally opposed. I just do not think it would add\nmuch value to new people at this point, and it will actively hurt\nif we shoved barely cooked one in 2.0.\n\nA few thinking points that are necessary to be worked out, even\nbefore we start imagining a plan to introduce them, off the top of\nmy head, are these:\n\n * Should we add many random aliases, or should we limit ourselves\n only to a narrow set that everybody can agree on?\n\n * What is the additional cognitive load do we feel comfortable\n burdening with the new users?\n\n * What is the exact mechanism to give these built-in aliases?\n\nImagine that somebody says \"[alias] ci = commit\" and a handful of\nvocal people on this list agree that it is a good idea. Many random\nwebsites start mentioning \"git ci -a\" in their beginner examples.\n\nUsers are led to think \"ci\" is a command just like \"commit\" and does\nthe same thing. Some of them want to always commit everything\nbefore moving to their next task, and want to alias it further, e.g.\n\"[alias] ci = ci -a\"---which would not work. At that point, the\nusers need to learn the distinction between native subcommands\n(e.g. \"commit\"), built-in fallback aliases (e.g. \"ci\") and aliases\nof their own in their ~/.gitconfig, and need to learn that only the\nfirst kind and not the second kind cannot be used to define their\nown alias (and the users need to learn \"commit\" at that time as\nwell).\n\nThat could be solved by making \"ci\" not a built-in fallback alias,\nbut a new subcommand (then there is no \"'foo' in 'git foo' could be\na command or a built-in alias and they behave differently\" issue),\nand additionally somehow allowing a native subcommand overriden by\nend-user alias, but I do not think anybody designed how such an\noverride would work so far.\n\nSo even if we agree that it would be a good idea to have some\ndefault fallback aliases, the set of such aliases we ship must be\nlimited to a set that everybody can agree on, both in the sense that\n\"adding alias XX is good\" and also in the sense that \"alias XX must\nbe defined as YY\".\n\nAs you allueded to, the Git userbase is a lot larger than it used to\nbe back in 2006, one alias, e.g. \"[alias] br = branch\", that is\nreported as either useless or needed to be further tweaked by a\nperson on this list would mean that we would be either spending\nunnecessary start-up cycles (for \"useless\" case) or adding cognitive\nload of having to differente between \"branch\" and \"br\" (for \"needs\nfurther tweak\" case) for thousands of users who would be better off\nif we didn't have that specific alias.\n\nSo while I understand the desire to have a bit more handholding and\nam not fundamentally opposed to the desire, I am not optimistic that\nan attempt to implement these \"aliases\" would result in a very\nuseful addition to the system, even if done after careful thought.\n\nIn any case, this definitely is not a 2.0 material. I agree that it\nwould be good to start discussing it early (rather than later) if we\never want to do such a change.\n"},{"id":"239371","messageId":"5356c1a61f6d8_463e11ef310a5@nysa.notmuch","threadId":"36457","inReplyTo":"xmqqk3ah5i55.fsf@gitster.dls.corp.google.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T19:23:18Z","receivedAt":"2014-04-22T19:23:18Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Sebastian Schuberth writes:\n> \n> > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote:\n> >\n> >>> If we don't standardize this now people will come up with their own\n> >>> definitions [1] [2] (and many others if you just search GitHub) which\n> >>> are again likely to differ (slightly), hindering interoperability.\n> >>\n> >> I am afraid that that ship has sailed long time ago, though.\n> >\n> > That's most likely true, but it does not get better by postponing this\n> > even more.\n> \n> As I already said:\n> \n> I think it might be OK to implement them as the lowest priority\n> fallback alias, so that '[alias] co = \"user's definition\"'\n> anywhere in the various configuration locations will override\n> it. I am a bit hesitant about adding start-up overhead, though.\n> Also I am not sure if people can agree with (1) a broadly wide\n> selection of aliases and (2) the actual definitions for them (I\n> am OK with \"co === checkout\" myself, but I'd rather not to even\n> think about my Git wasting cycles parsing extra configuration\n> items to support \"br === branch\" at all, for example).\n> \n> I am not fundamentally opposed. I just do not think it would add\n> much value to new people at this point, and it will actively hurt\n> if we shoved barely cooked one in 2.0.\n\nYou are probably biased in that you've used Git far much more than the average\nuser has (or future new users).\n\n> So even if we agree that it would be a good idea to have some\n> default fallback aliases, the set of such aliases we ship must be\n> limited to a set that everybody can agree on, both in the sense that\n> \"adding alias XX is good\" and also in the sense that \"alias XX must\n> be defined as YY\".\n> \n> As you allueded to, the Git userbase is a lot larger than it used to\n> be back in 2006, one alias, e.g. \"[alias] br = branch\", that is\n> reported as either useless or needed to be further tweaked by a\n> person on this list would mean that we would be either spending\n> unnecessary start-up cycles (for \"useless\" case) or adding cognitive\n> load of having to differente between \"branch\" and \"br\" (for \"needs\n> further tweak\" case) for thousands of users who would be better off\n> if we didn't have that specific alias.\n\nI think it's reasonable to follow these guidelines:\n\n 1) Each default alias should have two characters\n 2) Each default alias should map to a command without arguments\n 3) Each default alias be widely used in the wild\n\nThis set matches the above:\n\n co = checkout\n ci = commit\n rb = rebase\n st = status\n br = branch\n dt = difftool\n mt = mergetool\n\nYou might not like 'br', but there's tons of people already using that alias,\nso it's not \"useless\". I can go find links to many examples if you would like.\n\n> So while I understand the desire to have a bit more handholding and\n> am not fundamentally opposed to the desire, I am not optimistic that\n> an attempt to implement these \"aliases\" would result in a very\n> useful addition to the system, even if done after careful thought.\n\nThe fact that you are not optimistic about it doesn't mean it's impossible.\n\n> In any case, this definitely is not a 2.0 material. I agree that it\n> would be good to start discussing it early (rather than later) if we\n> ever want to do such a change.\n\nWhy is not material for v2.0? Because you say so? Are you going to wait another\nten years to introduce this to v3.0?\n\nThis is actually the perfect time to do it.\n\n-- \nFelipe Contreras\n"},{"id":"239379","messageId":"vpqlhux3yhr.fsf@anie.imag.fr","threadId":"36457","inReplyTo":"5356c1a61f6d8_463e11ef310a5@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-04-22T20:22:56Z","receivedAt":"2014-04-22T20:22:56Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> Why is not material for v2.0? Because you say so? Are you going to wait another\n> ten years to introduce this to v3.0?\n\nThere's no need to wait for a 3.0 to introduce this. If these would\nbe low-priority compared to user-defined aliases, there's no backward\ncompatibility issue, it can very well be a 2.1, or whatever number comes\nafter 2.0.\n\n> This is actually the perfect time to do it.\n\nJunio has just tagged a -rc for 2.0, so it's clearly too late to start\ndiscussing new features for this particular release.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"239382","messageId":"5356d8918948a_6cbadd72f0d@nysa.notmuch","threadId":"36457","inReplyTo":"vpqlhux3yhr.fsf@anie.imag.fr","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T21:01:05Z","receivedAt":"2014-04-22T21:01:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthieu Moy wrote:\n> Felipe Contreras writes:\n> \n> > Why is not material for v2.0? Because you say so? Are you going to wait another\n> > ten years to introduce this to v3.0?\n> \n> There's no need to wait for a 3.0 to introduce this. If these would\n> be low-priority compared to user-defined aliases, there's no backward\n> compatibility issue, it can very well be a 2.1, or whatever number comes\n> after 2.0.\n\nCan it? I would like Junio to say so.\n\nStill, v2.0 is a better time for this.\n\n> > This is actually the perfect time to do it.\n> \n> Junio has just tagged a -rc for 2.0, so it's clearly too late to start\n> discussing new features for this particular release.\n\nAnd whose fault is that? I never saw any warning about the -rc tag, and I never\nsaw any discussion about possible features missing in v2.0.\n\nGiven that the next backward-incompatible release might be in a decade, I would\nhave expected people to have put more thought into v2.0, but I guess the Git\nproject is not really interested in progressive features.\n\n-- \nFelipe Contreras\n"},{"id":"239386","messageId":"20140422213039.GB21043@thunk.org","threadId":"36457","inReplyTo":"5356c1a61f6d8_463e11ef310a5@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-04-22T21:30:39Z","receivedAt":"2014-04-22T21:30:39Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:\n> > I am not fundamentally opposed. I just do not think it would add\n> > much value to new people at this point, and it will actively hurt\n> > if we shoved barely cooked one in 2.0.\n> \n> You are probably biased in that you've used Git far much more than\n> the average user has (or future new users).\n\nI think Junio has a really strong point. If the goal is to make life\neasier for new users, allowing them to save a few keystrokes is\nprobably not the most significant thing we can do. And we have to\nbalance this with the additional cognitive load in remembering how a\nparticular two character alias maps to the \"real\" command. This is\nespecially true for commands which might not be used as often -- e.g.,\n\"rebase\", and for commands where the meaning of \"git commit\" without\nany argument is qualitatively different from what \"ci\" (for checkin)\nmeans in most other source management systems.\n\nSo I do think it's worth thinking about this very carefully. For\ncertain, I would **not** recommend using shortcuts in example command\nsequences. If the user reads \"git rebase\" or \"git cherry-pick\" it\nmeans a lot more than if they see a series of apparent chicken\nscratches filled with things like \"git rb\", \"git pi\", \"git st\", etc.\n\nIn fact, to be fair, you may be getting biased because you're used to\nusing the two character shortcuts, so for you, of *course* \"rb\" and\n\"pi\" and \"ci\" make a lot of sense. But for someone who is starting\nfrom scratch, I really question how much it helps, and how much it\nmight hurt, to see the two character shortcuts or even to have to\nremember the two character shortcuts. And for a command like \"rebase\"\nwhere the user can very easily shoot themselves in the foot to begin\nwith, I'd actually suggest that it's a _good_ thing that they have to\ntype it out in full.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"239389","messageId":"5356e62feb9f3_6cbadd72f0f1@nysa.notmuch","threadId":"36457","inReplyTo":"20140422213039.GB21043@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-22T21:59:11Z","receivedAt":"2014-04-22T21:59:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Theodore Ts'o wrote:\n> On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:\n> > > I am not fundamentally opposed. I just do not think it would add\n> > > much value to new people at this point, and it will actively hurt\n> > > if we shoved barely cooked one in 2.0.\n> > \n> > You are probably biased in that you've used Git far much more than\n> > the average user has (or future new users).\n> \n> I think Junio has a really strong point.\n\nWhat is that point?\n\n> If the goal is to make life easier for new users, allowing them to save a few\n> keystrokes is probably not the most significant thing we can do.\n\nNo, but it's *one* thing we can definetly do, and since we are not doing\nanything else, we might as well do this one thing.\n\n> And we have to balance this with the additional cognitive load in remembering\n> how a particular two character alias maps to the \"real\" command.\n\nWhat cognitive load? You don't *need* to remember the default aliases; you\ndon't need to use them at all.\n\n> This is especially true for commands which might not be used as often --\n> e.g., \"rebase\", and for commands where the meaning of \"git commit\" without\n> any argument is qualitatively different from what \"ci\" (for checkin) means in\n> most other source management systems.\n\nci means commit in Mercurial.\n\n> So I do think it's worth thinking about this very carefully. For\n> certain, I would **not** recommend using shortcuts in example command\n> sequences. If the user reads \"git rebase\" or \"git cherry-pick\" it\n> means a lot more than if they see a series of apparent chicken\n> scratches filled with things like \"git rb\", \"git pi\", \"git st\", etc.\n\nCertainly, but that is orthogonal.\n\n> In fact, to be fair, you may be getting biased because you're used to\n> using the two character shortcuts, so for you, of *course* \"rb\" and\n> \"pi\" and \"ci\" make a lot of sense.\n\nI can't be biased to those because I don't use them, mine are one character\nshortcuts.\n\nAnd if that hypothesis was correct, why does Mercurial, Bazaar, Subversion,\nCVS, and pretty much everything uses aliases? And why does pretty much every\n.gitconfig has similar aliases? That would imply that the whole world is\nbiased.\n\n> But for someone who is starting from scratch, I really question how much it\n> helps, and how much it might hurt, to see the two character shortcuts or even\n> to have to remember the two character shortcuts.\n\nHere you are talking from your own bias.\n\nIt would help when the user starts to think \"Geez, I seem to be typing\n`git checkout` an awful lot, I wonder if there's a shortcut\", which if the\n.gitconfigs out there are any indication, it happens all the time.\n\n> And for a command like \"rebase\" where the user can very easily shoot\n> themselves in the foot to begin with, I'd actually suggest that it's a _good_\n> thing that they have to type it out in full.\n\nAnd now you contradict yourself; you actually want to make life harder for new\nusers, on purpose.\n\n-- \nFelipe Contreras\n"},{"id":"239388","messageId":"xmqqmwfd2fa5.fsf@gitster.dls.corp.google.com","threadId":"36457","inReplyTo":"xmqqk3ah5i55.fsf@gitster.dls.corp.google.com","subject":"Re: What is missing from Git v2.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-22T22:03:14Z","receivedAt":"2014-04-22T22:03:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I am not fundamentally opposed. I just do not think it would add\n> much value to new people at this point, and it will actively hurt\n> if we shoved barely cooked one in 2.0.\n>\n> A few thinking points that are necessary to be worked out, even\n> before we start imagining a plan to introduce them, off the top of\n> my head, are these:\n>\n> * Should we add many random aliases, or should we limit ourselves\n> only to a narrow set that everybody can agree on?\n>\n> * What is the additional cognitive load do we feel comfortable\n> burdening with the new users?\n>\n> * What is the exact mechanism to give these built-in aliases?\n>\n> Imagine that somebody says \"[alias] ci = commit\" and a handful of\n> vocal people on this list agree that it is a good idea. Many random\n> websites start mentioning \"git ci -a\" in their beginner examples.\n>\n> Users are led to think \"ci\" is a command just like \"commit\" and does\n> the same thing.... and need to learn that only the\n> first kind and not the second kind cannot be used to define their\n> own alias (and the users need to learn \"commit\" at that time as\n> well).\n\nA bit further on this point, looking into the future.\n\nIt might help if we added some \"introduction\" phase to the first\ninvocation of \"git init\", \"git clone\", etc. that is interactively\nrun on a machine where there is no $HOME/.gitconfig detected, and\nhelp the user populate it with a few selected and uncontroversial\nones. Such a session might go like this:\n\n\t$ git init\n ... We do not see $HOME/.gitconfig; using Git for the first time?\n ... Let us ask a few questions to make your Git life more pleasant.\n >> What name do you want to appear on your commits?\n Sebastian Schuberth\n >> What email address do you want to appear on your commits?\n\tsschuberth@gmail.com\n >> You record your commits as\n ... \"Sebastian Schuberth \".\n >> OK?\n Y\n >> Do you want us to add a few sample aliases to your configuration file?\n Y\n ... Done. You can further tweak $HOME/.gitconfig to suit\n ... Git to your taste.\n\nAnd it would end up with something like this:\n\n\t$ cat $HOME/.gitconfig\n [user]\n\t\tname = <>\n email = <>\n\t[alias]\n \tco = checkout\n\t\tlg = log --oneline\n\nwhich can serve as an example the user can then tweak, without\ngiving any false impression that \"co\" is any more special than\nwhatever the user adds as a custom alias.\n\nBut the need to make the set minimum and the need to carefully think\nthings through are still there (Ted made a very good point about \"rb\",\nwhich I agree with).\n"},{"id":"239391","messageId":"xmqqioq12eif.fsf@gitster.dls.corp.google.com","threadId":"36457","inReplyTo":"vpqlhux3yhr.fsf@anie.imag.fr","subject":"Re: What is missing from Git v2.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-22T22:19:52Z","receivedAt":"2014-04-22T22:19:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Felipe Contreras writes:\n>\n>> Why is not material for v2.0? Because you say so? Are you going to wait another\n>> ten years to introduce this to v3.0?\n>\n> There's no need to wait for a 3.0 to introduce this. If these would\n> be low-priority compared to user-defined aliases, there's no backward\n> compatibility issue, it can very well be a 2.1, or whatever number comes\n> after 2.0.\n\nI do not think the discussion has analysed the issue deeply enough\nfor us to tell what the final proposal would look like, in order to\njudge what kind of issues, whether related to backward compatibility\nor not, are involved. My hunch is that this may not have to wait\nfor a big version bump, but I am not sure about that at this point.\n\nAlso I do not think 3.0 has to wait for ten years, either.\n\nWe started discussing incompatible updates for 2.0 in earnest during\nthe v1.8.2 timeframe, which was tagged mid-March 2013 with a release\nnotes with a \"B/c notes for 2.0\" section, but IIRC the discussion of\nmany of the \"let's make things consistent (even if that means we\nhave to break existing users), and devise ways to make the transtion\nfor them as smooth as possible\" changes that finally is going to\nhappen in v2.0 have been in the works since the v1.7.x era (tagged\nlate January 2012). While I do not want to rush things late in a\ncycle (notice how many topics are still cooking in 'next' and will\ncontinue to be in preparation for 2.1 right now), I do not think it\nis warranted to have a panic \"3.0 will be ten years out, and we will\nmiss the boat if we do not cram this in some shape into 2.0\"---that\nkind of haste simply is not necessary.\n\nEven if we end up having to wait for 3.0, it will happen within two\nyears max, if not earlier.\n"},{"id":"239393","messageId":"87y4yxc89r.fsf@fencepost.gnu.org","threadId":"36457","inReplyTo":"5356e62feb9f3_6cbadd72f0f1@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-22T22:24:32Z","receivedAt":"2014-04-22T22:24:32Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> Theodore Ts'o wrote:\n>\n>> This is especially true for commands which might not be used as often\n>> -- e.g., \"rebase\", and for commands where the meaning of \"git commit\"\n>> without any argument is qualitatively different from what \"ci\" (for\n>> checkin) means in most other source management systems.\n>\n> ci means commit in Mercurial.\n\nDoes it mean \"commit the staging area\"?\n\n>> In fact, to be fair, you may be getting biased because you're used to\n>> using the two character shortcuts, so for you, of *course* \"rb\" and\n>> \"pi\" and \"ci\" make a lot of sense.\n>\n> I can't be biased to those because I don't use them, mine are one\n> character shortcuts.\n\nWhich you created yourself, on your own responsibility.\n\n> And if that hypothesis was correct, why does Mercurial, Bazaar,\n> Subversion, CVS, and pretty much everything uses aliases? And why does\n> pretty much every .gitconfig has similar aliases? That would imply\n> that the whole world is biased.\n\nMost .profile files define aliases as well. Doing this on the user's\ninitiative is harmless since it will not have its usage leak into\nscripts intended for use by others.\n\n> It would help when the user starts to think \"Geez, I seem to be typing\n> `git checkout` an awful lot, I wonder if there's a shortcut\", which if\n> the .gitconfigs out there are any indication, it happens all the time.\n\nActually, it happens very rarely if you are talking about _real_\ngitconfigs deployed by projects as compared to _sample_ gitconfigs\ndemonstrating Git features for _personal_ rather than project-wide use.\n\n>> And for a command like \"rebase\" where the user can very easily shoot\n>> themselves in the foot to begin with, I'd actually suggest that it's\n>> a _good_ thing that they have to type it out in full.\n>\n> And now you contradict yourself; you actually want to make life harder\n> for new users, on purpose.\n\nLife's hardness is not proportional to the number of typed characters or\nAPL would be the easiest programming language narrowly followed by Perl.\nLife does not become easier by lowering input redundancy until it\nbecomes hard to tell apart from line noise. Keyboards are highly\nefficient input devices, or we would not be conversing in whole\nsentences in technical mailing lists but rather in telegraphy style.\n\n-- \nDavid Kastrup\n"},{"id":"239395","messageId":"alpine.DEB.2.02.1404221523060.14881@nftneq.ynat.uz","threadId":"36457","inReplyTo":"20140422213039.GB21043@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-04-22T22:25:50Z","receivedAt":"2014-04-22T22:25:50Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 22 Apr 2014, Theodore Ts'o wrote:\n\n> On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:\n>>> I am not fundamentally opposed. I just do not think it would add\n>>> much value to new people at this point, and it will actively hurt\n>>> if we shoved barely cooked one in 2.0.\n>>\n>> You are probably biased in that you've used Git far much more than\n>> the average user has (or future new users).\n>\n> I think Junio has a really strong point. If the goal is to make life\n> easier for new users, allowing them to save a few keystrokes is\n> probably not the most significant thing we can do. And we have to\n> balance this with the additional cognitive load in remembering how a\n> particular two character alias maps to the \"real\" command. This is\n> especially true for commands which might not be used as often -- e.g.,\n> \"rebase\", and for commands where the meaning of \"git commit\" without\n> any argument is qualitatively different from what \"ci\" (for checkin)\n> means in most other source management systems.\n>\n> So I do think it's worth thinking about this very carefully. For\n> certain, I would **not** recommend using shortcuts in example command\n> sequences. If the user reads \"git rebase\" or \"git cherry-pick\" it\n> means a lot more than if they see a series of apparent chicken\n> scratches filled with things like \"git rb\", \"git pi\", \"git st\", etc.\n>\n> In fact, to be fair, you may be getting biased because you're used to\n> using the two character shortcuts, so for you, of *course* \"rb\" and\n> \"pi\" and \"ci\" make a lot of sense. But for someone who is starting\n> from scratch, I really question how much it helps, and how much it\n> might hurt, to see the two character shortcuts or even to have to\n> remember the two character shortcuts. And for a command like \"rebase\"\n> where the user can very easily shoot themselves in the foot to begin\n> with, I'd actually suggest that it's a _good_ thing that they have to\n> type it out in full.\n\nagreed, of all the things that people complain about regarding learning git, the \nfact that the commands are words instead of cryptic 2 letter abberviations is \nnot one of them.\n\nThe complaints tend to be far more about how there are inconsistancies between \ncommands, or they don't understand what's happening.\n\nAdding a new inconsistancy, or changing words to abbreviations is a further \nbarrier against new users, not an advantage for them.\n\nDavid Lang\n"},{"id":"239526","messageId":"5358845caeba7_59ed83d3087d@nysa.notmuch","threadId":"36457","inReplyTo":"xmqqmwfd2fa5.fsf@gitster.dls.corp.google.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T03:26:20Z","receivedAt":"2014-04-24T03:26:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > I am not fundamentally opposed. I just do not think it would add\n> > much value to new people at this point, and it will actively hurt\n> > if we shoved barely cooked one in 2.0.\n> >\n> > A few thinking points that are necessary to be worked out, even\n> > before we start imagining a plan to introduce them, off the top of\n> > my head, are these:\n> >\n> > * Should we add many random aliases, or should we limit ourselves\n> > only to a narrow set that everybody can agree on?\n> >\n> > * What is the additional cognitive load do we feel comfortable\n> > burdening with the new users?\n> >\n> > * What is the exact mechanism to give these built-in aliases?\n> >\n> > Imagine that somebody says \"[alias] ci = commit\" and a handful of\n> > vocal people on this list agree that it is a good idea. Many random\n> > websites start mentioning \"git ci -a\" in their beginner examples.\n> >\n> > Users are led to think \"ci\" is a command just like \"commit\" and does\n> > the same thing.... and need to learn that only the\n> > first kind and not the second kind cannot be used to define their\n> > own alias (and the users need to learn \"commit\" at that time as\n> > well).\n> \n> A bit further on this point, looking into the future.\n> \n> It might help if we added some \"introduction\" phase to the first\n> invocation of \"git init\", \"git clone\", etc. that is interactively\n> run on a machine where there is no $HOME/.gitconfig detected, and\n> help the user populate it with a few selected and uncontroversial\n> ones. Such a session might go like this:\n> \n> \t$ git init\n> ... We do not see $HOME/.gitconfig; using Git for the first time?\n\nWe shouldn't say $HOME/.gitconfig, that's not user friendly, and it might not\nbe accurate.\n\nPlus, we might prefer $XDG_CONFIG_HOME/.config/git/config.\n\n\"There doesn't seem to be a Git user configuration.\" is enough.\n\n> >> Do you want us to add a few sample aliases to your configuration file?\n> Y\n\nI don't see the point in asking this, just put them, the user can remove them\nif he doesn't want.\n\n> ... Done. You can further tweak $HOME/.gitconfig to suit\n> ... Git to your taste.\n\nAagain not friendly. `git config --global --edit`.\n\n> And it would end up with something like this:\n> \n> \t$ cat $HOME/.gitconfig\n> [user]\n> \t\tname = <>\n> email = <>\n> \t[alias]\n> \tco = checkout\n> \t\tlg = log --oneline\n> \n> which can serve as an example the user can then tweak, without\n> giving any false impression that \"co\" is any more special than\n> whatever the user adds as a custom alias.\n\nYou are assuming the user wanted to \"further tweak\", most likely he didn't, in\nwhich case he wouldn't have seen those aliases.\n\nIt would be more friendly if the aliases are always there, then we can mention\nthem in the documentation of the relevant commands.\n\n-- \nFelipe Contreras\n"},{"id":"239527","messageId":"5358869b2937_59ed83d308fe@nysa.notmuch","threadId":"36457","inReplyTo":"87y4yxc89r.fsf@fencepost.gnu.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T03:35:55Z","receivedAt":"2014-04-24T03:35:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > Theodore Ts'o wrote:\n> >\n> >> This is especially true for commands which might not be used as often\n> >> -- e.g., \"rebase\", and for commands where the meaning of \"git commit\"\n> >> without any argument is qualitatively different from what \"ci\" (for\n> >> checkin) means in most other source management systems.\n> >\n> > ci means commit in Mercurial.\n> \n> Does it mean \"commit the staging area\"?\n\nIt means \"hg commit\".\n\n> > It would help when the user starts to think \"Geez, I seem to be typing\n> > `git checkout` an awful lot, I wonder if there's a shortcut\", which if\n> > the .gitconfigs out there are any indication, it happens all the time.\n> \n> Actually, it happens very rarely if you are talking about _real_\n> gitconfigs deployed by projects as compared to _sample_ gitconfigs\n> demonstrating Git features for _personal_ rather than project-wide use.\n\nThere's no such thing as gitconfigs deployed by projects, and if there were\nthey would be irrelevant.\n\nWe are talking about *people* using Git's command line interface, and people\nhave *personal* configs, that's it.\n\nAnd it's only those configs we have access to, and the only sources of\ninformation we have to make a guess if users ask the question \"Geez, I seem to\nbe typing `git checkout` an awful lot, I wonder if there's a shortcut\".\n\n> >> And for a command like \"rebase\" where the user can very easily shoot\n> >> themselves in the foot to begin with, I'd actually suggest that it's\n> >> a _good_ thing that they have to type it out in full.\n> >\n> > And now you contradict yourself; you actually want to make life harder\n> > for new users, on purpose.\n> \n> Life's hardness is not proportional to the number of typed characters\n\nIt is. Why do you think people set aliases? To make their life harder?\n\nAnyway, if you disagree change one of your frequently used passwords to a\nchapter of The Lord of the Rings for a day. Let's see if you still think that.\n\n-- \nFelipe Contreras\n"},{"id":"239528","messageId":"53588713347b7_59ed83d308cf@nysa.notmuch","threadId":"36457","inReplyTo":"alpine.DEB.2.02.1404221523060.14881@nftneq.ynat.uz","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T03:37:55Z","receivedAt":"2014-04-24T03:37:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Lang wrote:\n> agreed, of all the things that people complain about regarding learning git,\n> the fact that the commands are words instead of cryptic 2 letter\n> abberviations is not one of them.\n\nIt is when they start to use Git seriously and type them a lot.\n\n> The complaints tend to be far more about how there are inconsistancies\n> between commands, or they don't understand what's happening.\n\nYes, but you don't see anybody trying to improve those, do you?\n\nThis is low-hanging fruit we can actually change.\n\n-- \nFelipe Contreras\n"},{"id":"239529","messageId":"alpine.DEB.2.02.1404232050340.14881@nftneq.ynat.uz","threadId":"36457","inReplyTo":"53588713347b7_59ed83d308cf@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-04-24T03:51:43Z","receivedAt":"2014-04-24T03:51:43Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 23 Apr 2014, Felipe Contreras wrote:\n\n> David Lang wrote:\n>> agreed, of all the things that people complain about regarding learning git,\n>> the fact that the commands are words instead of cryptic 2 letter\n>> abberviations is not one of them.\n>\n> It is when they start to use Git seriously and type them a lot.\n\nIf that was such a significant factor, nobody would use Java with it's horribly \nlong function names.\n\nPeople are far more bothered about all the switches to remember and the options \nfor them than they are the fact that they have to type entire words.\n\nDavid Lang\n\n>> The complaints tend to be far more about how there are inconsistancies\n>> between commands, or they don't understand what's happening.\n>\n> Yes, but you don't see anybody trying to improve those, do you?\n>\n> This is low-hanging fruit we can actually change.\n>\n>\n"},{"id":"239531","messageId":"53588be5192d5_59ed83d30824@nysa.notmuch","threadId":"36457","inReplyTo":"alpine.DEB.2.02.1404232050340.14881@nftneq.ynat.uz","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T03:58:29Z","receivedAt":"2014-04-24T03:58:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Lang wrote:\n> On Wed, 23 Apr 2014, Felipe Contreras wrote:\n> \n> > David Lang wrote:\n> >> agreed, of all the things that people complain about regarding learning git,\n> >> the fact that the commands are words instead of cryptic 2 letter\n> >> abberviations is not one of them.\n> >\n> > It is when they start to use Git seriously and type them a lot.\n> \n> If that was such a significant factor, nobody would use Java with it's horribly \n> long function names.\n\nThere are these things called IDE's where people don't end up typing the whole\nfunction names. Take a look.\n\n> People are far more bothered about all the switches to remember and the options \n> for them than they are the fact that they have to type entire words.\n\nThis is, again, a red herring. The fact that B is more important doesn't mean A\nshouldn't be done.\n\n-- \nFelipe Contreras\n"},{"id":"239534","messageId":"53588f448d817_59ed83d3084e@nysa.notmuch","threadId":"36457","inReplyTo":"CAHYYfeHeJYZ67chSTQk2grsFGr07KXcVNR-T6kOPo0bVYDm59g@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T04:12:52Z","receivedAt":"2014-04-24T04:12:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe Contreras wrote:\n> > It is when they start to use Git seriously and type them a lot.\n> \n> Felipe, I think you refute your own point here, because people _learning_ git\n> aren't power-users. They might be one day, but not that day. If power-users\n> are complaining that \"commit\" is too long, but aren't setting their own\n> aliases,\n\nThis is a false dichotomy; there aren't just two kinds of Git users.\n\nThere is such a category of Git users who are not fresh-out-of-the-boat, yet\nnot power users either.\n\n> it's quite possible they just don't know about aliases. Because if they\n> _did_ know about aliases, they'd set one.\n\nUnless the aliases are already there by default.\n\nAnd if default aliases were such a bad idea, why do most (all?) version control\nsystems out there have them?\n\n-- \nFelipe Contreras\n"},{"id":"239533","messageId":"CAHYYfeHeJYZ67chSTQk2grsFGr07KXcVNR-T6kOPo0bVYDm59g@mail.gmail.com","threadId":"36457","inReplyTo":"53588713347b7_59ed83d308cf@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-24T04:16:29Z","receivedAt":"2014-04-24T04:16:29Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n>>David Lang wrote:\n>> agreed, of all the things that people complain\nabout regarding learning git,\n>> the fact that the commands are words instead of\ncryptic 2 letter\n>> abberviations is not one of them.\n>It is when they start to use Git seriously and type\nthem a lot.\n\nFelipe, I think you refute your own point here, because people _learning_\ngit aren't power-users. They might be one day, but not that day.\n\nIf power-users are complaining that \"commit\" is too long, but aren't\nsetting their own aliases, it's quite possible they just don't know about\naliases. Because if they _did_ know about aliases, they'd set one.\nEven a shell alias,\nnot nessecarily a git alias.\n\nI submit to you (with the backing of all my prior experience contributing to\ngit... Which is too say none) that the problem is not that git has a\nsingle, good,\nobvious and memorable commit command.\n\nThe problem is that those specific power-users don't know to use aliases.\n\n--\nJames Denholm\n"},{"id":"239536","messageId":"87eh0nb901.fsf@fencepost.gnu.org","threadId":"36457","inReplyTo":"5358869b2937_59ed83d308fe@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-24T05:18:38Z","receivedAt":"2014-04-24T05:18:38Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>\n>> Life's hardness is not proportional to the number of typed characters\n>\n> It is. Why do you think people set aliases? To make their life harder?\n>\n> Anyway, if you disagree change one of your frequently used passwords\n> to a chapter of The Lord of the Rings for a day. Let's see if you\n> still think that.\n\nSee? You made your life easier by typing a lot of hogwash, saving\nyourself the effort of finding a compelling argument.\n\n-- \nDavid Kastrup\n"},{"id":"239537","messageId":"CAHYYfeFKW93GH+6-ssR5L_uoo3OL2-LFAsj-4+8uEmL0BhT3ow@mail.gmail.com","threadId":"36457","inReplyTo":"53588f448d817_59ed83d3084e@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-24T06:06:57Z","receivedAt":"2014-04-24T06:06:57Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n>This is a false dichotomy; there aren't just two kinds\n> of Git users.\n>\n> There is such a category of Git users who are not\n> fresh-out-of-the-boat, yet not power users either.\n\nOh, I didn't mean to suggest a dichotomy of any kind. However these\nare the two groups (I\nsuggest) are the most immediately relevant - one calls for change, and\nthe other would be negatively impacted.\n\n> Unless the aliases are already there by default.\n\nOthers, with knowledge far beyond mine, have pointed out the problems\nwith this. I'd suggest the\nargument most relevant to my own statements is how it impacts the\nlearning proccess, and makes it\nmore likely that users will learn aliases _as_ commands, which of\ncourse is incorrect and\npotentially harmful.\n\n> And if default aliases were such a bad idea, why do\n most (all?) version control\n systems out there\n> have them?\n\nI'm so tempted just to sass and say that it's because they aren't git...\n\nBut on a more serious note, a feature (any feature) being in one vcs\ndoesn't mean, by default,\nthat it's right for git. The status quo may be a mistake on the part\nof it's followers.\n\n(And, historically, has been many times - for an\ntransculturally-acceptable example, consider the\nrejection of Galileo's astronomical research by the Vatican of the time.)\n\nJust because Mercurial et. all does something doesn't mean git needs\nto, or even should. It needs\nobjective consideration, not to just be ushered through on the basis\nof tradition.\n\n--\nJames Denholm\n"},{"id":"239540","messageId":"5358bae8ab550_1f7b143d31037@nysa.notmuch","threadId":"36457","inReplyTo":"CAHYYfeFKW93GH+6-ssR5L_uoo3OL2-LFAsj-4+8uEmL0BhT3ow@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T07:19:04Z","receivedAt":"2014-04-24T07:19:04Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe Contreras wrote:\n> >This is a false dichotomy; there aren't just two kinds\n> > of Git users.\n> >\n> > There is such a category of Git users who are not\n> > fresh-out-of-the-boat, yet not power users either.\n> \n> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the\n> two groups (I suggest) are the most immediately relevant - one calls for\n> change, and the other would be negatively impacted.\n\nNobody would be negatively impacted. Who would be impacted negatively by having\ndefault aliases?\n\n> > Unless the aliases are already there by default.\n> \n> Others, with knowledge far beyond mine, have pointed out the problems\n> with this.\n\nAnd I have showed they are not problems.\n\n> I'd suggest the argument most relevant to my own statements is how it impacts\n> the learning proccess, and makes it more likely that users will learn aliases\n> _as_ commands, which of course is incorrect and potentially harmful.\n\nThat is an assumption. Why would a user think 'co' is a command?\n\n> > And if default aliases were such a bad idea, why do most (all?) version\n> > control systems out there have them?\n> \n> I'm so tempted just to sass and say that it's because they aren't git...\n> \n> But on a more serious note, a feature (any feature) being in one vcs doesn't\n> mean, by default, that it's right for git.\n\nHow is Git different from any other version control systems?\n\nCommands are commands.\n\n> The status quo may be a mistake on the part of it's followers.\n\nYes, it might, but it's not.\n\n> (And, historically, has been many times - for an transculturally-acceptable\n> example, consider the rejection of Galileo's astronomical research by the\n> Vatican of the time.)\n\nYes, I'm perfecly aware that everybody _can_ be wrong, that doesn't mean they\n_are_.\n\n> Just because Mercurial et. all does something doesn't mean git needs to, or\n> even should. It needs objective consideration, not to just be ushered through\n> on the basis of tradition.\n\nAgain, this is a red herring. Nobody argued that Git should do this because\nothers are doing it.\n\nYou failed to answer the question, so I'm asking it again:\n\nIf default aliases were such a bad idea, why do most (all?) version control\nsystems out there have them?\n\nYour answer seems to be along the lines of: they made a mistake and they are\nall wrong. Is it?\n\nBut, surely if it's a mistake on their part you should be able to find people\naffected by this horrible error. This would validate the arguments that others\nhave put forward; if we do X we will have problem Y. Well, other projects have\ndone X, do they have problem Y?\n\n-- \nFelipe Contreras\n"},{"id":"239542","messageId":"877g6fb2h6.fsf@fencepost.gnu.org","threadId":"36457","inReplyTo":"5358bae8ab550_1f7b143d31037@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-24T07:39:33Z","receivedAt":"2014-04-24T07:39:33Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> James Denholm wrote:\n>> Felipe Contreras wrote:\n>> >This is a false dichotomy; there aren't just two kinds\n>> > of Git users.\n>> >\n>> > There is such a category of Git users who are not\n>> > fresh-out-of-the-boat, yet not power users either.\n>> \n>> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the\n>> two groups (I suggest) are the most immediately relevant - one calls for\n>> change, and the other would be negatively impacted.\n>\n> Nobody would be negatively impacted. Who would be impacted negatively\n> by having default aliases?\n\nThe people having to read and understand scripts written in the\nexpectation of default aliases.\n\n> And I have showed they are not problems.\n\nYou managed to convince yourself, so feel free to put aliases in every\nGit you use and distribute.\n\n-- \nDavid Kastrup\n"},{"id":"239545","messageId":"5358ca1a55a69_1f7b143d3101c@nysa.notmuch","threadId":"36457","inReplyTo":"877g6fb2h6.fsf@fencepost.gnu.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T08:23:54Z","receivedAt":"2014-04-24T08:23:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > James Denholm wrote:\n> >> Felipe Contreras wrote:\n> >> >This is a false dichotomy; there aren't just two kinds\n> >> > of Git users.\n> >> >\n> >> > There is such a category of Git users who are not\n> >> > fresh-out-of-the-boat, yet not power users either.\n> >> \n> >> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the\n> >> two groups (I suggest) are the most immediately relevant - one calls for\n> >> change, and the other would be negatively impacted.\n> >\n> > Nobody would be negatively impacted. Who would be impacted negatively\n> > by having default aliases?\n> \n> The people having to read and understand scripts written in the\n> expectation of default aliases.\n\nWhich are imaginary.\n\n> > And I have showed they are not problems.\n> \n> You managed to convince yourself, so feel free to put aliases in every\n> Git you use and distribute.\n\nThere is evidence for the claim that there won't be those problems. You have\nabsolutely no evidence there there will.\n\n-- \nFelipe Contreras\n"},{"id":"239547","messageId":"8738h3ayom.fsf@fencepost.gnu.org","threadId":"36457","inReplyTo":"5358ca1a55a69_1f7b143d3101c@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-24T09:01:29Z","receivedAt":"2014-04-24T09:01:29Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>> Felipe Contreras writes:\n>> \n>> > James Denholm wrote:\n>> >> Felipe Contreras wrote:\n>> >> >This is a false dichotomy; there aren't just two kinds\n>> >> > of Git users.\n>> >> >\n>> >> > There is such a category of Git users who are not\n>> >> > fresh-out-of-the-boat, yet not power users either.\n>> >> \n>> >> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the\n>> >> two groups (I suggest) are the most immediately relevant - one calls for\n>> >> change, and the other would be negatively impacted.\n>> >\n>> > Nobody would be negatively impacted. Who would be impacted negatively\n>> > by having default aliases?\n>> \n>> The people having to read and understand scripts written in the\n>> expectation of default aliases.\n>\n> Which are imaginary.\n\nAnd I prefer them to stay that way since then one does not need to worry\nabout them.\n\n>> > And I have showed they are not problems.\n>> \n>> You managed to convince yourself, so feel free to put aliases in\n>> every Git you use and distribute.\n>\n> There is evidence for the claim that there won't be those\n> problems. You have absolutely no evidence there there will.\n\nAs I said: you managed to convince yourself and may milk that for all\nthat it's worth.\n\n-- \nDavid Kastrup\n"},{"id":"239565","messageId":"20140424133910.GA26427@inner.h.apk.li","threadId":"36457","inReplyTo":"5358869b2937_59ed83d308fe@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2014-04-24T13:39:10Z","receivedAt":"2014-04-24T13:39:10Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Wed, 23 Apr 2014 22:35:55 +0000, Felipe Contreras wrote:\n...\n> Anyway, if you disagree change one of your frequently used passwords to a\n> chapter of The Lord of the Rings for a day. Let's see if you still think that.\n\nProving that one extreme isn't the optimum doesn't prove the other is.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"239566","messageId":"20140424134106.GA27035@thunk.org","threadId":"36457","inReplyTo":"5358ca1a55a69_1f7b143d3101c@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-04-24T13:41:06Z","receivedAt":"2014-04-24T13:41:06Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:\n> \n> There is evidence for the claim that there won't be those problems. You have\n> absolutely no evidence there there will.\n\nFelipe,\n\nIt's clear that you've not been able to produce evidence that can\nconvince most of the people on this thread. Simply repeating the same\nassertions over and over again, in a shrill fashion, is not likely to\nconvince those of us who that this would not be a good idea for git\nv2.0.\n\nCreating a ~/.gitconfig file if one doesn't already is one I agree\nwith, and at least on Unix systems, telling them that the config file\nlives in ~/.gitconfig, or where ever it might happen to be on other\nplatforms, is a good one. If it's in some really weird place on\nWindows, then sure, we can tell them about \"git config -e\". But the\npoint is to let the user look at the default .gitconfig file, where we\ncan put in comments to help explain what is going on, and perhaps have\nlinks to web pages for more information.\n\nI don't even think we need to query the user to fill out all of the\nfields. We can prepopulate a lot of the fields (name, e-mail address,\netc.) from OS specific defaults that are available on most systems ---\nspecifically, the default values we would use the name and e-mail\naddress are not specified in a config file.\n\nWe can just tell the user that we have created a default .gitconfig\nfile, and tell them how they can take a look at it.\n\nIn the long term, if the worry is how to bridge the gap between\ncomplete newbies, one way of dealing with this is to have a tutorial\nmode (off by default, on in the default .gitconfig) which despenses\nsome helpful hints at certain strategic points (i.e., after five\ncommits, give a message that introduces git log --oneline, after the\nthird merge commit is created by the user, give a message which\nintroduces git log --merge, and so on). The challenge is not strawing\nover the line to the point where the hints become as annoying as\n\"clippy\", but that is what UX labs are for, to tune the experience for\ncompletely new users to git.\n\nWithout doing a formal UX experiment, all of us are going to making\nassertions without formal evidence --- at best some of us who have\ntutored a few newbies might have some anecdates, but remember the old\nsaying about the plural of anecdote not being data.\n\nCheers,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"239568","messageId":"CALbm-EbBj1hCF=rFfeBbzeVmffRHVEEE=HSbVZxw-=-=p2BvEQ@mail.gmail.com","threadId":"36457","inReplyTo":"20140424134106.GA27035@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2014-04-24T15:00:13Z","receivedAt":"2014-04-24T15:00:13Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> I don't even think we need to query the user to fill out all of the\n> fields. We can prepopulate a lot of the fields (name, e-mail address,\n> etc.) from OS specific defaults that are available on most systems ---\n> specifically, the default values we would use the name and e-mail\n> address are not specified in a config file.\n\nPlease don't. Or you end up again with Commiters like sb@localhost,\nsbeller@(None) or alike. I mean it's just one question once you setup\na new computer, so I'd really like to see that question and then\nanswer myself (at university/employer I might put in another email\naddress than at home anyway, and I'm sure my boxes have no sane\ndefaults)\n\n2014-04-24 15:41 GMT+02:00 Theodore Ts'o :\n> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:\n>>\n>> There is evidence for the claim that there won't be those problems. You have\n>> absolutely no evidence there there will.\n>\n> Felipe,\n>\n> It's clear that you've not been able to produce evidence that can\n> convince most of the people on this thread. Simply repeating the same\n> assertions over and over again, in a shrill fashion, is not likely to\n> convince those of us who that this would not be a good idea for git\n> v2.0.\n>\n> Creating a ~/.gitconfig file if one doesn't already is one I agree\n> with, and at least on Unix systems, telling them that the config file\n> lives in ~/.gitconfig, or where ever it might happen to be on other\n> platforms, is a good one. If it's in some really weird place on\n> Windows, then sure, we can tell them about \"git config -e\". But the\n> point is to let the user look at the default .gitconfig file, where we\n> can put in comments to help explain what is going on, and perhaps have\n> links to web pages for more information.\n>\n> I don't even think we need to query the user to fill out all of the\n> fields. We can prepopulate a lot of the fields (name, e-mail address,\n> etc.) from OS specific defaults that are available on most systems ---\n> specifically, the default values we would use the name and e-mail\n> address are not specified in a config file.\n>\n> We can just tell the user that we have created a default .gitconfig\n> file, and tell them how they can take a look at it.\n>\n> In the long term, if the worry is how to bridge the gap between\n> complete newbies, one way of dealing with this is to have a tutorial\n> mode (off by default, on in the default .gitconfig) which despenses\n> some helpful hints at certain strategic points (i.e., after five\n> commits, give a message that introduces git log --oneline, after the\n> third merge commit is created by the user, give a message which\n> introduces git log --merge, and so on). The challenge is not strawing\n> over the line to the point where the hints become as annoying as\n> \"clippy\", but that is what UX labs are for, to tune the experience for\n> completely new users to git.\n>\n> Without doing a formal UX experiment, all of us are going to making\n> assertions without formal evidence --- at best some of us who have\n> tutored a few newbies might have some anecdates, but remember the old\n> saying about the plural of anecdote not being data.\n>\n> Cheers,\n>\n> - Ted\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"239572","messageId":"20140424154717.GB7531@thunk.org","threadId":"36457","inReplyTo":"CALbm-EbBj1hCF=rFfeBbzeVmffRHVEEE=HSbVZxw-=-=p2BvEQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"","fromEmail":"tytso@mit.edu","sentAt":"2014-04-24T15:47:18Z","receivedAt":"2014-04-24T15:47:18Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:\n> > I don't even think we need to query the user to fill out all of the\n> > fields. We can prepopulate a lot of the fields (name, e-mail address,\n> > etc.) from OS specific defaults that are available on most systems ---\n> > specifically, the default values we would use the name and e-mail\n> > address are not specified in a config file.\n> \n> Please don't. Or you end up again with Commiters like sb@localhost,\n> sbeller@(None) or alike. I mean it's just one question once you setup\n> a new computer, so I'd really like to see that question and then\n> answer myself (at university/employer I might put in another email\n> address than at home anyway, and I'm sure my boxes have no sane\n> defaults)\n\nBut that's no worse than what we have today. What if we print what\nthe defaults were, which might help encourage the user to actually run\nthe \"git config -e\" command?\n\n\t\t\t\t\t- Ted\n"},{"id":"239579","messageId":"CALbm-Ea4oAQ+JsYu6Zo06ONMbtp8AhgFqDC485BRKsM36EVQXw@mail.gmail.com","threadId":"36457","inReplyTo":"20140424154717.GB7531@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2014-04-24T17:46:38Z","receivedAt":"2014-04-24T17:46:38Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"I may have missunderstood.\n\nSo today you cannot commit if you don't provide an email address\n(usually the first time you try to commit, git asks to \"git config\n--global author.email=\"), if I remember correctly, so\nthere is definitely a valid (i.e. user approved) email address.\n\n2014-04-24 17:47 GMT+02:00 :\n> On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:\n>> > I don't even think we need to query the user to fill out all of the\n>> > fields. We can prepopulate a lot of the fields (name, e-mail address,\n>> > etc.) from OS specific defaults that are available on most systems ---\n>> > specifically, the default values we would use the name and e-mail\n>> > address are not specified in a config file.\n>>\n>> Please don't. Or you end up again with Commiters like sb@localhost,\n>> sbeller@(None) or alike. I mean it's just one question once you setup\n>> a new computer, so I'd really like to see that question and then\n>> answer myself (at university/employer I might put in another email\n>> address than at home anyway, and I'm sure my boxes have no sane\n>> defaults)\n>\n> But that's no worse than what we have today. What if we print what\n> the defaults were, which might help encourage the user to actually run\n> the \"git config -e\" command?\n>\n> - Ted\n"},{"id":"239580","messageId":"20140424180204.GL15516@google.com","threadId":"36457","inReplyTo":"CALbm-Ea4oAQ+JsYu6Zo06ONMbtp8AhgFqDC485BRKsM36EVQXw@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-04-24T18:02:04Z","receivedAt":"2014-04-24T18:02:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Stefan Beller wrote:\n\n> I may have missunderstood.\n>\n> So today you cannot commit if you don't provide an email address\n> (usually the first time you try to commit, git asks to \"git config\n> --global author.email=\"), if I remember correctly, so\n> there is definitely a valid (i.e. user approved) email address.\n\nNot true. But you do get a big wall of text when you make your\nfirst commit without an EMAIL envvar or configured [user] section,\nincluding\n\n| You can suppress this message by setting them explicitly:\n|\n| git config --global user.name \"Your Name\"\n| git config --global user.email you@example.com\n|\n| After doing this, you may fix the identity used for this commit with:\n| \n| git commit --amend --reset-author\n\nCiao,\nJonathan\n"},{"id":"239583","messageId":"535955235cd75_3241f112ecb@nysa.notmuch","threadId":"36457","inReplyTo":"20140424154717.GB7531@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T18:17:07Z","receivedAt":"2014-04-24T18:17:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"tytso@ wrote:\n> On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:\n> > > I don't even think we need to query the user to fill out all of the\n> > > fields. We can prepopulate a lot of the fields (name, e-mail address,\n> > > etc.) from OS specific defaults that are available on most systems ---\n> > > specifically, the default values we would use the name and e-mail\n> > > address are not specified in a config file.\n> > \n> > Please don't. Or you end up again with Commiters like sb@localhost,\n> > sbeller@(None) or alike. I mean it's just one question once you setup\n> > a new computer, so I'd really like to see that question and then\n> > answer myself (at university/employer I might put in another email\n> > address than at home anyway, and I'm sure my boxes have no sane\n> > defaults)\n> \n> But that's no worse than what we have today. What if we print what\n> the defaults were, which might help encourage the user to actually run\n> the \"git config -e\" command?\n\nIn addition we shouldn't consider user@host a valid e-mail. In the vast\nmajority of cases it's not.\n\nhttp://article.gmane.org/gmane.comp.version-control.git/232027\n\n-- \nFelipe Contreras\n"},{"id":"239586","messageId":"5359572b40d4f_3241f112ecf6@nysa.notmuch","threadId":"36457","inReplyTo":"CALbm-Ea4oAQ+JsYu6Zo06ONMbtp8AhgFqDC485BRKsM36EVQXw@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T18:25:47Z","receivedAt":"2014-04-24T18:25:47Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Stefan Beller wrote:\n> I may have missunderstood.\n> \n> So today you cannot commit if you don't provide an email address\n> (usually the first time you try to commit, git asks to \"git config\n> --global author.email=\"), if I remember correctly, so\n> there is definitely a valid (i.e. user approved) email address.\n\nThat's not true, that's only the case if you don't have a fully qualified\nhostname, like 'localhost', but if you do, like localhost.redhat, then Git\nassumes your email is user@localhost.redhat, and it's valid.\n\n-- \nFelipe Contreras\n"},{"id":"239587","messageId":"53595759dce2a_3241f112ec9b@nysa.notmuch","threadId":"36457","inReplyTo":"20140424180204.GL15516@google.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T18:26:33Z","receivedAt":"2014-04-24T18:26:33Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jonathan Nieder wrote:\n> Stefan Beller wrote:\n> \n> > I may have missunderstood.\n> >\n> > So today you cannot commit if you don't provide an email address\n> > (usually the first time you try to commit, git asks to \"git config\n> > --global author.email=\"), if I remember correctly, so\n> > there is definitely a valid (i.e. user approved) email address.\n> \n> Not true. But you do get a big wall of text when you make your\n> first commit without an EMAIL envvar or configured [user] section,\n> including\n\nOnly if you don't have a fully qualified hostname.\n\n-- \nFelipe Contreras\n"},{"id":"239589","messageId":"535957e225e7b_3241f112ecc3@nysa.notmuch","threadId":"36457","inReplyTo":"8738h3ayom.fsf@fencepost.gnu.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T18:28:50Z","receivedAt":"2014-04-24T18:28:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> > David Kastrup wrote:\n> >> The people having to read and understand scripts written in the\n> >> expectation of default aliases.\n> >\n> > Which are imaginary.\n> \n> And I prefer them to stay that way since then one does not need to worry\n> about them.\n\nIf everybody was afraid of moving because of imaginary fears like you, nothing\nwould get done in this world. Rational people distinguish the imaginary from\nthe real.\n\n-- \nFelipe Contreras\n"},{"id":"239591","messageId":"5359587cbe1bb_3241f112ecf8@nysa.notmuch","threadId":"36457","inReplyTo":"20140424133910.GA26427@inner.h.apk.li","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T18:31:24Z","receivedAt":"2014-04-24T18:31:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andreas Krey wrote:\n> On Wed, 23 Apr 2014 22:35:55 +0000, Felipe Contreras wrote:\n> ...\n> > Anyway, if you disagree change one of your frequently used passwords to a\n> > chapter of The Lord of the Rings for a day. Let's see if you still think\n> > that.\n> \n> Proving that one extreme isn't the optimum doesn't prove the other is.\n\nIt's called hyperbole, and it's a very common and very effective rhetorical\ndevice.\n\nNobody argued that the extreme opposite was best.\n\nMy point was that the amount of characters you type _does_ matter, and I think\nI proved my point.\n\n-- \nFelipe Contreras\n"},{"id":"239593","messageId":"53595a107cf1f_3241f112ec72@nysa.notmuch","threadId":"36457","inReplyTo":"20140424134106.GA27035@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-24T18:38:08Z","receivedAt":"2014-04-24T18:38:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Theodore Ts'o wrote:\n> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:\n> > \n> > There is evidence for the claim that there won't be those problems. You have\n> > absolutely no evidence there there will.\n> \n> It's clear that you've not been able to produce evidence that can\n> convince most of the people on this thread.\n\nWhich only proves you don't want to be convinced, no evidence could convince\nyou.\n\n> I don't even think we need to query the user to fill out all of the\n> fields. We can prepopulate a lot of the fields (name, e-mail address,\n> etc.) from OS specific defaults that are available on most systems ---\n> specifically, the default values we would use the name and e-mail\n> address are not specified in a config file.\n\nMost systems don't have a configured $EMAIL, so those defautls would be wrong.\n\nIt's so evident that no evide could convince you that you don't even bothere to\nanswer my question:\n\nWhy does Mercurial, Bazaar, Subversion, CVS, and pretty much everything uses\naliases?\n\nSince you are conveniently not answering, I'll answer for you:\n\nBecause such hypothetical problems wouldn't actually occur in reality with Git,\njust like they don't occur in other tools.\n\n-- \nFelipe Contreras\n"},{"id":"239596","messageId":"20140424191531.GA7815@sigill.intra.peff.net","threadId":"36457","inReplyTo":"53595759dce2a_3241f112ec9b@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-04-24T19:15:32Z","receivedAt":"2014-04-24T19:15:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 24, 2014 at 01:26:33PM -0500, Felipe Contreras wrote:\n\n> Jonathan Nieder wrote:\n> > Stefan Beller wrote:\n> > \n> > > I may have missunderstood.\n> > >\n> > > So today you cannot commit if you don't provide an email address\n> > > (usually the first time you try to commit, git asks to \"git config\n> > > --global author.email=\"), if I remember correctly, so\n> > > there is definitely a valid (i.e. user approved) email address.\n> > \n> > Not true. But you do get a big wall of text when you make your\n> > first commit without an EMAIL envvar or configured [user] section,\n> > including\n> \n> Only if you don't have a fully qualified hostname.\n\nNo, we alway warn if the values weren't explicitly provided:\n\n $ git config --global --unset user.email\n $ git commit --allow-empty -m foo\n [master 1e987ba] foo\n Committer: Jeff King \n Your name and email address were configured automatically based\n on your username and hostname. Please check that they are accurate.\n You can suppress this message by setting them explicitly:\n \n git config --global user.name \"Your Name\"\n git config --global user.email you@example.com\n \n After doing this, you may fix the identity used for this commit with:\n \n git commit --amend --reset-author\n\nbut we will consider several sources explicit, like\n$GIT_COMMITTER_EMAIL, $EMAIL, and of course user.email:\n\n $ EMAIL=whatever@example.com git commit --allow-empty -m foo\n [master e75f17a] foo\n\nWe die when the values are implicitly derived from the system _and_ they\nlook bogus:\n\n $ sudo rm /etc/mailname\n $ sudo hostname bogus\n $ git commit --allow-empty -m foo\n\n *** Please tell me who you are.\n \n Run\n \n git config --global user.email \"you@example.com\"\n git config --global user.name \"Your Name\"\n \n to set your account's default identity.\n Omit --global to set the identity only in this repository.\n \n fatal: unable to auto-detect email address (got 'peff@bogus.(none)')\n\n-Peff\n"},{"id":"239599","messageId":"87y4yua679.fsf@fencepost.gnu.org","threadId":"36457","inReplyTo":"5359587cbe1bb_3241f112ecf8@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-24T19:16:42Z","receivedAt":"2014-04-24T19:16:42Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> Andreas Krey wrote:\n>> On Wed, 23 Apr 2014 22:35:55 +0000, Felipe Contreras wrote:\n>> ...\n>> > Anyway, if you disagree change one of your frequently used passwords to a\n>> > chapter of The Lord of the Rings for a day. Let's see if you still think\n>> > that.\n>> \n>> Proving that one extreme isn't the optimum doesn't prove the other is.\n>\n> It's called hyperbole, and it's a very common and very effective rhetorical\n> device.\n\nLet us conclude this discussion by declaring you the best rhetor then.\n\n-- \nDavid Kastrup\n"},{"id":"239597","messageId":"alpine.DEB.2.02.1404241219520.14881@nftneq.ynat.uz","threadId":"36457","inReplyTo":"535957e225e7b_3241f112ecc3@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-04-24T19:20:46Z","receivedAt":"2014-04-24T19:20:46Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 24 Apr 2014, Felipe Contreras wrote:\n\n> David Kastrup wrote:\n>> Felipe Contreras writes:\n>>> David Kastrup wrote:\n>>>> The people having to read and understand scripts written in the\n>>>> expectation of default aliases.\n>>>\n>>> Which are imaginary.\n>>\n>> And I prefer them to stay that way since then one does not need to worry\n>> about them.\n>\n> If everybody was afraid of moving because of imaginary fears like you, nothing\n> would get done in this world. Rational people distinguish the imaginary from\n> the real.\n\nThe exact same thing could be said for your position that typing rebase instead \nof rb causes a major problem\n\nCalm down and stop accusing everyone of sticking their heads in the ground\n\nDavid Lang\n"},{"id":"239603","messageId":"20140424195559.GA1336@luc-arch","threadId":"36457","inReplyTo":"20140424134106.GA27035@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"","fromEmail":"luc.linux@mailoo.org","sentAt":"2014-04-24T19:55:59Z","receivedAt":"2014-04-24T19:55:59Z","isPatch":false,"sender":{"key":"luc.linux@mailoo.org","avatar":null},"body":"On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote:\n> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:\n> Creating a ~/.gitconfig file if one doesn't already is one I agree\n> with, and at least on Unix systems, telling them that the config file\n> lives in ~/.gitconfig, or where ever it might happen to be on other\n> platforms, is a good one. If it's in some really weird place on\n> Windows, then sure, we can tell them about \"git config -e\". But the\n> point is to let the user look at the default .gitconfig file, where we\n> can put in comments to help explain what is going on, and perhaps have\n> links to web pages for more information.\n\nI think the idea of a commented gitconfig is a good solution. We could\ninclude default aliases commented, so that a new user would just have to\nuncomment them. That way, he will understand they are aliases and not\ncommands, learn how to tune them to its own needs and it won't annoy\nanyone because they will be commented by default, ideally with explicit\ncommentaries around them.\n\nFurthermore, this could be a good way to show a new user all the\npossibilities of git, or at least its configuration. Documentation is a\ngood thing when you know what you are looking for, but when you are\nbeginning, you don't know what can be done, and reading a complete and\ncommented example configuration could be a good way to discover it.\n\n"},{"id":"239625","messageId":"CALZVapn0gEHc7t2fjk7YGd2o0yfpGLu0JCgUtdREvROC8_mqXg@mail.gmail.com","threadId":"36457","inReplyTo":"20140424195559.GA1336@luc-arch","subject":"Re: What is missing from Git v2.0","fromName":"Javier Domingo Cansino","fromEmail":"javierdo1@gmail.com","sentAt":"2014-04-25T02:22:23Z","receivedAt":"2014-04-25T02:22:23Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"Felipe's\n=======\n\n= The publish tracking branch =\nI still have problems getting upstream branches correctly configured\nas to have this introduced, anyway, I suppose it's optional, so\nnothing to add on that.\n\nBy the way, remote branch managing has improved a lot, one of the\nbest things I see for branching and remotes is the \"git remote show\"\ncommand, but I think further work should be done. Help messages FTW!\n\n= Reject non-fast-forward pulls by default =\nNot having this introduced yet allows newbie people to use git with\njust 4 commands, without bothering around with fetch and merge and so.\n\n= Use \"stage\" instead of \"index\" =\nTotally agree with this.\n\n= Default aliases =\nI hate aliases, make scripts more difficult to read and understand. I\nwould instead try to improve knowledge on this feature. I have to\nagree with David Lang's first message, and\n\nThe cherry-pick => pick thing would be the only thing I would see with\ngood eyes, just because it's too long and has a dash.\n\n\nJuno's\n======\nThe idea about ~/.gitconfig seems incredible simple and effective to\nme. I would however try to keep it simple, and minimize the form.\n\n\nMine\n====\nI have taught (or tried to) a lot of people Git. And this is some of\nthe stuff I have seen they have difficulties with:\n- Remembering the commands, for example, remembering add, commit push\nand pull, which I think we can all agree is the most core and simple\ncombination of Git commands.\n- What command comes for what they need. If I want to share\neverything, what should I do?\n- Most of them, have real difficulties on remembering the flows. There\nare too many commands for the start.\n\nI wouldn't nevertheless suppress any of them, I would rather do a tuto\non-the-go.\n\nHere are some ideas I have thought of:\n\n== Command Output==\nAt the moment, there are several commands that don't output any help\ntext, and many others, that although they have become more verbose\nwith the years, they aren't too verbose yet.\n\nOne of the things I most recommend to anyone is to run \"git status\"\njust before any command (push, commit, add, etc.) to get sure they are\ndoing what they thing they will.\n\nFor example, running git add won't tell you what you just added, nor\nwhat you could do now. I would put some output there, maybe the git\nstatus output or something similar that helps the user to know what\njust happened.\n\nGit status doesn't say much about remotes, and suggesting pushing if a\nremote is outdated, would be fantastic.\n\nCheckout command has decreased verbosity from a previous version,\nwhere it stated which branch it came from and to which branch it was\nswitching to.\n\nAs an extreme thing, I would consider adding a configuration parameter\ndefault, core.helptext=True that could switch off all this stuff.\n\n==Running git==\nThis is a very basic idea, and I suppose it isn't too helpful or\nrealistic, but might give someone an idea.\n\nI would first make that running git, just git, tell the user the\npossibilities he has. I don't know of any power user that uses git to\nremember the commands. At the moment, git[1] just tells many of the\ncommands available, without any classification, maybe classifying them\nas \"commiting\" \"branching\" and \"remote\" could help a little.\n\nRegards,\n\nJavier Domingo Cansino\n\n[1] git output:\n----------------------------------------------------\njavier@frodo:~$ git\nusage: git [--version] [--help] [-C ] [-c name=value]\n [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n [--git-dir=] [--work-tree=] [--namespace=]\n []\n\nThe most commonly used git commands are:\n add Add file contents to the index\n bisect Find by binary search the change that introduced a bug\n branch List, create, or delete branches\n checkout Checkout a branch or paths to the working tree\n clone Clone a repository into a new directory\n commit Record changes to the repository\n diff Show changes between commits, commit and working tree, etc\n fetch Download objects and refs from another repository\n grep Print lines matching a pattern\n init Create an empty Git repository or reinitialize an existing one\n log Show commit logs\n merge Join two or more development histories together\n mv Move or rename a file, a directory, or a symlink\n pull Fetch from and integrate with another repository or a local branch\n push Update remote refs along with associated objects\n rebase Forward-port local commits to the updated upstream head\n reset Reset current HEAD to the specified state\n rm Remove files from the working tree and from the index\n show Show various types of objects\n status Show the working tree status\n tag Create, list, delete or verify a tag object signed with GPG\n\n'git help -a' and 'git help -g' lists available subcommands and some\nconcept guides. See 'git help ' or 'git help '\nto read about a specific subcommand or concept.\n----------------------------------------------------\n"},{"id":"239626","messageId":"5359c9d612298_771c15f72f02a@nysa.notmuch","threadId":"36457","inReplyTo":"CALZVapn0gEHc7t2fjk7YGd2o0yfpGLu0JCgUtdREvROC8_mqXg@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-25T02:35:02Z","receivedAt":"2014-04-25T02:35:02Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Javier Domingo Cansino wrote:\n> Felipe's\n> =======\n> \n> = The publish tracking branch =\n> I still have problems getting upstream branches correctly configured\n> as to have this introduced, anyway, I suppose it's optional, so\n> nothing to add on that.\n\nI did so too, until I patch `git branch -v` to be useful.\n\n> = Reject non-fast-forward pulls by default =\n\n> Not having this introduced yet allows newbie people to use git with\n> just 4 commands, without bothering around with fetch and merge and so.\n\nI don't understand what you are trying to say. There is no change for those\npeople, when the pull fails they would be told to use `git pull --merge` if not\nsure.\n\n> = Use \"stage\" instead of \"index\" =\n> Totally agree with this.\n> \n> = Default aliases =\n> I hate aliases, make scripts more difficult to read and understand.\n\nYou are assuming that everyone will start to use aliases in scripts, which is\nnot going to happen enough to be a problem.\n\nTry to find svn or hg scripts with aliases, let's see how many you find.\n\n> Mine\n> ====\n> I have taught (or tried to) a lot of people Git. And this is some of\n> the stuff I have seen they have difficulties with:\n> - Remembering the commands, for example, remembering add, commit push\n> and pull, which I think we can all agree is the most core and simple\n> combination of Git commands.\n> - What command comes for what they need. If I want to share\n> everything, what should I do?\n> - Most of them, have real difficulties on remembering the flows. There\n> are too many commands for the start.\n> \n> I wouldn't nevertheless suppress any of them, I would rather do a tuto\n> on-the-go.\n\nI think you are on the right track but the solution is not to shrug shoulders.\nWe should acknowledge there are serious problems with the interface, list them,\nand try to fix them. One example is `git add $tracked_file` being wrong, it\nshould be `git stage $tracked_file`.\n\nThe real problem is that the core developers of Git don't acknowledge these\nuser-interface issues, according the them the interface doesn't require any\nmajor changes. Which goes contrary to what most of the world believes.\n\n-- \nFelipe Contreras\n"},{"id":"239632","messageId":"87d2g69ekl.fsf@fencepost.gnu.org","threadId":"36457","inReplyTo":"CALZVapn0gEHc7t2fjk7YGd2o0yfpGLu0JCgUtdREvROC8_mqXg@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-25T05:13:30Z","receivedAt":"2014-04-25T05:13:30Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Javier Domingo Cansino writes:\n\n> Felipe's\n> =======\n>\n> = Reject non-fast-forward pulls by default =\n> Not having this introduced yet allows newbie people to use git with\n> just 4 commands, without bothering around with fetch and merge and so.\n\nIf you have a gun lying around your house, you should turn the safety\ncatch off or the children will not be able to use it without\ninstruction.\n\n-- \nDavid Kastrup\n"},{"id":"239631","messageId":"vpqa9b9rj1w.fsf@anie.imag.fr","threadId":"36457","inReplyTo":"20140424154717.GB7531@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-04-25T06:59:23Z","receivedAt":"2014-04-25T06:59:23Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"tytso@mit.edu writes:\n\n> On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote:\n>> > I don't even think we need to query the user to fill out all of the\n>> > fields. We can prepopulate a lot of the fields (name, e-mail address,\n>> > etc.) from OS specific defaults that are available on most systems ---\n>> > specifically, the default values we would use the name and e-mail\n>> > address are not specified in a config file.\n>> \n>> Please don't. Or you end up again with Commiters like sb@localhost,\n>> sbeller@(None) or alike. I mean it's just one question once you setup\n>> a new computer, so I'd really like to see that question and then\n>> answer myself (at university/employer I might put in another email\n>> address than at home anyway, and I'm sure my boxes have no sane\n>> defaults)\n>\n> But that's no worse than what we have today.\n\nIt is. Currently, Git displays a very big and scary warning when you use\ncommit and Git had to guess your identity.\n\nIf you explicitly fill-in the config file with guessed values, then Git\nwill have no way to know if the config values are real or guessed.\n\nOTOH, a prompt with a default value (i.e \"type 'return' to get the\ndefault\") would make sense.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"239633","messageId":"CAGK7Mr5aR36X3x=jcsRWyuo9cS0qGud114gSJECPW0rOWqUFKw@mail.gmail.com","threadId":"36457","inReplyTo":"CALbm-EbBj1hCF=rFfeBbzeVmffRHVEEE=HSbVZxw-=-=p2BvEQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-04-25T07:35:53Z","receivedAt":"2014-04-25T07:35:53Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> > I don't even think we need to query the user to fill out all of the\n> > fields. We can prepopulate a lot of the fields (name, e-mail address,\n> > etc.) from OS specific defaults that are available on most systems ---\n> > specifically, the default values we would use the name and e-mail\n> > address are not specified in a config file.\n>\n> Please don't. Or you end up again with Commiters like sb@localhost,\n> sbeller@(None) or alike. I mean it's just one question once you setup\n> a new computer, so I'd really like to see that question and then\n> answer myself (at university/employer I might put in another email\n> address than at home anyway, and I'm sure my boxes have no sane\n> defaults)\n\nYes, try to guess a good default but let the user change it if he\nwants to, and if he presses enter the default is used. It's not a big\ndeal to have to press enter a few times the first time you use git.\n\nThat or make a new \"git setup\" command which interactively sets up\nyour .gitconfig.\n\nPhilippe\n"},{"id":"239635","messageId":"CAGK7Mr6dss7BF-srQ3SqeZe2hAe9nS07fGe--ka1rvC5hXvbSA@mail.gmail.com","threadId":"36457","inReplyTo":"5359c9d612298_771c15f72f02a@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-04-25T07:48:53Z","receivedAt":"2014-04-25T07:48:53Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> I think you are on the right track but the solution is not to shrug shoulders.\n> We should acknowledge there are serious problems with the interface, list them,\n> and try to fix them. One example is `git add $tracked_file` being wrong, it\n> should be `git stage $tracked_file`.\n\nI agree. The \"stage area\" is a very important concept in git, why not\ntalk git commands that refers to it? Then we could add flags like\n--new-files or --deleted-files for better granularity than the current\n--all flag.\n\n\n> The real problem is that the core developers of Git don't acknowledge these\n> user-interface issues, according the them the interface doesn't require any\n> major changes. Which goes contrary to what most of the world believes.\n\nI think most people agree with these interfaces issues but it's a hard\nproblem to solve, so they are reluctant to talk about it because they\nfear the can of worm. If someone came with a good solution most people\nwould be willing to consider it.\n\nI think starting by documenting the issues is a good idea, maybe on a\nwiki, and start some draft of a proposed solution that would improve\nin an iterative process.\n\nPhilippe\n"},{"id":"239636","messageId":"535a1451b34_2a62c2130c1d@nysa.notmuch","threadId":"36457","inReplyTo":"CAGK7Mr6dss7BF-srQ3SqeZe2hAe9nS07fGe--ka1rvC5hXvbSA@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-25T07:52:49Z","receivedAt":"2014-04-25T07:52:49Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philippe Vaucher wrote:\n> > I think you are on the right track but the solution is not to shrug shoulders.\n> > We should acknowledge there are serious problems with the interface, list them,\n> > and try to fix them. One example is `git add $tracked_file` being wrong, it\n> > should be `git stage $tracked_file`.\n> \n> I agree. The \"stage area\" is a very important concept in git, why not\n> talk git commands that refers to it? Then we could add flags like\n> --new-files or --deleted-files for better granularity than the current\n> --all flag.\n\nLike this:\nhttp://thread.gmane.org/gmane.comp.version-control.git/236127\n\n> > The real problem is that the core developers of Git don't acknowledge these\n> > user-interface issues, according the them the interface doesn't require any\n> > major changes. Which goes contrary to what most of the world believes.\n> \n> I think most people agree with these interfaces issues but it's a hard\n> problem to solve, so they are reluctant to talk about it because they\n> fear the can of worm. If someone came with a good solution most people\n> would be willing to consider it.\n> \n> I think starting by documenting the issues is a good idea, maybe on a\n> wiki, and start some draft of a proposed solution that would improve\n> in an iterative process.\n\nYes, it would be good to document these issues, but it wouldn't matter if the\ndevelopers ignore them.\n\nFor example the move away from the 'index' name was backed up by literally\neveryone, except Junio, so it doesn't matter if the issue is documented, and\nthere are patches with good solutions, if Junio thinks it's not an issue; it's\nignored.\n\n-- \nFelipe Contreras\n"},{"id":"239637","messageId":"20140425133520.GC11124@thunk.org","threadId":"36457","inReplyTo":"CAGK7Mr6dss7BF-srQ3SqeZe2hAe9nS07fGe--ka1rvC5hXvbSA@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-04-25T13:35:20Z","receivedAt":"2014-04-25T13:35:20Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:\n> \n> I agree. The \"stage area\" is a very important concept in git, why not\n> talk git commands that refers to it? Then we could add flags like\n> --new-files or --deleted-files for better granularity than the current\n> --all flag.\n\nOne caution: The term \"stage/staged\" is already a little overloaded.\nWe generally use the word \"staged\" to refer to changes that are in the\nindex, but the term \"stage\" as a noun generally refers to referencing\nthe different versions of a file during a merge operation (cf \"git\nls-files --stage\").\n\n> I think starting by documenting the issues is a good idea, maybe on a\n> wiki, and start some draft of a proposed solution that would improve\n> in an iterative process.\n\nAnd it would be nice if the issues were discussed in a way that\nacknowledged that all changes have tradeoffs, both positive and\nnegative, and to clearly articulate whether the concern is just\nsomeone going \"uh, 'index' is a wierd term\", but once they learn it,\nit's pretty clear, versus a case where there is continuous confusion\ndue to overloaded meanings, or for people for whom English might not\nbe the first language.\n\nAnd most importantly, to avoid rheteroic. In fact, given that strong\nuse of rhetoric is often used to disguise a weakness of a position\nthat can't be defended using logic and data, someone who tries to win\narguments using the \"last post wins\" style of discourse, and a heavy\nuse of rhetoric, may find that people just simply decide that it's a\nbetter use of their time not to engage and to just kill the entire\nthread.\n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"239638","messageId":"CAGK7Mr4g3j80R4P_wpfNip9vxvaDg4q_3Utq9KVvKtbdhVutfQ@mail.gmail.com","threadId":"36457","inReplyTo":"20140425133520.GC11124@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-04-25T14:23:43Z","receivedAt":"2014-04-25T14:23:43Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> I agree. The \"stage area\" is a very important concept in git, why not\n>> talk git commands that refers to it? Then we could add flags like\n>> --new-files or --deleted-files for better granularity than the current\n>> --all flag.\n>\n> One caution: The term \"stage/staged\" is already a little overloaded.\n> We generally use the word \"staged\" to refer to changes that are in the\n> index, but the term \"stage\" as a noun generally refers to referencing\n> the different versions of a file during a merge operation (cf \"git\n> ls-files --stage\").\n\nI agree, but I think it's better than \"index\" tho. That one is heavily\noverloaded and easily confused with other meaning in other softwares.\n\n\n>> I think starting by documenting the issues is a good idea, maybe on a\n>> wiki, and start some draft of a proposed solution that would improve\n>> in an iterative process.\n>\n> And it would be nice if the issues were discussed in a way that\n> acknowledged that all changes have tradeoffs, both positive and\n> negative, and to clearly articulate whether the concern is just\n> someone going \"uh, 'index' is a wierd term\", but once they learn it,\n> it's pretty clear, versus a case where there is continuous confusion\n> due to overloaded meanings, or for people for whom English might not\n> be the first language.\n\nYes, of course there should be a list of both positive and negative\ntradeoffs. But I think the \"overloaded\" argument can be easily solved\nby renaming one of the overloads.\n\n\n> And most importantly, to avoid rheteroic. In fact, given that strong\n> use of rhetoric is often used to disguise a weakness of a position\n> that can't be defended using logic and data, someone who tries to win\n> arguments using the \"last post wins\" style of discourse, and a heavy\n> use of rhetoric, may find that people just simply decide that it's a\n> better use of their time not to engage and to just kill the entire\n> thread.\n\nUnfortunately yes, I see many people being silly in order to win\narguments, both in the pro-changes and against-changes side of the\ndiscussion. I'd be much simpler to simply gather arguments on some\nwiki and eventually do a vote when the list is complete about the\nproposed change.\n\nPhilippe\n"},{"id":"239639","messageId":"20140425144054.GA6230@thunk.org","threadId":"36457","inReplyTo":"CAGK7Mr4g3j80R4P_wpfNip9vxvaDg4q_3Utq9KVvKtbdhVutfQ@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-04-25T14:40:54Z","receivedAt":"2014-04-25T14:40:54Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote:\n> \n> I agree, but I think it's better than \"index\" tho. That one is heavily\n> overloaded and easily confused with other meaning in other softwares.\n\nThere is a big difference between being used in a difference sense\nthan other software --- there is a one-time learning curve after which\npoint people can generally understand that a term in a given context\nhas a single meaning --- and when we have two very easily confused\nterms (i.e., \"stage versus staged\") or a single identical term,\noverloaded within a single context. So I'm much more worried about\nthe git documentation using the same term or two closely related terms\nin an overloaded fashion, much more than I am with \"index\" meaning one\nthing for databases, and another thing for book publishers, and yet\nanother for compilers.\n\n> Yes, of course there should be a list of both positive and negative\n> tradeoffs. But I think the \"overloaded\" argument can be easily solved\n> by renaming one of the overloads.\n\nAnd renaming one of a term also has costs, especially if it is one\nthat is in use in large amounts of documentation, both in the git man\npages, and in web pages across the web.\n\nAnd my plea for data extends even here. For example, things like\nthis:\n\nwww.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q\n\n> Unfortunately yes, I see many people being silly in order to win\n> arguments, both in the pro-changes and against-changes side of the\n> discussion. I'd be much simpler to simply gather arguments on some\n> wiki and eventually do a vote when the list is complete about the\n> proposed change.\n\nVoting is not a good way to do software development. That way lies\npeople wanting to whip up clueless folks using rhetoric (exhibit one:\nFox News) to \"vote\" and so it's not necessarily the best way to make\nthoughtful decisions. Using hard data, including possibly formal UX\nexperiments, is a much better way to make such decisions.\n\nCheers,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"239643","messageId":"20140425154104.GB11479@google.com","threadId":"36457","inReplyTo":"87d2g69ekl.fsf@fencepost.gnu.org","subject":"Re: What is missing from Git v2.0","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-04-25T15:41:04Z","receivedAt":"2014-04-25T15:41:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nDavid Kastrup wrote:\n> Javier Domingo Cansino writes:\n\n>> = Reject non-fast-forward pulls by default =\n>> Not having this introduced yet allows newbie people to use git with\n>> just 4 commands, without bothering around with fetch and merge and so.\n>\n> If you have a gun lying around your house, you should turn the safety\n> catch off or the children will not be able to use it without\n> instruction.\n\nI probably missed a subtlety, but the above comment reminded me of\nsome netiquette I think this list is starting to forget. If I have\nmisread it, please let me know and skip the rest of this message.\n\nThis is a comment about style, not substance. Like coding style,\ndiscussion style matters as a way of making life easier for\nmaintainers and new contributors, and different projects have subtly\ndifferent practices.\n\nOn the git list, the rule is simple. Feel free to grumble, but make\nsure there is some contribution in the same message. For example,\nafter the confusing gun analogy you can say \"How about this patch?\"\nand people reading can follow up by reviewing that patch and\npotentially getting it applied.\n\n\"But what if there's already a patch doing what I want to do?\" you\nmight ask. No problem. Link to the patch and say \"I think this patch\nshould be revisited\", or even better, re-send it with some notes about\nhow previous review comments have been addressed or remain to be\naddressed.\n\n\"How do I get feedback on design of a new change without wasting a lot\nof time coding something that might be a bad idea?\" Glad you asked.\nSometimes instead of a patch, a better contribution is a detailed\nexplanation of a design to be reviewed and adopted. In this case, do\ntry to be clear about whether you'll have enough time to implement the\nresult or will be relying on others so people know how much time to\ndevote to working out the details.\n\n\"What about feature requests? I might have an idea for improving git\nthat no one's had before but I don't have a detailed design in mind.\"\nSure, that can be a good contribution. Just treat it as a gift ---\ndon't assume anyone is going to implement it for you if they're not\ninterested.\n\n\"What about reminders about known bugs? There's this regression and\nit would not be right to release without fixing it but I think it's\nfallen through the cracks.\" Yes, good contribution.\n\n\"What about jokes?\" Sure, making people laugh is productive.\n\n\"What about cryptic grumbling?\" Sorry, unless you are grumbling to\nget input on how to improve git's documentation or code, it's not\nenough to be worth sending an email to this list.\n\nHope that helps,\nJonathan\n"},{"id":"239645","messageId":"CAGK7Mr74TK4x7WYnmWyRUj_Aga0CHbyFNyZGZdu6eubtwahBXg@mail.gmail.com","threadId":"36457","inReplyTo":"20140425144054.GA6230@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-04-25T15:54:17Z","receivedAt":"2014-04-25T15:54:17Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":">> Yes, of course there should be a list of both positive and negative\n>> tradeoffs. But I think the \"overloaded\" argument can be easily solved\n>> by renaming one of the overloads.\n>\n> And renaming one of a term also has costs, especially if it is one\n> that is in use in large amounts of documentation, both in the git man\n> pages, and in web pages across the web.\n\nIt's just impossible to change terms and have previous documentation\nstill be valid. Sure, you can list it in the \"cons\" section as an\nargument, but it's not very convincing in itself because it applies to\npretty much any interface changes. I think the main idea is to\n_improve_ the interface, which means rename things so it is more\nconsistent and so concepts are easier for new comers to grasp. We\ncould still support old terms for a while and eventually deprecate\nthem.\n\n\n> www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q\n\nI think this comparison is a bit bogus, searching for \"git stage\"\nyields more accurate results, we can see the searches are related:\n\nhttp://www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index%2C%20git%20stage&cmpt=q\n\n\n>> Unfortunately yes, I see many people being silly in order to win\n>> arguments, both in the pro-changes and against-changes side of the\n>> discussion. I'd be much simpler to simply gather arguments on some\n>> wiki and eventually do a vote when the list is complete about the\n>> proposed change.\n>\n> Voting is not a good way to do software development. That way lies\n> people wanting to whip up clueless folks using rhetoric (exhibit one:\n> Fox News) to \"vote\" and so it's not necessarily the best way to make\n> thoughtful decisions. Using hard data, including possibly formal UX\n> experiments, is a much better way to make such decisions.\n\nInteresting, but then who's to say which data is more important than\nanothers? For example, I consider improving the interface to be more\nimportant than having old documentation on blogs/tutorial for a while\nuntil people catch up, but maybe you consider old documentation to be\nmore important... who decides what really counts? I guess it's a mix\nof general consensus and old timers credibility.\n\nAnyway, having some data as a list of pros/cons would greatly simplify\nthe debate.\n\nPhilippe\n"},{"id":"239646","messageId":"871twl9z8h.fsf@fencepost.gnu.org","threadId":"36457","inReplyTo":"20140425154104.GB11479@google.com","subject":"Re: What is missing from Git v2.0","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-25T15:59:26Z","receivedAt":"2014-04-25T15:59:26Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jonathan Nieder writes:\n\n> Hi,\n>\n> David Kastrup wrote:\n>> Javier Domingo Cansino writes:\n>\n>>> = Reject non-fast-forward pulls by default =\n>>> Not having this introduced yet allows newbie people to use git with\n>>> just 4 commands, without bothering around with fetch and merge and so.\n>>\n>> If you have a gun lying around your house, you should turn the safety\n>> catch off or the children will not be able to use it without\n>> instruction.\n>\n> I probably missed a subtlety, but the above comment reminded me of\n> some netiquette I think this list is starting to forget. If I have\n> misread it, please let me know and skip the rest of this message.\n>\n> This is a comment about style, not substance. Like coding style,\n> discussion style matters as a way of making life easier for\n> maintainers and new contributors, and different projects have subtly\n> different practices.\n>\n> On the git list, the rule is simple. Feel free to grumble, but make\n> sure there is some contribution in the same message. For example,\n> after the confusing gun analogy you can say \"How about this patch?\"\n> and people reading can follow up by reviewing that patch and\n> potentially getting it applied.\n\nUh, Javier was commenting on a number of concrete proposals regarding\nthe subject line \"What is missing from Git v2.0\" and quoted Felipe\ndirectly. As you seem to have lost the context, let me requote the\nrespective portion:\n\n From: Felipe Contreras \n Subject: What is missing from Git v2.0\n Newsgroups: gmane.comp.version-control.git\n To: git@vger.kernel.org\n Date: Sun, 20 Apr 2014 17:41:05 -0500 (4 days, 17 hours, 12 minutes ago)\n\n [...]\n\n = Reject non-fast-forward pulls by default =\n\n Many new-comers end up making merges by mistake when they pull\n because they don't understand what is a non-fast-forward and what\n they should actually be doing. Most people, even Linus Torvalds,\n agreed that by default `git pull` should fail and guide the user,\n instead of silently making a merge which might not be what the user\n wants (even though he doesn't know it), and messing up the project's\n history, which affects other people.\n\n The patches were sent, the issues were addressed, people agreed, and\n yet nothing happened.\n\n [3][4]\n\n [...]\n\n [3] http://thread.gmane.org/gmane.comp.version-control.git/240030\n [4] http://thread.gmane.org/gmane.comp.version-control.git/235981\n\n\n> \"How do I get feedback on design of a new change without wasting a lot\n> of time coding something that might be a bad idea?\" Glad you asked.\n\nI didn't.\n\n> \"What about reminders about known bugs? There's this regression and\n> it would not be right to release without fixing it but I think it's\n> fallen through the cracks.\" Yes, good contribution.\n>\n> \"What about jokes?\" Sure, making people laugh is productive.\n>\n> \"What about cryptic grumbling?\" Sorry, unless you are grumbling to\n> get input on how to improve git's documentation or code, it's not\n> enough to be worth sending an email to this list.\n>\n> Hope that helps,\n\nNo need to get condescending if you did not get the joke.\n\n-- \nDavid Kastrup\n"},{"id":"239647","messageId":"20140425161443.GE11479@google.com","threadId":"36457","inReplyTo":"871twl9z8h.fsf@fencepost.gnu.org","subject":"Re: What is missing from Git v2.0","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-04-25T16:14:43Z","receivedAt":"2014-04-25T16:14:43Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"David Kastrup wrote:\n> Jonathan Nieder writes:\n\n>> I probably missed a subtlety, but the above comment reminded me of\n>> some netiquette I think this list is starting to forget. If I have\n>> misread it, please let me know and skip the rest of this message.\n[...]\n>> On the git list, the rule is simple. Feel free to grumble, but make\n>> sure there is some contribution in the same message.\n[...]\n> Uh, Javier was commenting on a number of concrete proposals regarding\n> the subject line \"What is missing from Git v2.0\" and quoted Felipe\n> directly. As you seem to have lost the context, let me requote the\n> respective portion:\n\nI hadn't lost the context, but thanks for a pointer.\n\n[...]\n> = Reject non-fast-forward pulls by default =\n[...]\n> The patches were sent, the issues were addressed, people agreed, and\n> yet nothing happened.\n>\n> [3][4]\n>\n> [...]\n>\n> [3] http://thread.gmane.org/gmane.comp.version-control.git/240030\n> [4] http://thread.gmane.org/gmane.comp.version-control.git/235981\n\nUnfortunately Felipe's summary is incomplete.\n\nMy message was meant as something that could be made into a reference\nfor when similar questions of netiquette come up in the future (as for\nexample they do all the time with Felipe). That meant I didn't give\nas good advice for your particular case than I should have.\n\nFor this particular case, my thoughts are:\n\nIf you believe those patches should be applied, please re-send them\nwith a summary of changes you've made (if any) and your opinion on\nany unaddressed comments from the review thread.\n\nIf you believe those patches should not be applied, wouldn't it be\nbetter to reply to that thread to help in case someone wants to pick\nup the patches and fix them?\n\nOn the other hand if you just want to blow off steam, I guess that's\nfine too. Just don't expect it to result in any patches being\napplied, code quality improving, etc.\n\nJonathan\n"},{"id":"239669","messageId":"535a9f375e196_3984aa530c46@nysa.notmuch","threadId":"36457","inReplyTo":"20140425133520.GC11124@thunk.org","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-25T17:45:27Z","receivedAt":"2014-04-25T17:45:27Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Theodore Ts'o wrote:\n> On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:\n> > \n> > I agree. The \"stage area\" is a very important concept in git, why not\n> > talk git commands that refers to it? Then we could add flags like\n> > --new-files or --deleted-files for better granularity than the current\n> > --all flag.\n> \n> One caution: The term \"stage/staged\" is already a little overloaded.\n> We generally use the word \"staged\" to refer to changes that are in the\n> index, but the term \"stage\" as a noun generally refers to referencing\n> the different versions of a file during a merge operation (cf \"git\n> ls-files --stage\").\n> \n> > I think starting by documenting the issues is a good idea, maybe on a\n> > wiki, and start some draft of a proposed solution that would improve\n> > in an iterative process.\n> \n> And it would be nice if the issues were discussed in a way that acknowledged\n> that all changes have tradeoffs, both positive and negative,\n\nThey have been discussed at length:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/197111\nhttp://thread.gmane.org/gmane.comp.version-control.git/166675\nhttp://thread.gmane.org/gmane.comp.version-control.git/115666\nhttp://thread.gmane.org/gmane.comp.version-control.git/236127\n\nWhen I say literally everbody agreed to move away from the name \"index\" (except\nJunio and another guy) I mean it. I even composed a list:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/233469\n\nJeff King, Jonathan Nieder, Matthieu Moy, they all agreed.\n\n> or for people for whom English might not be the first language.\n\nPeople whom English is not their first language also agreed \"index\" is a\nterrible term.\n\n-- \nFelipe Contreras\n"},{"id":"239670","messageId":"535aa0813e27a_3984aa530c24@nysa.notmuch","threadId":"36457","inReplyTo":"CAGK7Mr74TK4x7WYnmWyRUj_Aga0CHbyFNyZGZdu6eubtwahBXg@mail.gmail.com","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-25T17:50:57Z","receivedAt":"2014-04-25T17:50:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philippe Vaucher wrote:\n> >> Yes, of course there should be a list of both positive and negative\n> >> tradeoffs. But I think the \"overloaded\" argument can be easily solved\n> >> by renaming one of the overloads.\n> >\n> > And renaming one of a term also has costs, especially if it is one\n> > that is in use in large amounts of documentation, both in the git man\n> > pages, and in web pages across the web.\n> \n> It's just impossible to change terms and have previous documentation\n> still be valid. Sure, you can list it in the \"cons\" section as an\n> argument, but it's not very convincing in itself because it applies to\n> pretty much any interface changes. I think the main idea is to\n> _improve_ the interface, which means rename things so it is more\n> consistent and so concepts are easier for new comers to grasp. We\n> could still support old terms for a while and eventually deprecate\n> them.\n\nAnd that's exactly what I did in my patch series: start introducing the --stage\noptions along the current ones.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/236127/focus=236128\n\n-- \nFelipe Contreras\n"},{"id":"239685","messageId":"20140425182459.GA29329@sigill.intra.peff.net","threadId":"36457","inReplyTo":"535a9f375e196_3984aa530c46@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-04-25T18:24:59Z","receivedAt":"2014-04-25T18:24:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:\n\n> When I say literally everbody agreed to move away from the name \"index\" (except\n> Junio and another guy) I mean it. I even composed a list:\n> \n> http://article.gmane.org/gmane.comp.version-control.git/233469\n> \n> Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.\n\nWith reference to my name, your email says:\n\n Jeff King:\n \"staging area\" makes perfect sense\n\nBut here's that statement in context[1]:\n\n So the term \"staging area\" makes perfect sense to me; it is where we\n collect changes to make a commit. I am willing to accept that does not\n to others (native English speakers or no), and that we may need to\n come up with a better term. But I think just calling it \"the stage\" is\n even worse; it loses the concept that it is a place for collecting and\n organizing.\n\nIn other words, I was saying that the term makes sense to me, and\nprimarily comparing favorably to a worse proposal. I am not commenting\nat all on a plan to change names, which is what you are claiming above.\n\nI do think the term \"staging area\" is fine, but picking a term is only\nstep one of a plan. The rest is deciding how to make the change, and\nwhether it is worth it. I remain undecided on the latter bits. Please\ndon't quote me out of context in a way that implies that I am decided.\n\n-Peff\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/168012\n"},{"id":"239689","messageId":"535aa905cd59c_44cee6530ccb@nysa.notmuch","threadId":"36457","inReplyTo":"20140425182459.GA29329@sigill.intra.peff.net","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-25T18:27:17Z","receivedAt":"2014-04-25T18:27:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote:\n> \n> > When I say literally everbody agreed to move away from the name \"index\" (except\n> > Junio and another guy) I mean it. I even composed a list:\n> > \n> > http://article.gmane.org/gmane.comp.version-control.git/233469\n> > \n> > Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed.\n> \n> With reference to my name, your email says:\n> \n> Jeff King:\n> \"staging area\" makes perfect sense\n> \n> But here's that statement in context[1]:\n> \n> So the term \"staging area\" makes perfect sense to me; it is where we\n> collect changes to make a commit. I am willing to accept that does not\n> to others (native English speakers or no), and that we may need to\n> come up with a better term. But I think just calling it \"the stage\" is\n> even worse; it loses the concept that it is a place for collecting and\n> organizing.\n> \n> In other words, I was saying that the term makes sense to me, and\n> primarily comparing favorably to a worse proposal. I am not commenting\n> at all on a plan to change names, which is what you are claiming above.\n> \n> I do think the term \"staging area\" is fine, but picking a term is only\n> step one of a plan. The rest is deciding how to make the change, and\n> whether it is worth it. I remain undecided on the latter bits. Please\n> don't quote me out of context in a way that implies that I am decided.\n\nI specifically said everybody agreed to \"move away from the name 'index'\", I\ndidn't say everybody agreed on the \"staged area\" although the vast majority\ndid, and I didn't say anybody agreed on my patches, although some did.\n\nI think I was clear.\n\n-- \nFelipe Contreras\n"},{"id":"239691","messageId":"20140425185731.GA31454@sigill.intra.peff.net","threadId":"36457","inReplyTo":"535aa905cd59c_44cee6530ccb@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-04-25T18:57:31Z","receivedAt":"2014-04-25T18:57:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:\n\n> I specifically said everybody agreed to \"move away from the name 'index'\", I\n> didn't say everybody agreed on the \"staged area\" although the vast majority\n> did, and I didn't say anybody agreed on my patches, although some did.\n> \n> I think I was clear.\n\nMaybe I was not clear in my response, so let me try again. I do _not_\nnecessarily agree that we need to move away from the name index. I am\nspecifically saying that your \"everyone\" includes my name explicitly,\nand that I do not agree with the statement you are attributing to it.\n\n-Peff\n"},{"id":"239695","messageId":"535ab03711d81_471d7d930822@nysa.notmuch","threadId":"36457","inReplyTo":"20140425185731.GA31454@sigill.intra.peff.net","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-25T18:57:59Z","receivedAt":"2014-04-25T18:57:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote:\n> \n> > I specifically said everybody agreed to \"move away from the name 'index'\", I\n> > didn't say everybody agreed on the \"staged area\" although the vast majority\n> > did, and I didn't say anybody agreed on my patches, although some did.\n> > \n> > I think I was clear.\n> \n> Maybe I was not clear in my response, so let me try again. I do _not_\n> necessarily agree that we need to move away from the name index.\n\nSo you agree that \"the index\" is a bad name, and you agree \"staging area\" is a\nbetter name, yet you don't agree we should move away from the term \"index\"?\n\n-- \nFelipe Contreras\n"},{"id":"239705","messageId":"20140425191236.GA31637@sigill.intra.peff.net","threadId":"36457","inReplyTo":"535ab03711d81_471d7d930822@nysa.notmuch","subject":"Re: What is missing from Git v2.0","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-04-25T19:12:36Z","receivedAt":"2014-04-25T19:12:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:\n\n> > Maybe I was not clear in my response, so let me try again. I do _not_\n> > necessarily agree that we need to move away from the name index.\n> \n> So you agree that \"the index\" is a bad name, and you agree \"staging area\" is a\n> better name, yet you don't agree we should move away from the term \"index\"?\n\nI don't agree that \"the index\" is a \"bad\" name, because that implies\nsome objective level of \"bad\".\n\nI do think the name \"staging area\" is fine, and I think it may even be\nbetter than \"index\", if we were picking a name out of the blue.\n\nI am undecided on whether we should move away from the term \"index\". The\nway you have phrased it seems like you are trying to create a logical\ncontradiction: A is bad, B is good, therefore we should move from A to\nB. But that neglects the cost of moving.\n\nFrankly, I am not that interested in discussing it with you. I _am_\ninterested in you not using my name to claim that I believe things I do\nnot.\n\n-Peff\n"},{"id":"239706","messageId":"535ab7137ac2_48b3d8330866@nysa.notmuch","threadId":"36457","inReplyTo":"20140425191236.GA31637@sigill.intra.peff.net","subject":"Re: What is missing from Git v2.0","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-25T19:27:15Z","receivedAt":"2014-04-25T19:27:15Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote:\n> \n> > > Maybe I was not clear in my response, so let me try again. I do _not_\n> > > necessarily agree that we need to move away from the name index.\n> > \n> > So you agree that \"the index\" is a bad name, and you agree \"staging area\" is a\n> > better name, yet you don't agree we should move away from the term \"index\"?\n> \n> I don't agree that \"the index\" is a \"bad\" name, because that implies\n> some objective level of \"bad\".\n> \n> I do think the name \"staging area\" is fine, and I think it may even be\n> better than \"index\", if we were picking a name out of the blue.\n\n> The way you have phrased it seems like you are trying to create a logical\n> contradiction: A is bad, B is good, therefore we should move from A to B.\n\nA _is_ bad, and B _is_ good. That's what I, and many people, have argued, and\nthat's what the vast majority of people have agreed.\n\n> But that neglects the cost of moving.\n\nAnd you neglect the benefits of moving.\n\nIt is very clear that the costs of moving are negligible in comparison to the\nbenefits.\n\nBut you *always* resist any change, so of course you wouldn't agree on change.\nAnd that's why nothing ever changes.\n\n-- \nFelipe Contreras\n"}]}