{"thread":{"id":"34991","subject":"[PATCH v3] build: add default aliases","startedAt":"2013-09-21T19:20:21Z","lastAt":"2013-10-17T21:34:01Z","messageCount":34,"participants":["Felipe Contreras","Jeff King","John Szakmeister","SZEDER Gábor","Jonathan Nieder","Matthieu Moy","Michael Haggerty","Duy Nguyen","Junio C Hamano"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"228012","messageId":"1379791221-29925-1-git-send-email-felipe.contreras@gmail.com","threadId":"34991","inReplyTo":null,"subject":"[PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-21T19:20:21Z","receivedAt":"2013-09-21T19:20:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"For now simply add a few common aliases.\n\n  co = checkout\n  ci = commit\n  rb = rebase\n  st = status\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n\nI still think we should ship a default /etc/gitconfig, but the project needs to\nagree it's a good change, and nobody every agrees changes are good. So this is\nthe minimal change that achieves the desired result.\n\n Documentation/git-checkout.txt |  5 +++++\n Documentation/git-commit.txt   |  5 +++++\n Documentation/git-rebase.txt   |  5 +++++\n Documentation/git-status.txt   |  5 +++++\n alias.c                        | 17 +++++++++++++++++\n 5 files changed, 37 insertions(+)\n\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex ca118ac..7597813 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -14,6 +14,11 @@ SYNOPSIS\n 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...\n 'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]\n \n+ALIAS\n+-----\n+\n+git co\n+\n DESCRIPTION\n -----------\n Updates files in the working tree to match the version in the index\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 1a7616c..8705abc 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -15,6 +15,11 @@ SYNOPSIS\n \t   [--date=<date>] [--cleanup=<mode>] [--[no-]status]\n \t   [-i | -o] [-S[<keyid>]] [--] [<file>...]\n \n+ALIAS\n+-----\n+\n+git ci\n+\n DESCRIPTION\n -----------\n Stores the current contents of the index in a new commit along\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 6b2e1c8..bb18fea 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -14,6 +14,11 @@ SYNOPSIS\n \t--root [<branch>]\n 'git rebase' --continue | --skip | --abort | --edit-todo\n \n+ALIAS\n+-----\n+\n+git rb\n+\n DESCRIPTION\n -----------\n If <branch> is specified, 'git rebase' will perform an automatic\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex 9046df9..30ecd25 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -11,6 +11,11 @@ SYNOPSIS\n [verse]\n 'git status' [<options>...] [--] [<pathspec>...]\n \n+ALIAS\n+-----\n+\n+git st\n+\n DESCRIPTION\n -----------\n Displays paths that have differences between the index file and the\ndiff --git a/alias.c b/alias.c\nindex eb9f08b..d6bad69 100644\n--- a/alias.c\n+++ b/alias.c\n@@ -14,11 +14,28 @@ static int alias_lookup_cb(const char *k, const char *v, void *cb)\n \treturn 0;\n }\n \n+static struct {\n+\tconst char *key;\n+\tconst char *val;\n+} default_aliases[] = {\n+\t{ \"co\", \"checkout\" },\n+\t{ \"ci\", \"checkout\" },\n+\t{ \"rb\", \"rebase\" },\n+\t{ \"st\", \"status\" },\n+};\n+\n char *alias_lookup(const char *alias)\n {\n+\tint i;\n \talias_key = alias;\n \talias_val = NULL;\n \tgit_config(alias_lookup_cb, NULL);\n+\tif (alias_val)\n+\t\treturn alias_val;\n+\tfor (i = 0; i < ARRAY_SIZE(default_aliases); i++) {\n+\t\tif (!strcmp(alias, default_aliases[i].key))\n+\t\t\treturn xstrdup(default_aliases[i].val);\n+\t}\n \treturn alias_val;\n }\n \n-- \n1.8.4-fc\n"},{"id":"228118","messageId":"20130924045325.GD2766@sigill.intra.peff.net","threadId":"34991","inReplyTo":"1379791221-29925-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-24T04:53:25Z","receivedAt":"2013-09-24T04:53:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n\n> For now simply add a few common aliases.\n> \n>   co = checkout\n>   ci = commit\n>   rb = rebase\n>   st = status\n\nAre these the best definitions of those shortcuts? It seems[1] that some\npeople define \"ci\" as \"commit -a\", and some people define \"st\" as\n\"status -s\" or even \"status -sb\".\n\nYou are making things more consistent for people who already define\nthose aliases in the same way (they are available everywhere, even if\nthey have not moved their config to a new installation), but less so for\npeople who define them differently. Rather than get an obvious:\n\n  git: 'co' is not a git command. See 'git --help'.\n\nthe result will be subtly different (especially so in the case of\n\"commit\" versus \"commit -a\").\n\n-Peff\n\n[1] https://github.com/search?q=%22ci+%3D+commit+-a%22+path%3A.gitconfig&type=Code\n\n    https://github.com/search?q=%22st+%3D+status+-s%22&type=Code\n\n    https://github.com/search?q=%22st+%3D+status+-sb%22&type=Code\n"},{"id":"228125","messageId":"CAMP44s1tirA5w91L2YomaduZVkqL3=n1j79eoueB6XeGuyY3Mw@mail.gmail.com","threadId":"34991","inReplyTo":"20130924045325.GD2766@sigill.intra.peff.net","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-24T05:32:46Z","receivedAt":"2013-09-24T05:32:46Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Sep 23, 2013 at 11:53 PM, Jeff King <peff@peff.net> wrote:\n> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n>\n>> For now simply add a few common aliases.\n>>\n>>   co = checkout\n>>   ci = commit\n>>   rb = rebase\n>>   st = status\n>\n> Are these the best definitions of those shortcuts? It seems[1] that some\n> people define \"ci\" as \"commit -a\", and some people define \"st\" as\n> \"status -s\" or even \"status -sb\".\n>\n> You are making things more consistent for people who already define\n> those aliases in the same way (they are available everywhere, even if\n> they have not moved their config to a new installation), but less so for\n> people who define them differently. Rather than get an obvious:\n>\n>   git: 'co' is not a git command. See 'git --help'.\n>\n> the result will be subtly different (especially so in the case of\n> \"commit\" versus \"commit -a\").\n\nBefore:\n\n# machine A: git ci\ngit: 'ca' is not a git command. See 'git --help'.\n\n# machine B: git ci\ncommits\n\nAfter:\n\n# machine A: git ci\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n# machine B: git ci\ncommits\n\nThe \"after\" part is much more consistent, at least several commands\nhave a higher chance of doing what the user actually wants, at worst\nthey would do something close to what the user wants.\n\n-- \nFelipe Contreras\n"},{"id":"228127","messageId":"20130924053712.GA6114@sigill.intra.peff.net","threadId":"34991","inReplyTo":"CAMP44s1tirA5w91L2YomaduZVkqL3=n1j79eoueB6XeGuyY3Mw@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-24T05:37:12Z","receivedAt":"2013-09-24T05:37:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote:\n\n> > You are making things more consistent for people who already define\n> > those aliases in the same way (they are available everywhere, even if\n> > they have not moved their config to a new installation), but less so for\n> > people who define them differently. Rather than get an obvious:\n> >\n> >   git: 'co' is not a git command. See 'git --help'.\n> >\n> > the result will be subtly different (especially so in the case of\n> > \"commit\" versus \"commit -a\").\n> \n> Before:\n> \n> # machine A: git ci\n> git: 'ca' is not a git command. See 'git --help'.\n> \n> # machine B: git ci\n> commits\n> \n> After:\n> \n> # machine A: git ci\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> \n> # machine B: git ci\n> commits\n\nThat is the output if there are no files to commit. What about while\nresolving a merge, or after using \"git add\" on a path? In that case we\ncreate a commit, but it is subtly different than what the user intended.\n\nI think for the merge case, it is probably OK, as the \"surprise\" should\nalways go in the safe direction (user expects \"commit -a\", gets\n\"commit\", and commit balks). But the other omits intended files from the\ncommit.\n\n-Peff\n"},{"id":"228130","messageId":"CAMP44s1-AXKRz4pqQsyCMLZgnxmxTaoeBGt8aNDFM0ttDTmBRQ@mail.gmail.com","threadId":"34991","inReplyTo":"20130924053712.GA6114@sigill.intra.peff.net","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-24T05:49:21Z","receivedAt":"2013-09-24T05:49:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 24, 2013 at 12:37 AM, Jeff King <peff@peff.net> wrote:\n> On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote:\n>\n>> > You are making things more consistent for people who already define\n>> > those aliases in the same way (they are available everywhere, even if\n>> > they have not moved their config to a new installation), but less so for\n>> > people who define them differently. Rather than get an obvious:\n>> >\n>> >   git: 'co' is not a git command. See 'git --help'.\n>> >\n>> > the result will be subtly different (especially so in the case of\n>> > \"commit\" versus \"commit -a\").\n>>\n>> Before:\n>>\n>> # machine A: git ci\n>> git: 'ca' is not a git command. See 'git --help'.\n>>\n>> # machine B: git ci\n>> commits\n>>\n>> After:\n>>\n>> # machine A: git ci\n>> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>>\n>> # machine B: git ci\n>> commits\n>\n> That is the output if there are no files to commit. What about while\n> resolving a merge, or after using \"git add\" on a path? In that case we\n> create a commit, but it is subtly different than what the user intended.\n\nIt might be different, but it might not.\n\nAnyway, if you are so worried about this hypothetical user not\nnoticing that 'git ci' didn't commit all the files, we could ma ci to\n'git commit -v' so we are being straightforward to the user as to what\nis being committed.\n\n-- \nFelipe Contreras\n"},{"id":"228134","messageId":"20130924061830.GB6114@sigill.intra.peff.net","threadId":"34991","inReplyTo":"CAMP44s1-AXKRz4pqQsyCMLZgnxmxTaoeBGt8aNDFM0ttDTmBRQ@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-24T06:18:30Z","receivedAt":"2013-09-24T06:18:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote:\n\n> Anyway, if you are so worried about this hypothetical user not\n> noticing that 'git ci' didn't commit all the files, we could ma ci to\n> 'git commit -v' so we are being straightforward to the user as to what\n> is being committed.\n\nI do not think that is a useful suggestion, as the output of \"commit -v\"\nis typically too long for unsuspecting people to check carefully, and is\nredundant with the filename summary we already put in the commit\ntemplate. And neither is shown with \"-m\", anyway.  I agree it's a\nminority of cases where somebody will make a bogus commit because of it,\nthough.\n\nBut let's take a step back for a moment. What was the goal of the patch?\nWho are we trying to help? People who already have identical aliases are\nnot helped on existing boxes; they already have them. They might be\nhelped on new boxes, where they will not have to copy over their custom\naliases (but they would probably end up wanting to copy the rest of\ntheir config and aliases anyway).  People who have different aliases for\nthe same terms are unaffected on existing boxes, but slightly hindered\non new boxes as the aliases do something else.\n\nPeople with no matching aliases now get these aliases. What do they\nexpect them to do? Do they expect \"commit\" or \"commit -a\"? Do they\nexpect \"status\" or \"status -s\" or \"status -sb\"? Are we trying for\nconsistency across git installations, or consistency with similar\naliases in systems like cvs (in which case, would that argue for \"commit\n-a\")? Do people who have not bothered to configure the aliases even\ncare?\n\nMy original question was: are these the best definitions of those\nshortcuts? I have not seen any answer to that.\n\n-Peff\n"},{"id":"228136","messageId":"CAMP44s3ee_SmY=NOeMW31D4E01-Ft9qY5wa9VhRQWrY0fo7S=A@mail.gmail.com","threadId":"34991","inReplyTo":"20130924061830.GB6114@sigill.intra.peff.net","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-24T06:41:19Z","receivedAt":"2013-09-24T06:41:19Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 24, 2013 at 1:18 AM, Jeff King <peff@peff.net> wrote:\n> On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote:\n>\n>> Anyway, if you are so worried about this hypothetical user not\n>> noticing that 'git ci' didn't commit all the files, we could ma ci to\n>> 'git commit -v' so we are being straightforward to the user as to what\n>> is being committed.\n>\n> I do not think that is a useful suggestion, as the output of \"commit -v\"\n> is typically too long for unsuspecting people to check carefully, and is\n> redundant with the filename summary we already put in the commit\n> template. And neither is shown with \"-m\", anyway.  I agree it's a\n> minority of cases where somebody will make a bogus commit because of it,\n> though.\n>\n> But let's take a step back for a moment. What was the goal of the patch?\n> Who are we trying to help? People who already have identical aliases are\n> not helped on existing boxes; they already have them. They might be\n> helped on new boxes, where they will not have to copy over their custom\n> aliases (but they would probably end up wanting to copy the rest of\n> their config and aliases anyway).\n\nThey probably will want that, but they won't be forced to by typing\nfailing commands, they could do it later at their pleasure.\n\n> People who have different aliases for\n> the same terms are unaffected on existing boxes, but slightly hindered\n> on new boxes as the aliases do something else.\n\nLess hindered than in the current situation.\n\n> People with no matching aliases now get these aliases. What do they\n> expect them to do? Do they expect \"commit\" or \"commit -a\"? Do they\n> expect \"status\" or \"status -s\" or \"status -sb\"? Are we trying for\n> consistency across git installations, or consistency with similar\n> aliases in systems like cvs (in which case, would that argue for \"commit\n> -a\")? Do people who have not bothered to configure the aliases even\n> care?\n\ncvs ci = cvs commit\ncvs co = cvs checkout\n\nsvn ci = svn commit\nsvn co = svn checkout\n\nhg ci = hg commit\nhg co = hg checkout\n\nAnd somehow you think this is not natural and sensible?\n\ngit ci = git commit\ngit co = git checkout\n\nI think it's as clear as day.\n\n-- \nFelipe Contreras\n"},{"id":"228137","messageId":"20130924064604.GA7257@sigill.intra.peff.net","threadId":"34991","inReplyTo":"CAMP44s3ee_SmY=NOeMW31D4E01-Ft9qY5wa9VhRQWrY0fo7S=A@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-24T06:46:04Z","receivedAt":"2013-09-24T06:46:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 24, 2013 at 01:41:19AM -0500, Felipe Contreras wrote:\n\n> > People who have different aliases for\n> > the same terms are unaffected on existing boxes, but slightly hindered\n> > on new boxes as the aliases do something else.\n> \n> Less hindered than in the current situation.\n\nI do not agree, but I've already explained my reasoning.  I think we\nmust agree to disagree on this.\n\n> cvs ci = cvs commit\n> cvs co = cvs checkout\n> \n> svn ci = svn commit\n> svn co = svn checkout\n> \n> hg ci = hg commit\n> hg co = hg checkout\n> \n> And somehow you think this is not natural and sensible?\n> \n> git ci = git commit\n> git co = git checkout\n> \n> I think it's as clear as day.\n\nIf it is natural, sensible, and as clear as day, then why do people\nalias the commands to something besides what you show?\n\n-Peff\n"},{"id":"228140","messageId":"CAMP44s0RPgVOo4qN-Nb2Mqkemk53gi_pu7Ft25e3gtFciNOEgw@mail.gmail.com","threadId":"34991","inReplyTo":"20130924064604.GA7257@sigill.intra.peff.net","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-24T06:59:21Z","receivedAt":"2013-09-24T06:59:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 24, 2013 at 1:46 AM, Jeff King <peff@peff.net> wrote:\n> On Tue, Sep 24, 2013 at 01:41:19AM -0500, Felipe Contreras wrote:\n>\n>> > People who have different aliases for\n>> > the same terms are unaffected on existing boxes, but slightly hindered\n>> > on new boxes as the aliases do something else.\n>>\n>> Less hindered than in the current situation.\n>\n> I do not agree, but I've already explained my reasoning.  I think we\n> must agree to disagree on this.\n>\n>> cvs ci = cvs commit\n>> cvs co = cvs checkout\n>>\n>> svn ci = svn commit\n>> svn co = svn checkout\n>>\n>> hg ci = hg commit\n>> hg co = hg checkout\n>>\n>> And somehow you think this is not natural and sensible?\n>>\n>> git ci = git commit\n>> git co = git checkout\n>>\n>> I think it's as clear as day.\n>\n> If it is natural, sensible, and as clear as day, then why do people\n> alias the commands to something besides what you show?\n\nFor the same reason people would do alias.commit='commit -a' if it was possible.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/147517\n\n-- \nFelipe Contreras\n"},{"id":"228148","messageId":"CAEBDL5WQLx4rsN+yRs62fgTBWkuAhCSWDRkoCc8M_akpSqMKvg@mail.gmail.com","threadId":"34991","inReplyTo":"1379791221-29925-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-24T09:19:08Z","receivedAt":"2013-09-24T09:19:08Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> For now simply add a few common aliases.\n>\n>   co = checkout\n>   ci = commit\n>   rb = rebase\n>   st = status\n>\n> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> ---\n>\n> I still think we should ship a default /etc/gitconfig, but the project needs to\n> agree it's a good change, and nobody every agrees changes are good. So this is\n> the minimal change that achieves the desired result.\n\nI wish you would stop attacking the project every time you send a\npatch--it's simply not productive and it's certainly not getting you\nany closer to a resolution.\n\nThat said, I think the idea of having some default aliases is good,\nand these match what several other version control systems have\nalready.\n\nFWIW, I alias st to \"status -sb\", but I'm not convinced it's a good\ndefault.  I think the safe thing to do is to just alias it to\nstatus--like you did here--and let folks override it, if they want\nsomething more.\n\n-John\n"},{"id":"228159","messageId":"CAMP44s3nQv97B2=mq-mn8S41sMA43qRfr+nC7eQ=Jft=zRgTRw@mail.gmail.com","threadId":"34991","inReplyTo":"CAEBDL5WQLx4rsN+yRs62fgTBWkuAhCSWDRkoCc8M_akpSqMKvg@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-24T10:25:06Z","receivedAt":"2013-09-24T10:25:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister <john@szakmeister.net> wrote:\n> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n>> For now simply add a few common aliases.\n>>\n>>   co = checkout\n>>   ci = commit\n>>   rb = rebase\n>>   st = status\n>>\n>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n>> ---\n>>\n>> I still think we should ship a default /etc/gitconfig, but the project needs to\n>> agree it's a good change, and nobody every agrees changes are good. So this is\n>> the minimal change that achieves the desired result.\n>\n> I wish you would stop attacking the project every time you send a\n> patch--it's simply not productive and it's certainly not getting you\n> any closer to a resolution.\n\nI'm not attacking the project, I'm making an objective claim, and I\ncan back it up with several instances of evidence where 99% of the\nusers would benefit from a change, yet it does not move forward.\n\nIf you don't agree my comment is accurate, that's one thing, but\nlabeling it as an attack is another.\n\nI would admit I was wrong if an /etc/gitconfig is indeed shipped by\ndefault, and agree that the Git project is indeed welcome to change,\nbut that's not going to happen.\n\n-- \nFelipe Contreras\n"},{"id":"228160","messageId":"CAEBDL5V1kyRwtKSM+L_E_XbJRauvdmOLc+g2acbixt0+pd6_ag@mail.gmail.com","threadId":"34991","inReplyTo":"CAMP44s3nQv97B2=mq-mn8S41sMA43qRfr+nC7eQ=Jft=zRgTRw@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-24T11:06:44Z","receivedAt":"2013-09-24T11:06:44Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister <john@szakmeister.net> wrote:\n>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras\n>> <felipe.contreras@gmail.com> wrote:\n>>> For now simply add a few common aliases.\n>>>\n>>>   co = checkout\n>>>   ci = commit\n>>>   rb = rebase\n>>>   st = status\n>>>\n>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n>>> ---\n>>>\n>>> I still think we should ship a default /etc/gitconfig, but the project needs to\n>>> agree it's a good change, and nobody every agrees changes are good. So this is\n>>> the minimal change that achieves the desired result.\n>>\n>> I wish you would stop attacking the project every time you send a\n>> patch--it's simply not productive and it's certainly not getting you\n>> any closer to a resolution.\n>\n> I'm not attacking the project, I'm making an objective claim, and I\n> can back it up with several instances of evidence where 99% of the\n> users would benefit from a change, yet it does not move forward.\n\nThere's nothing objective about \"Nobody every (sic) agrees changes are\ngood\".  If it were true, no changes would get in.\n\nAlso, you don't know that any of those changes would benefit \"99% of\nall users\".  It's a guess or an estimate but it's not based on\nanything concrete.  It might be a good guess--and in this case, I\nthink it is--but it's not a concrete fact.  Don't make it sound like\nit is.\n\n> If you don't agree my comment is accurate, that's one thing, but\n> labeling it as an attack is another.\n\nDon't turn it around.  A number of your patches and emails poke at the\ncommunity of the Git project and you know it.  It's simply not helping\nthe situation.\n\nYour clearly a bright and motivated individual--which makes it all the\nmore frustrating that you don't approach this differently.  I even\nagree with your motivations for Git: I'd like to see less shell and\nperl involved and to see Git run faster on Windows.  But I wish you'd\nstop with the jabs.\n\n> I would admit I was wrong if an /etc/gitconfig is indeed shipped by\n> default, and agree that the Git project is indeed welcome to change,\n> but that's not going to happen.\n\nAnd there it is again.  Predicting the future now?  Objectively and\naccurately?  Please stop.\n\n-John\n"},{"id":"228163","messageId":"CAMP44s2j_ra_Tk_s-tjwwvX=T8y=bKPTaUdOQk1jD8QpUm+-zA@mail.gmail.com","threadId":"34991","inReplyTo":"CAEBDL5V1kyRwtKSM+L_E_XbJRauvdmOLc+g2acbixt0+pd6_ag@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-24T14:35:05Z","receivedAt":"2013-09-24T14:35:05Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister <john@szakmeister.net> wrote:\n> On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n>> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister <john@szakmeister.net> wrote:\n>>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras\n>>> <felipe.contreras@gmail.com> wrote:\n>>>> For now simply add a few common aliases.\n>>>>\n>>>>   co = checkout\n>>>>   ci = commit\n>>>>   rb = rebase\n>>>>   st = status\n>>>>\n>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n>>>> ---\n>>>>\n>>>> I still think we should ship a default /etc/gitconfig, but the project needs to\n>>>> agree it's a good change, and nobody every agrees changes are good. So this is\n>>>> the minimal change that achieves the desired result.\n>>>\n>>> I wish you would stop attacking the project every time you send a\n>>> patch--it's simply not productive and it's certainly not getting you\n>>> any closer to a resolution.\n>>\n>> I'm not attacking the project, I'm making an objective claim, and I\n>> can back it up with several instances of evidence where 99% of the\n>> users would benefit from a change, yet it does not move forward.\n>\n> There's nothing objective about \"Nobody every (sic) agrees changes are\n> good\".  If it were true, no changes would get in.\n\nIt is true, where by \"changes\" I mean \"changes from common user's\npoint of view\", actually, a tiny amount of then do sneak in, so let me\nbe precise: \"Virtually nobody ever agrees important changes from the\ncommon user's point of view are good\".\n\nSo now that I'm being clear, do tell, name one important change in Git\nfrom the user's point of view that happened in the last two years.\n\n> Also, you don't know that any of those changes would benefit \"99% of\n> all users\".  It's a guess or an estimate but it's not based on\n> anything concrete.  It might be a good guess--and in this case, I\n> think it is--but it's not a concrete fact.  Don't make it sound like\n> it is.\n\nSure, it's not a concrete fact, but the actual probability most likely\nfollows a beta distribution with alpha=15 and beta=1. Is that more\nprecise for you?\n\n>> If you don't agree my comment is accurate, that's one thing, but\n>> labeling it as an attack is another.\n>\n> Don't turn it around.  A number of your patches and emails poke at the\n> community of the Git project and you know it.  It's simply not helping\n> the situation.\n\nShow me a patch that \"pokes\" at the community. All my patches have\ntechnical descriptions, and help improve Git.\n\n> Your clearly a bright and motivated individual--which makes it all the\n> more frustrating that you don't approach this differently.  I even\n> agree with your motivations for Git: I'd like to see less shell and\n> perl involved and to see Git run faster on Windows.  But I wish you'd\n> stop with the jabs.\n\nDon't worry, I'll stop the \"jabs\" (which are really objective\nobservations which are not particularly flattering for the project,\nbut true, and serious problems that need to be fixed) as soon when I\nleave the project, which I'll do once it's clear my patches are going\nnowhere without any valid justification, and we are right on track for\nthat.\n\n>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by\n>> default, and agree that the Git project is indeed welcome to change,\n>> but that's not going to happen.\n>\n> And there it is again.  Predicting the future now?  Objectively and\n> accurately?  Please stop.\n\nYes I am. Feel free to go back to this mail and tell me I was wrong\nwhen they do what I said they won't.\n\n-- \nFelipe Contreras\n"},{"id":"228164","messageId":"20130924152140.GA4259@goldbirke","threadId":"34991","inReplyTo":"1379791221-29925-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"SZEDER Gábor","fromEmail":"szeder@fzi.de","sentAt":"2013-09-24T15:21:40Z","receivedAt":"2013-09-24T15:21:40Z","isPatch":true,"sender":{"key":"szeder@fzi.de","avatar":null},"body":"The subject line needs to be updated.\n\nOn Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n> For now simply add a few common aliases.\n> \n>   co = checkout\n>   ci = commit\n>   rb = rebase\n>   st = status\n> \n> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n> ---\n\n[...]\n\n> diff --git a/alias.c b/alias.c\n> index eb9f08b..d6bad69 100644\n> --- a/alias.c\n> +++ b/alias.c\n> @@ -14,11 +14,28 @@ static int alias_lookup_cb(const char *k, const char *v, void *cb)\n>  \treturn 0;\n>  }\n>  \n> +static struct {\n> +\tconst char *key;\n> +\tconst char *val;\n> +} default_aliases[] = {\n> +\t{ \"co\", \"checkout\" },\n> +\t{ \"ci\", \"checkout\" },\n> +\t{ \"rb\", \"rebase\" },\n> +\t{ \"st\", \"status\" },\n> +};\n> +\n>  char *alias_lookup(const char *alias)\n>  {\n> +\tint i;\n>  \talias_key = alias;\n>  \talias_val = NULL;\n>  \tgit_config(alias_lookup_cb, NULL);\n> +\tif (alias_val)\n> +\t\treturn alias_val;\n> +\tfor (i = 0; i < ARRAY_SIZE(default_aliases); i++) {\n> +\t\tif (!strcmp(alias, default_aliases[i].key))\n> +\t\t\treturn xstrdup(default_aliases[i].val);\n> +\t}\n>  \treturn alias_val;\n>  }\n\nAliases implemented this way don't work the same way as \"normal\"\naliases do:\n\n  $ # which aliases do I have?\n  $ ./bin-wrappers/git config --get-regexp \"alias\\..*\"\n  $ # no aliases at all\n  $ # does completion work?\n  $ ./bin-wrappers/git co ma<TAB>\n  mailmap.c      mailmap.h      mailmap.o      match-trees.c  match-trees.o\n  $ # no refs completion\n  $ # let's see a real alias\n  $ git config alias.co checkout\n  $ ./bin-wrappers/git config --get-regexp \"alias\\..*\"\n  alias.co checkout\n  $ ./bin-wrappers/git co ma<TAB>\n  maint    master\n  $ # as expected\n\n\nBest,\nGábor\n"},{"id":"228165","messageId":"1380036793-21901-1-git-send-email-felipe.contreras@gmail.com","threadId":"34991","inReplyTo":"20130924152140.GA4259@goldbirke","subject":"[PATCH v4] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-24T15:33:13Z","receivedAt":"2013-09-24T15:33:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"For now simply add a few common aliases.\n\n  co = checkout\n  ci = commit\n  rb = rebase\n  st = status\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n Documentation/git-checkout.txt | 5 +++++\n Documentation/git-commit.txt   | 5 +++++\n Documentation/git-rebase.txt   | 5 +++++\n Documentation/git-status.txt   | 5 +++++\n config.c                       | 5 +++++\n 5 files changed, 25 insertions(+)\n\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex ca118ac..7597813 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -14,6 +14,11 @@ SYNOPSIS\n 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...\n 'git checkout' [-p|--patch] [<tree-ish>] [--] [<paths>...]\n \n+ALIAS\n+-----\n+\n+git co\n+\n DESCRIPTION\n -----------\n Updates files in the working tree to match the version in the index\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 1a7616c..8705abc 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -15,6 +15,11 @@ SYNOPSIS\n \t   [--date=<date>] [--cleanup=<mode>] [--[no-]status]\n \t   [-i | -o] [-S[<keyid>]] [--] [<file>...]\n \n+ALIAS\n+-----\n+\n+git ci\n+\n DESCRIPTION\n -----------\n Stores the current contents of the index in a new commit along\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 6b2e1c8..bb18fea 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -14,6 +14,11 @@ SYNOPSIS\n \t--root [<branch>]\n 'git rebase' --continue | --skip | --abort | --edit-todo\n \n+ALIAS\n+-----\n+\n+git rb\n+\n DESCRIPTION\n -----------\n If <branch> is specified, 'git rebase' will perform an automatic\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex 9046df9..30ecd25 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -11,6 +11,11 @@ SYNOPSIS\n [verse]\n 'git status' [<options>...] [--] [<pathspec>...]\n \n+ALIAS\n+-----\n+\n+git st\n+\n DESCRIPTION\n -----------\n Displays paths that have differences between the index file and the\ndiff --git a/config.c b/config.c\nindex e13a7b6..be724b2 100644\n--- a/config.c\n+++ b/config.c\n@@ -1082,6 +1082,11 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)\n \n \thome_config_paths(&user_config, &xdg_config, \"config\");\n \n+\tret += fn(\"alias.ci\", \"commit\", data);\n+\tret += fn(\"alias.co\", \"checkout\", data);\n+\tret += fn(\"alias.rb\", \"rebase\", data);\n+\tret += fn(\"alias.st\", \"status\", data);\n+\n \tif (git_config_system() && !access_or_die(git_etc_gitconfig(), R_OK, 0)) {\n \t\tret += git_config_from_file(fn, git_etc_gitconfig(),\n \t\t\t\t\t    data);\n-- \n1.8.4-fc\n"},{"id":"228167","messageId":"20130924183958.GK9464@google.com","threadId":"34991","inReplyTo":"20130924045325.GD2766@sigill.intra.peff.net","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-09-24T18:39:58Z","receivedAt":"2013-09-24T18:39:58Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n\n>> For now simply add a few common aliases.\n>>\n>>   co = checkout\n>>   ci = commit\n>>   rb = rebase\n>>   st = status\n>\n> Are these the best definitions of those shortcuts? It seems[1] that some\n> people define \"ci\" as \"commit -a\", and some people define \"st\" as\n> \"status -s\" or even \"status -sb\".\n\nI feel bad about having waited for 4 rounds of this patch to say this,\nbut the basic change (providing \"co\", \"ci\", etc. as aliases by\ndefault) does not look well thought through.\n\nIt would be a different story if this were a patch to update\ndocumentation to suggest adding such aliases at the same time as\ntelling Git what your name is.  The user manual doesn't explain how to\nset up aliases at all yet, and that should be fixed.\n\nBut making 'ci' a synonym of another command by default while still\nkeeping its definition configurable would be doing people a\ndisservice, I fear.  As long as 'ci' works out of the box, it will\nstart showing up in examples and used in suggestions over IRC, etc,\nwhich is great.  Unfortunately that means that anyone who has 'ci'\ndefined to mean something different can no longer use those examples,\nthat advice from IRC, and so on.  So in the world where 'ci' is a\nsynonym for 'commit' by default, while people still *can* redefine\n'ci' to include whatever options they like (e.g., \"-a\"), actually\ncarrying out such a personal customization is asking for trouble.\n\nIncidentally, that is also the reason git already doesn't allow\naliases to override built-in commands such as \"git commit\", even\nthough it would be convenient to some to not have to remember to add\n\"-a\" each time.  As consolation we have been able to say \"But you can\ntake the even shorter-and-sweeter 'git ci' and make it mean whatever\nyou want\".  Now we should take that avenue away for people?\n\nBad idea.\n\nHope that helps,\nJonathan\n"},{"id":"228170","messageId":"CAEBDL5Xa2C_zXdaE+Db9Rh7o_xyF6gC-72_Nxb0u5_o4ACjuFw@mail.gmail.com","threadId":"34991","inReplyTo":"20130924183958.GK9464@google.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-24T19:30:12Z","receivedAt":"2013-09-24T19:30:12Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Sep 24, 2013 at 2:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Jeff King wrote:\n>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n>\n>>> For now simply add a few common aliases.\n>>>\n>>>   co = checkout\n>>>   ci = commit\n>>>   rb = rebase\n>>>   st = status\n>>\n>> Are these the best definitions of those shortcuts? It seems[1] that some\n>> people define \"ci\" as \"commit -a\", and some people define \"st\" as\n>> \"status -s\" or even \"status -sb\".\n>\n> I feel bad about having waited for 4 rounds of this patch to say this,\n> but the basic change (providing \"co\", \"ci\", etc. as aliases by\n> default) does not look well thought through.\n>\n> It would be a different story if this were a patch to update\n> documentation to suggest adding such aliases at the same time as\n> telling Git what your name is.  The user manual doesn't explain how to\n> set up aliases at all yet, and that should be fixed.\n\nYes, better documentation around aliases would be a good idea.\n\n> But making 'ci' a synonym of another command by default while still\n> keeping its definition configurable would be doing people a\n> disservice, I fear.  As long as 'ci' works out of the box, it will\n> start showing up in examples and used in suggestions over IRC, etc,\n> which is great.  Unfortunately that means that anyone who has 'ci'\n> defined to mean something different can no longer use those examples,\n> that advice from IRC, and so on.  So in the world where 'ci' is a\n> synonym for 'commit' by default, while people still *can* redefine\n> 'ci' to include whatever options they like (e.g., \"-a\"), actually\n> carrying out such a personal customization is asking for trouble.\n\nI'm not sure I agree.  Yes, if someone has configured their shortcut\ndifferently, they may not be able to use the example exactly.  OTOH,\nshells have aliases, and while there are sometimes problems, I think\nmost people overcome them.  I don't see the situation being very\ndifferent here.\n\nFWIW, I'm not overly convinced one way or another.  What I can say is,\nin the circles I run in, I can only think of one person has gone\nwithout setting up aliases to commit (ci), status (st), and checkout\n(co).  The full names are simply to long for day-to-day usage.\n\n-John\n"},{"id":"228204","messageId":"CAEBDL5X1QRLaTvxhEu4e5_NE5fEWc6fd60YJyA8wye4d4T3wpQ@mail.gmail.com","threadId":"34991","inReplyTo":"CAMP44s2j_ra_Tk_s-tjwwvX=T8y=bKPTaUdOQk1jD8QpUm+-zA@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-09-25T13:33:59Z","receivedAt":"2013-09-25T13:33:59Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister <john@szakmeister.net> wrote:\n[snip]\n>> There's nothing objective about \"Nobody every (sic) agrees changes are\n>> good\".  If it were true, no changes would get in.\n>\n> It is true, where by \"changes\" I mean \"changes from common user's\n> point of view\", actually, a tiny amount of then do sneak in, so let me\n> be precise: \"Virtually nobody ever agrees important changes from the\n> common user's point of view are good\".\n>\n> So now that I'm being clear, do tell, name one important change in Git\n> from the user's point of view that happened in the last two years.\n\nCredential helpers.\n\n>> Also, you don't know that any of those changes would benefit \"99% of\n>> all users\".  It's a guess or an estimate but it's not based on\n>> anything concrete.  It might be a good guess--and in this case, I\n>> think it is--but it's not a concrete fact.  Don't make it sound like\n>> it is.\n>\n> Sure, it's not a concrete fact, but the actual probability most likely\n> follows a beta distribution with alpha=15 and beta=1. Is that more\n> precise for you?\n\nIt's not about precision, it's that you don't have any actual facts to\nstand on but you speak like you do.  Then when someone questions it,\nyou accuse them of being against fixes for the user.  I wish you'd\nstop it and do something more constructive to help move things along.\n\n>>> If you don't agree my comment is accurate, that's one thing, but\n>>> labeling it as an attack is another.\n>>\n>> Don't turn it around.  A number of your patches and emails poke at the\n>> community of the Git project and you know it.  It's simply not helping\n>> the situation.\n>\n> Show me a patch that \"pokes\" at the community. All my patches have\n> technical descriptions, and help improve Git.\n\nYou're filtering what I said again.  Take a look at the first message\nis this thread.\n\nI'll agree the patches themselves have been free of this, but the\ncover letters--which I consider to be part of the patch--and ensuing\nconversation has not.  If you need another example, look at the cover\nletter for your transport helper patches.\n\nNone of this is news to you.\n\n[snip]\n>>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by\n>>> default, and agree that the Git project is indeed welcome to change,\n>>> but that's not going to happen.\n>>\n>> And there it is again.  Predicting the future now?  Objectively and\n>> accurately?  Please stop.\n>\n> Yes I am. Feel free to go back to this mail and tell me I was wrong\n> when they do what I said they won't.\n\nI have no need for that, and I'm done talking to you about any of this.\n\n-John\n"},{"id":"228207","messageId":"CAMP44s2EtgXXdfa+QtUmmRh6wZ1fD8YTWtzLJ2mN6y_6faMM_g@mail.gmail.com","threadId":"34991","inReplyTo":"CAEBDL5X1QRLaTvxhEu4e5_NE5fEWc6fd60YJyA8wye4d4T3wpQ@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-25T14:29:03Z","receivedAt":"2013-09-25T14:29:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"n\n\nOn Wed, Sep 25, 2013 at 8:33 AM, John Szakmeister <john@szakmeister.net> wrote:\n> On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n>> On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister <john@szakmeister.net> wrote:\n> [snip]\n>>> There's nothing objective about \"Nobody every (sic) agrees changes are\n>>> good\".  If it were true, no changes would get in.\n>>\n>> It is true, where by \"changes\" I mean \"changes from common user's\n>> point of view\", actually, a tiny amount of then do sneak in, so let me\n>> be precise: \"Virtually nobody ever agrees important changes from the\n>> common user's point of view are good\".\n>>\n>> So now that I'm being clear, do tell, name one important change in Git\n>> from the user's point of view that happened in the last two years.\n>\n> Credential helpers.\n\nThat's not a change, that's a new feature, and it could hardly be\ncalled important.\n\nBy change I mean something that was one way before, and it's a\ndifferent way now.\n\nBut let me help you; you can't mention one, because there isn't any.\n\n>>> Also, you don't know that any of those changes would benefit \"99% of\n>>> all users\".  It's a guess or an estimate but it's not based on\n>>> anything concrete.  It might be a good guess--and in this case, I\n>>> think it is--but it's not a concrete fact.  Don't make it sound like\n>>> it is.\n>>\n>> Sure, it's not a concrete fact, but the actual probability most likely\n>> follows a beta distribution with alpha=15 and beta=1. Is that more\n>> precise for you?\n>\n> It's not about precision, it's that you don't have any actual facts to\n> stand on but you speak like you do.  Then when someone questions it,\n> you accuse them of being against fixes for the user.  I wish you'd\n> stop it and do something more constructive to help move things along.\n\nI have as many facts as you or anybody does.\n\nIf I cannot use the claim that 99% (or any overwhelming number) of\nusers would benefit, then nobody can make the claim that X amount of\nusers would be affected negatively, because the actual number can be\nclose to or equal to 0. But one claim is more likely than the other.\n\nAs for doing something more constructive to help move things along,\nwhat you don't get is that there is nothing to do to move things\nalong. I send the patches, the patches are good, the patches should be\napplied. That's what any decently run project would do, concentrate on\nthe technical side.\n\nDo you think if I hold hands with the people involved and we all sing\nKumbaya things would move along? Well it shouldn't, if the patches are\ngood the patches are good. What should move things along is the\ntechnical merits of the patch.\n\n>>>> If you don't agree my comment is accurate, that's one thing, but\n>>>> labeling it as an attack is another.\n>>>\n>>> Don't turn it around.  A number of your patches and emails poke at the\n>>> community of the Git project and you know it.  It's simply not helping\n>>> the situation.\n>>\n>> Show me a patch that \"pokes\" at the community. All my patches have\n>> technical descriptions, and help improve Git.\n>\n> You're filtering what I said again.  Take a look at the first message\n> is this thread.\n>\n> I'll agree the patches themselves have been free of this, but the\n> cover letters--which I consider to be part of the patch--and ensuing\n> conversation has not.  If you need another example, look at the cover\n> letter for your transport helper patches.\n\nI don't consider the cover letter part of the patch. And the\nconversation is irrelevant, all the users care about is the code.\n\nNot introducing a good feature for users because a developer said a\nnasty word (which I haven't) in the cover letter of the patch series\nis ridiculous.\n\n>>>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by\n>>>> default, and agree that the Git project is indeed welcome to change,\n>>>> but that's not going to happen.\n>>>\n>>> And there it is again.  Predicting the future now?  Objectively and\n>>> accurately?  Please stop.\n>>\n>> Yes I am. Feel free to go back to this mail and tell me I was wrong\n>> when they do what I said they won't.\n>\n> I have no need for that, and I'm done talking to you about any of this.\n\nDoesn't matter, because it's not going to happen.\n\n-- \nFelipe Contreras\n"},{"id":"228209","messageId":"vpqr4cdt0gk.fsf@anie.imag.fr","threadId":"34991","inReplyTo":"CAMP44s2EtgXXdfa+QtUmmRh6wZ1fD8YTWtzLJ2mN6y_6faMM_g@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-25T14:55:39Z","receivedAt":"2013-09-25T14:55:39Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> But let me help you; you can't mention one, because there isn't any.\n\nOr because you didn't really look. Read the release notes of every Git\nrelease these days, there's a big section about ongoing backward\nincompatible changes.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"228210","messageId":"CAMP44s3qv==GZt7BYMc-FuQvVoNGf3kkGAGzk=-=F4A8KZojKQ@mail.gmail.com","threadId":"34991","inReplyTo":"vpqr4cdt0gk.fsf@anie.imag.fr","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-25T15:08:33Z","receivedAt":"2013-09-25T15:08:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> But let me help you; you can't mention one, because there isn't any.\n>\n> Or because you didn't really look. Read the release notes of every Git\n> release these days, there's a big section about ongoing backward\n> incompatible changes.\n\nI said *important* changes from the common user's point of view.\n\n-- \nFelipe Contreras\n"},{"id":"228212","messageId":"vpqk3i5szng.fsf@anie.imag.fr","threadId":"34991","inReplyTo":"CAMP44s3qv==GZt7BYMc-FuQvVoNGf3kkGAGzk=-=F4A8KZojKQ@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-25T15:13:07Z","receivedAt":"2013-09-25T15:13:07Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy\n> <Matthieu.Moy@grenoble-inp.fr> wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>> But let me help you; you can't mention one, because there isn't any.\n>>\n>> Or because you didn't really look. Read the release notes of every Git\n>> release these days, there's a big section about ongoing backward\n>> incompatible changes.\n>\n> I said *important* changes from the common user's point of view.\n\nCall me fool, but I do consider the default behavior of \"git push\" as\nsomething important, indeed.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"228213","messageId":"CAMP44s05ggre-ZcURLyTyYsFG1_f=gVDW-dj2LsNK8_tGTqyyg@mail.gmail.com","threadId":"34991","inReplyTo":"vpqk3i5szng.fsf@anie.imag.fr","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-25T15:16:53Z","receivedAt":"2013-09-25T15:16:53Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 25, 2013 at 10:13 AM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy\n>> <Matthieu.Moy@grenoble-inp.fr> wrote:\n>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>>\n>>>> But let me help you; you can't mention one, because there isn't any.\n>>>\n>>> Or because you didn't really look. Read the release notes of every Git\n>>> release these days, there's a big section about ongoing backward\n>>> incompatible changes.\n>>\n>> I said *important* changes from the common user's point of view.\n>\n> Call me fool, but I do consider the default behavior of \"git push\" as\n> something important, indeed.\n\nLast time I checked nothing has changed, the default remains\npush.default=matching.\n\n-- \nFelipe Contreras\n"},{"id":"228217","messageId":"vpqy56ksx8y.fsf@anie.imag.fr","threadId":"34991","inReplyTo":"CAMP44s05ggre-ZcURLyTyYsFG1_f=gVDW-dj2LsNK8_tGTqyyg@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-09-25T16:05:01Z","receivedAt":"2013-09-25T16:05:01Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Last time I checked nothing has changed, the default remains\n> push.default=matching.\n\nLOL.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"228219","messageId":"CAMP44s3AtmJ7juRvfk4+StBqskv0tvukaLv9wMD0ymGVinOXGw@mail.gmail.com","threadId":"34991","inReplyTo":"vpqy56ksx8y.fsf@anie.imag.fr","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-25T16:36:34Z","receivedAt":"2013-09-25T16:36:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 25, 2013 at 11:05 AM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> Last time I checked nothing has changed, the default remains\n>> push.default=matching.\n>\n> LOL.\n\nI'd take that as an admission that you don't have any examples of\nimportant changes in the past two years, at least.\n\n-- \nFelipe Contreras\n"},{"id":"228422","messageId":"CAMP44s0UcP5AhWrm7vjBDLvY6CupzL03kys1YXs9cpGJNxkBBA@mail.gmail.com","threadId":"34991","inReplyTo":"20130924183958.GK9464@google.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-28T22:41:41Z","receivedAt":"2013-09-28T22:41:41Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Jeff King wrote:\n>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n>\n>>> For now simply add a few common aliases.\n>>>\n>>>   co = checkout\n>>>   ci = commit\n>>>   rb = rebase\n>>>   st = status\n>>\n>> Are these the best definitions of those shortcuts? It seems[1] that some\n>> people define \"ci\" as \"commit -a\", and some people define \"st\" as\n>> \"status -s\" or even \"status -sb\".\n>\n> I feel bad about having waited for 4 rounds of this patch to say this,\n> but the basic change (providing \"co\", \"ci\", etc. as aliases by\n> default) does not look well thought through.\n\nTo you.\n\n> It would be a different story if this were a patch to update\n> documentation to suggest adding such aliases at the same time as\n> telling Git what your name is.  The user manual doesn't explain how to\n> set up aliases at all yet, and that should be fixed.\n\nThat's a completely different subject.\n\n> But making 'ci' a synonym of another command by default while still\n> keeping its definition configurable would be doing people a\n> disservice, I fear.\n\nAnd I and many (most) users disagree.\n\n> As long as 'ci' works out of the box, it will\n> start showing up in examples and used in suggestions over IRC, etc,\n> which is great.\n\nIt might, or...\n\n> Unfortunately that means that anyone who has 'ci'\n> defined to mean something different can no longer use those examples,\n> that advice from IRC, and so on.  So in the world where 'ci' is a\n> synonym for 'commit' by default, while people still *can* redefine\n> 'ci' to include whatever options they like (e.g., \"-a\"), actually\n> carrying out such a personal customization is asking for trouble.\n\nPrecisely for this reason it might not. If people know aliases can be\ndifferent in different machines, they would avoid them in\ndocumentation which is meant for all machines.\n\nIf you truly want to be pedantic, you could add a warning if the\ndefault alias is not used, and this warning gets silenced if the user\nconfigures the alias manually.\n\n> Incidentally, that is also the reason git already doesn't allow\n> aliases to override built-in commands such as \"git commit\", even\n> though it would be convenient to some to not have to remember to add\n> \"-a\" each time.  As consolation we have been able to say \"But you can\n> take the even shorter-and-sweeter 'git ci' and make it mean whatever\n> you want\".  Now we should take that avenue away for people?\n\nWho is taking away that avenue? Certainly not this patch.\n\n> Bad idea.\n\nOnly if you assume your hypothesis is a fact, which is not, and even\nif you do, it's still not.\n\n> Hope that helps,\n\nThe project? No, it doesn't. Virtually every VCS out there has default aliases,\nand Git somehow cannot manage to get them done.\n\nAnd BTW, look what I can do in mercurial:\n\n.hgrc\n---\n[alias]\nstatus = status --all\n---\n\nOMG! The world is going to end! No, it's not, it's no problem. What you think\nis so clearly a bad idea, seems to be doing just fine in Mercurial.\n\n-- \nFelipe Contreras\n"},{"id":"228432","messageId":"52479C04.8060000@alum.mit.edu","threadId":"34991","inReplyTo":"CAMP44s0UcP5AhWrm7vjBDLvY6CupzL03kys1YXs9cpGJNxkBBA@mail.gmail.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2013-09-29T03:18:28Z","receivedAt":"2013-09-29T03:18:28Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 09/29/2013 12:41 AM, Felipe Contreras wrote:\n> On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n>>>> For now simply add a few common aliases.\n>>>>\n>>>>   co = checkout\n>>>>   ci = commit\n>>>>   rb = rebase\n>>>>   st = status\n>>>\n>>> [...]\n> \n>> But making 'ci' a synonym of another command by default while still\n>> keeping its definition configurable would be doing people a\n>> disservice, I fear.\n> \n> And I and many (most) users disagree.\n> \n>> As long as 'ci' works out of the box, it will\n>> start showing up in examples and used in suggestions over IRC, etc,\n>> which is great.\n\n...and in scripts.\n\n> It might, or...\n> \n>> Unfortunately that means that anyone who has 'ci'\n>> defined to mean something different can no longer use those examples,\n>> that advice from IRC, and so on.  So in the world where 'ci' is a\n>> synonym for 'commit' by default, while people still *can* redefine\n>> 'ci' to include whatever options they like (e.g., \"-a\"), actually\n>> carrying out such a personal customization is asking for trouble.\n> \n> Precisely for this reason it might not. If people know aliases can be\n> different in different machines, they would avoid them in\n> documentation which is meant for all machines.\n\nMy experience contradicts your prediction.  I have 'ci'/'co' aliases in\nmy own configuration.  But even though I am aware of the fact that other\npeople might not have the same aliases, I have on multiple occasions\nused them in documentation and/or scripts meant for other people.  The\nmuscle memory is just too strong.\n\nMy error was discovered by other people who didn't have those aliases.\nIf *most* people had the same aliases as I did, and others had defined\ntheir own slightly different ones, then the scripts would have subtly\nmalfunctioned for the latter set of users and I would have had trouble\nreproducing the errors.\n\nThat being said, independent of aliases, there are many other config\nsettings that can affect commands that might be used in documentation or\nscripts, and which also could be the source of errors for the non-vigilent.\n\nSo, even though I think such aliases are a great convenience factor, I\nam -0 on including pre-defined but overrideable aliases and -1 on\nincluding pre-defined and non-overrideable aliases.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"228433","messageId":"CAMP44s12c2_nEkwzgWXYzaJTeymSyLbDMWoRygMwZv8-m8wG4g@mail.gmail.com","threadId":"34991","inReplyTo":"52479C04.8060000@alum.mit.edu","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-29T03:37:05Z","receivedAt":"2013-09-29T03:37:05Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Sep 28, 2013 at 10:18 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 09/29/2013 12:41 AM, Felipe Contreras wrote:\n>> On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>>>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:\n>>>>> For now simply add a few common aliases.\n>>>>>\n>>>>>   co = checkout\n>>>>>   ci = commit\n>>>>>   rb = rebase\n>>>>>   st = status\n>>>>\n>>>> [...]\n>>\n>>> But making 'ci' a synonym of another command by default while still\n>>> keeping its definition configurable would be doing people a\n>>> disservice, I fear.\n>>\n>> And I and many (most) users disagree.\n>>\n>>> As long as 'ci' works out of the box, it will\n>>> start showing up in examples and used in suggestions over IRC, etc,\n>>> which is great.\n>\n> ...and in scripts.\n>\n>> It might, or...\n>>\n>>> Unfortunately that means that anyone who has 'ci'\n>>> defined to mean something different can no longer use those examples,\n>>> that advice from IRC, and so on.  So in the world where 'ci' is a\n>>> synonym for 'commit' by default, while people still *can* redefine\n>>> 'ci' to include whatever options they like (e.g., \"-a\"), actually\n>>> carrying out such a personal customization is asking for trouble.\n>>\n>> Precisely for this reason it might not. If people know aliases can be\n>> different in different machines, they would avoid them in\n>> documentation which is meant for all machines.\n>\n> My experience contradicts your prediction.  I have 'ci'/'co' aliases in\n> my own configuration.  But even though I am aware of the fact that other\n> people might not have the same aliases, I have on multiple occasions\n> used them in documentation and/or scripts meant for other people.  The\n> muscle memory is just too strong.\n\nIf you are already making that error, then this patch wouldn't make it\nany worst. In fact, it would make the situation better.\n\nIf previously you had 10 persons complaining about the \"ci\" command\nnot working, now 9 of them wouldn't complain because \"git ci\" does\nactually work, even if you have aliased it to something slightly\ndifferent, like \"commit -v\". Instead, you would have 1 person\ncomplaining, because he has a different alias, which makes the command\nfail somehow. In reality, that 1 person might not even exist.\n\nThe solution before and after my patch is the same; avoid the 'ci'/'co' aliases.\n\n> My error was discovered by other people who didn't have those aliases.\n\nAnd after this patch it still will.\n\n> If *most* people had the same aliases as I did, and others had defined\n> their own slightly different ones, then the scripts would have subtly\n> malfunctioned for the latter set of users and I would have had trouble\n> reproducing the errors.\n\nDoubtful. But a warning that a default alias is being used, or simply\nshowing the actual command in the standard output would fix the\nproblem.\n\nIt certainly looks like you are not even looking for solutions for the\nhypothetical problems you put forward.\n\n> So, even though I think such aliases are a great convenience factor, I\n> am -0 on including pre-defined but overrideable aliases and -1 on\n> including pre-defined and non-overrideable aliases.\n\nAnd still, somehow every other VCS out there manages default aliases\njust fine, and Mercurial even allows overriding commands. How do you\nexplain that the world hasn't ended for them?\n\n-- \nFelipe Contreras\n"},{"id":"228476","messageId":"20130930193343.GW9464@google.com","threadId":"34991","inReplyTo":"52479C04.8060000@alum.mit.edu","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-09-30T19:33:43Z","receivedAt":"2013-09-30T19:33:43Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael Haggerty wrote:\n\n> That being said, independent of aliases, there are many other config\n> settings that can affect commands that might be used in documentation or\n> scripts, and which also could be the source of errors for the non-vigilent.\n\nYep, this is a problem, too (I'm looking at you, \"git push\").  We try\nto avoid this problem or balance it against convenience by being\ncareful when adding new configuration, but sometimes we slip up.\n\nThanks for your thoughtfulness.\n\nSincerely,\nJonathan\n"},{"id":"228490","messageId":"CACsJy8De8uER-=N4DonycE9i0cOG-mvcx+bRnQ=Gxt4X9_1TfQ@mail.gmail.com","threadId":"34991","inReplyTo":"20130930193343.GW9464@google.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-10-01T01:12:37Z","receivedAt":"2013-10-01T01:12:37Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Oct 1, 2013 at 2:33 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Michael Haggerty wrote:\n>\n>> That being said, independent of aliases, there are many other config\n>> settings that can affect commands that might be used in documentation or\n>> scripts, and which also could be the source of errors for the non-vigilent.\n>\n> Yep, this is a problem, too (I'm looking at you, \"git push\").  We try\n> to avoid this problem or balance it against convenience by being\n> careful when adding new configuration, but sometimes we slip up.\n\nI think the problem is we start pushing too much on the porcelain\nfront and forget about plumbing. \"git push\" is for human, but I don't\nthink there's an equivalent for scripts. \"git branch --list\" vs \"git\nfor-each-ref\" is a good example.\n-- \nDuy\n"},{"id":"229032","messageId":"xmqqy55ub1ud.fsf@gitster.dls.corp.google.com","threadId":"34991","inReplyTo":"20130924045325.GD2766@sigill.intra.peff.net","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-15T22:34:18Z","receivedAt":"2013-10-15T22:34:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> It seems[1] that some\n> people define \"ci\" as \"commit -a\", and some people define \"st\" as\n> \"status -s\" or even \"status -sb\".\n\nThese option variants aside.\n\nJust like thinking that committing must be the same as publishing,\nit is a cvs/svn induced braindamage to think that \"checking in\" must\nbe the same as \"committing\".  The former is a sign of not\nunderstanding the \"distributed\", the latter \"the index\".\n\nIn a world with both check-in and commit as two words usable to\ndenote possibly different concepts, it may make sense to say \"you\ncheck-in the current status of the working tree files into the\nindex, in order to make commits out of it later\".\n"},{"id":"229055","messageId":"525e0b6e25aeb_81a151de7495@nysa.notmuch","threadId":"34991","inReplyTo":"xmqqy55ub1ud.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-16T03:43:42Z","receivedAt":"2013-10-16T03:43:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n> > It seems[1] that some\n> > people define \"ci\" as \"commit -a\", and some people define \"st\" as\n> > \"status -s\" or even \"status -sb\".\n> \n> These option variants aside.\n> \n> Just like thinking that committing must be the same as publishing,\n> it is a cvs/svn induced braindamage to think that \"checking in\" must\n> be the same as \"committing\".  The former is a sign of not\n> understanding the \"distributed\", the latter \"the index\".\n> \n> In a world with both check-in and commit as two words usable to\n> denote possibly different concepts, it may make sense to say \"you\n> check-in the current status of the working tree files into the\n> index, in order to make commits out of it later\".\n\nYet a wide amount of users do use 'ci' to mean 'commit', so basically they are\njust wrong. So you are saying they are just ignorant.\n\nPersonally I don't care if it's 'ci', or 'co', or 'cm', or 'ct'. I just\nwant/need a shortcut, then I can train my fingers to type that.\n\nIf you have a better alias than 'ci', then by all means, throw away your\nsuggestion.\n\nNow, if you are commenting on the aliases, that would mean you are not against\nthe idea of aliaes per se, but more about values of those aliases. So if we\nagreed on the right values, you would welcome this patch.\n\nIs that correct?\n\n-- \nFelipe Contreras\n"},{"id":"229132","messageId":"xmqqppr3znf1.fsf@gitster.dls.corp.google.com","threadId":"34991","inReplyTo":"525e0b6e25aeb_81a151de7495@nysa.notmuch","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-17T19:51:13Z","receivedAt":"2013-10-17T19:51:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> Jeff King <peff@peff.net> writes:\n>> \n>> > It seems[1] that some\n>> > people define \"ci\" as \"commit -a\", and some people define \"st\" as\n>> > \"status -s\" or even \"status -sb\".\n>> \n>> These option variants aside.\n>> \n>> Just like thinking that committing must be the same as publishing,\n>> it is a cvs/svn induced braindamage to think that \"checking in\" must\n>> be the same as \"committing\".  The former is a sign of not\n>> understanding the \"distributed\", the latter \"the index\".\n>> \n>> In a world with both check-in and commit as two words usable to\n>> denote possibly different concepts, it may make sense to say \"you\n>> check-in the current status of the working tree files into the\n>> index, in order to make commits out of it later\".\n>\n> Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are\n> just wrong. So you are saying they are just ignorant.\n\nI am sick of seeing my word twisted, especially when they were not\neven addressed to you (see the message's primary recipients list).\nThose who want to type \"git ci\" due to their familiarity with \"svn\nci\" are not wrong; they can do so if they choose.\n\nLet's try again (see below).\n\n> Now, if you are commenting on the aliases, that would mean you are not against\n> the idea of aliaes per se, but more about values of those aliases. So if we\n> agreed on the right values, you would welcome this patch.\n>\n> Is that correct?\n\nNo.\n\nI agree with the issue the message I was replying to raised. The\nalias mechanism is a way to help users to define their own\nconvenient short-cut. If you want to say \"git ci\" to mean \"git\ncommit\" (and not \"git commit -a\" or something else), define it for\nyour own use, and stop there, without getting in the way of other\npeople. That is why I see an attempt to add hard-coded set of\naliases as a move in the wrong direction.\n\nA set of hard-coded alias that _officially_ declares that \"checkin\"\nis an equivalent to \"commit\" has another issue.  It will close the\ndoor for us to later add \"git checkin\" that may mean something\ndifferent from \"git commit\", and that is another reason why I do not\nagree with the patch under discussion in this thread. A \"checkin\"\nthat is an operation that checks-in the current contents to the\nindex is one example of an action other than committing that the\nword may make sense for, because \"git checkout README.txt\" is about\nchecking out of the index, its logical opposite \"checkin\" could be\nabout checking into the index.\n"},{"id":"229145","messageId":"526057c98609c_448145fe74bb@nysa.notmuch","threadId":"34991","inReplyTo":"xmqqppr3znf1.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v3] build: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-10-17T21:34:01Z","receivedAt":"2013-10-17T21:34:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n> \n> > Junio C Hamano wrote:\n> >> Jeff King <peff@peff.net> writes:\n> >> \n> >> > It seems[1] that some\n> >> > people define \"ci\" as \"commit -a\", and some people define \"st\" as\n> >> > \"status -s\" or even \"status -sb\".\n> >> \n> >> These option variants aside.\n> >> \n> >> Just like thinking that committing must be the same as publishing,\n> >> it is a cvs/svn induced braindamage to think that \"checking in\" must\n> >> be the same as \"committing\".  The former is a sign of not\n> >> understanding the \"distributed\", the latter \"the index\".\n> >> \n> >> In a world with both check-in and commit as two words usable to\n> >> denote possibly different concepts, it may make sense to say \"you\n> >> check-in the current status of the working tree files into the\n> >> index, in order to make commits out of it later\".\n> >\n> > Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are\n> > just wrong. So you are saying they are just ignorant.\n> \n> I am sick of seeing my word twisted, especially when they were not\n> even addressed to you (see the message's primary recipients list).\n\nWhen you send messages to a public mailing list, even if not addressed to that\nmailing list, is with the expectation that other people in that mailing list\nwill reply.\n\nWhen you say something is a sign of not understanding, that means ignorance,\nand there's nothing bad about that, we are all ignorant about many things.\n\n> Those who want to type \"git ci\" due to their familiarity with \"svn\n> ci\" are not wrong; they can do so if they choose.\n\nI never suggested they were wrong, you suggested they were ignorant.\n\nAnd this is being used by you as reason *not* to use ci as an alias for commit\nby default.\n\n> > Now, if you are commenting on the aliases, that would mean you are not against\n> > the idea of aliaes per se, but more about values of those aliases. So if we\n> > agreed on the right values, you would welcome this patch.\n> >\n> > Is that correct?\n> \n> No.\n> \n> I agree with the issue the message I was replying to raised. The\n> alias mechanism is a way to help users to define their own\n> convenient short-cut. If you want to say \"git ci\" to mean \"git\n> commit\" (and not \"git commit -a\" or something else), define it for\n> your own use, and stop there, without getting in the way of other\n> people.\n\nA set of default aliases doesn't get in the way of other people either.\n\nThat's why all VCS tools have them, and none of them have a problem.\n\n> That is why I see an attempt to add hard-coded set of aliases as a move in\n> the wrong direction.\n\nThey are not hard-coded, they are configurable.\n\n> A set of hard-coded alias that _officially_ declares that \"checkin\"\n> is an equivalent to \"commit\" has another issue.\n\nNo. Nobody said anything about check-in, it's ci, which could be CommIt. And\nyou are conveniently ignoring all the other possible aliases for commit.\n\n> It will close the door for us to later add \"git checkin\" that may mean\n> something different from \"git commit\", and that is another reason why I do\n> not agree with the patch under discussion in this thread. A \"checkin\" that is\n> an operation that checks-in the current contents to the index is one example\n> of an action other than committing that the word may make sense for, because\n> \"git checkout README.txt\" is about checking out of the index, its logical\n> opposite \"checkin\" could be about checking into the index.\n\nNobody said anything about a check-in. This is a red herring.\n\nAbsolultely nothing you have said in this second half has anything to do with\nthe question I asked. I asked specifically about the idea of aliases,\nindependently of their actual values, and all you have done is argue against\nthe value of a single alias: ci.\n\n-- \nFelipe Contreras\n"}]}