{"thread":{"id":"33975","subject":"Re: Highlevel (but simple to implement) commands provided by default for git","startedAt":"2013-05-29T18:05:52Z","lastAt":"2013-06-03T23:22:44Z","messageCount":24,"participants":["Bráulio Bhavamitra","Ramkumar Ramachandra","Junio C Hamano","Felipe Contreras","Jonathan Nieder","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"218867","messageId":"CAJri6_vdN6-z0xvS2PrrdcesStqRKt7ve4dp8S2np3v=_S_ifg@mail.gmail.com","threadId":"33975","inReplyTo":"f611150e-a12a-47f6-97f0-8aaff3045338-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org","subject":"Re: Highlevel (but simple to implement) commands provided by default for git","fromName":"Bráulio Bhavamitra","fromEmail":"brauliobo-re5jqeeqqe8avxtiumwx3w@public.gmane.org","sentAt":"2013-05-29T18:05:52Z","receivedAt":"2013-05-29T18:05:52Z","isPatch":false,"sender":{"key":"brauliobo-re5jqeeqqe8avxtiumwx3w@public.gmane.org","avatar":null},"body":"On Wed, May 29, 2013 at 8:23 AM, Bráulio Bhavamitra wrote:\n\n> Hello all,\n>\n> One of the things I note about git is that is provides mostly low-level\n> and strictly necessary commands.\n> Many highlevel commands are then implemented as alias by users, after a\n> deep search on the internet.\n>\n> Adding highlevel commands, even though it could be implemented by a simple\n> alias, would put git in another level\n> of user experience and create a new standard for newbie users.\n> What git developers think about this?\n>\n> I have, as many other users, an enormous .gitconfig. I paste here some\n> highlevel commands of it, according to my judgement.\n> Mercurial provides many of these highlevel commands.\n>\n> root = rev-parse --show-toplevel\n>\n> upstream = !git for-each-ref --format='%(upstream:short)' $(git symbolic-ref -q HEAD)\n> upstream-remote = !git upstream | sed -e 's/\\\\/.*$//g'\n>\n> out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD\n> in = pull --dry-run\n>\n>\n> unmerged = !git ls-files --unmerged | cut -f2 | uniq\n> untracked = ls-files --other --exclude-standard\n> staged = ls-files --staged\n> modified = ls-files --modified\n> deleted = ls-files --deleted\n>\n>\n> head = !git l -1\n> current = rev-parse --abbrev-ref HEAD\n>\n> Source:\n> https://github.com/brauliobo/gitconfig/blob/master/configs/.gitconfig\n>\n> regards,\n> bráulio\n>\n> --\n> You received this message because you are subscribed to the Google Groups\n> \"Git for human beings\" group.\n> To unsubscribe from this group and stop receiving emails from it, send an\n> email to git-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org\n> For more options, visit https://groups.google.com/groups/opt_out.\n>\n>\n>\n\n-- \nYou received this message because you are subscribed to the Google Groups \"Git for human beings\" group.\nTo unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org\nFor more options, visit https://groups.google.com/groups/opt_out.\n\n\n"},{"id":"218869","messageId":"CAJri6_tm=tk6L1DT=A_BB25jm7b+2Uniw1uSCGtrY5_8X=t_hw@mail.gmail.com","threadId":"33975","inReplyTo":"f611150e-a12a-47f6-97f0-8aaff3045338@googlegroups.com","subject":"Fwd: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Bráulio Bhavamitra","fromEmail":"brauliobo@gmail.com","sentAt":"2013-05-29T18:11:25Z","receivedAt":"2013-05-29T18:11:25Z","isPatch":false,"sender":{"key":"brauliobo@gmail.com","avatar":null},"body":"---------- Forwarded message ----------\nFrom: Bráulio Bhavamitra \nDate: Wed, May 29, 2013 at 8:23 AM\nSubject: [git-users] Highlevel (but simple to implement) commands\nprovided by default for git\nTo: git-users@googlegroups.com\n\n\nHello all,\n\nOne of the things I note about git is that is provides mostly\nlow-level and strictly necessary commands.\nMany highlevel commands are then implemented as alias by users, after\na deep search on the internet.\n\nAdding highlevel commands, even though it could be implemented by a\nsimple alias, would put git in another level\nof user experience and create a new standard for newbie users.\nWhat git developers think about this?\n\nI have, as many other users, an enormous .gitconfig. I paste here some\nhighlevel commands of it, according to my judgement.\nMercurial provides many of these highlevel commands.\n\n root = rev-parse --show-toplevel\n\n upstream = !git for-each-ref --format='%(upstream:short)' $(git\nsymbolic-ref -q HEAD)\n upstream-remote = !git upstream | sed -e 's/\\\\/.*$//g'\n\n out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD\n in = pull --dry-run\n\n\n unmerged = !git ls-files --unmerged | cut -f2 | uniq\n untracked = ls-files --other --exclude-standard\n staged = ls-files --staged\n modified = ls-files --modified\n deleted = ls-files --deleted\n\n\n head = !git l -1\n current = rev-parse --abbrev-ref HEAD\n\nSource: https://github.com/brauliobo/gitconfig/blob/master/configs/.gitconfig\n\nregards,\nbráulio\n\n--\nYou received this message because you are subscribed to the Google\nGroups \"Git for human beings\" group.\nTo unsubscribe from this group and stop receiving emails from it, send\nan email to git-users+unsubscribe@googlegroups.com.\nFor more options, visit https://groups.google.com/groups/opt_out.\n"},{"id":"218872","messageId":"CALkWK0k8GkFYNkoGH4YCgmWtSR5rgFSG0dU9Aw2CO_arvuzKxQ@mail.gmail.com","threadId":"33975","inReplyTo":"CAJri6_tm=tk6L1DT=A_BB25jm7b+2Uniw1uSCGtrY5_8X=t_hw@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-29T18:26:58Z","receivedAt":"2013-05-29T18:26:58Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Bráulio Bhavamitra wrote:\n> root = rev-parse --show-toplevel\n\nWhat is your usecase for this?\n\n> upstream = !git for-each-ref --format='%(upstream:short)' $(git\n> symbolic-ref -q HEAD)\n\nAgain, what is the usecase? What doesn't @{u} do?\n\n> upstream-remote = !git upstream | sed -e 's/\\\\/.*$//g'\n\nWindows back-slashes?\n\n> out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD\n\nI didn't understand this at all. What are you doing?\n\n> in = pull --dry-run\n\nWhy?\n\n> unmerged = !git ls-files --unmerged | cut -f2 | uniq\n> untracked = ls-files --other --exclude-standard\n> staged = ls-files --staged\n> modified = ls-files --modified\n> deleted = ls-files --deleted\n\nWhat is wrong with git status showing a unified output?\n\n> head = !git l -1\n\nWhat is git l again?\n\n> current = rev-parse --abbrev-ref HEAD\n\nWhy don't you use a prompt? Use the one in contrib/completion/git-prompt.sh.\n"},{"id":"218878","messageId":"7vtxllsjeh.fsf@alter.siamese.dyndns.org","threadId":"33975","inReplyTo":"CAJri6_tm=tk6L1DT=A_BB25jm7b+2Uniw1uSCGtrY5_8X=t_hw@mail.gmail.com","subject":"Re: Fwd: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-29T18:58:14Z","receivedAt":"2013-05-29T18:58:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bráulio Bhavamitra writes:\n\n> root = rev-parse --show-toplevel\n\nHmm, part of my \"cdup\" shell function looks something like\n\n cdup () {\n\t... error detection etc...\n\td=$(git rev-parse --show-toplevel)\n cd \"$d\"\n }\n\nso I can quickly go up to the top-level. With \"root\", I could\nreplace that rev-parse call with \"git root\", but I'd keep typing\n\n\t$ cdup\n\nafter doing so anyway. I am not sure how much value it adds.\n\nYou would need to handle error cases like \"you are not in a working\ntree\", you cannot expect to be able to say\n\n\t$ cd \"$(git root)\"\n\nanyway.\n"},{"id":"218888","messageId":"CAMP44s0Cx-FCZLOFZxcpC86sY+H03HKBi0nKFMgit=B5XCy71g@mail.gmail.com","threadId":"33975","inReplyTo":"CAJri6_tm=tk6L1DT=A_BB25jm7b+2Uniw1uSCGtrY5_8X=t_hw@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-29T19:39:37Z","receivedAt":"2013-05-29T19:39:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 29, 2013 at 1:11 PM, Bráulio Bhavamitra wrote:\n> ---------- Forwarded message ----------\n> From: Bráulio Bhavamitra \n> Date: Wed, May 29, 2013 at 8:23 AM\n> Subject: [git-users] Highlevel (but simple to implement) commands\n> provided by default for git\n> To: git-users@googlegroups.com\n\n> One of the things I note about git is that is provides mostly\n> low-level and strictly necessary commands.\n> Many highlevel commands are then implemented as alias by users, after\n> a deep search on the internet.\n>\n> Adding highlevel commands, even though it could be implemented by a\n> simple alias, would put git in another level\n> of user experience and create a new standard for newbie users.\n> What git developers think about this?\n\nCompletely agree.\n\n> root = rev-parse --show-toplevel\n>\n> upstream = !git for-each-ref --format='%(upstream:short)' $(git\n> symbolic-ref -q HEAD)\n\ngit rev-parse --abbrev-ref @{u}\n\n> upstream-remote = !git upstream | sed -e 's/\\\\/.*$//g'\n\ngit config branch.$(git rev-parse --abbrev-ref HEAD).remote\n\n> out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD\n\n'git fetch' without arguments is the same as git fetch `git upstream-remote`\n\nJunio: See? It's not the expected behavior for most of our user-base.\n\n'git log @{u}..HEAD' does the same as 'git log `git upstream`..HEAD'\n\n> unmerged = !git ls-files --unmerged | cut -f2 | uniq\n> untracked = ls-files --other --exclude-standard\n> staged = ls-files --staged\n> modified = ls-files --modified\n> deleted = ls-files --deleted\n\nI think we should have a user-friendly 'git ls' command.\n\n> head = !git l -1\n\nOr 'git show --quiet'.\n\n> current = rev-parse --abbrev-ref HEAD\n\nWe should probably also add typical shortucts:\n\nd = diff\nl = log\nf = fetch\np = push\nr = reset\nci = commit\nrb = rebase\nco = checkout\nst = status\npi = cherry-pick\nmt = mergetool\n\n-- \nFelipe Contreras\n"},{"id":"218889","messageId":"CAMP44s1VFxarV4Gp5KsxhFKJbmd033-DW8koe9P4XUZQcX4mrA@mail.gmail.com","threadId":"33975","inReplyTo":"CALkWK0k8GkFYNkoGH4YCgmWtSR5rgFSG0dU9Aw2CO_arvuzKxQ@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-29T19:50:14Z","receivedAt":"2013-05-29T19:50:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra\n wrote:\n> Bráulio Bhavamitra wrote:\n>> root = rev-parse --show-toplevel\n>\n> What is your usecase for this?\n\nSome Git commands expect to be in the top level directory (e.g. git blame).\n\n>> upstream-remote = !git upstream | sed -e 's/\\\\/.*$//g'\n>\n> Windows back-slashes?\n\nMaybe git config quoting.\n\n>> out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD\n>\n> I didn't understand this at all. What are you doing?\n\nFinding out what changes haven't been pushed out yet?\n\n>> in = pull --dry-run\n>\n> Why?\n\nBecause it's very easy to mess things up with 'git pull'. This\nprobably wouldn't be needed if we change the default of 'git pull' to\nbarf when the changes are not a fast-forward, and print a message\nsuggesting to either merge or rebase, as it has been suggested.\n\n>> unmerged = !git ls-files --unmerged | cut -f2 | uniq\n>> untracked = ls-files --other --exclude-standard\n>> staged = ls-files --staged\n>> modified = ls-files --modified\n>> deleted = ls-files --deleted\n>\n> What is wrong with git status showing a unified output?\n\nIt's not easy to be used in \"scripts\", say, 'gvim -p $(git unmerged)'.\n\n>> head = !git l -1\n>\n> What is git l again?\n\n'git log', of course.\n\n>> current = rev-parse --abbrev-ref HEAD\n>\n> Why don't you use a prompt? Use the one in contrib/completion/git-prompt.sh.\n\nWhile this is probably a good idea, not everybody has a prompt\nconfigured. Imagine ssh'ing to a machine you haven't touched before,\nor shouldn't configure. Sure, right now you need to configure it\nanyway, but the whole proposal is to make these default aliases.\n\nIn Mercurial 'hg branch' shows only the current branch, and I think\nthat's more appropriate.\n\nBefore I configured my prompt, 'git branch' was by far the command I\nused the most.\n\n-- \nFelipe Contreras\n"},{"id":"218893","messageId":"CALkWK0=Sn2myT3QPCWJnoxKH4hm4s7MaB=UrPixP87MFSwKoug@mail.gmail.com","threadId":"33975","inReplyTo":"CAMP44s1VFxarV4Gp5KsxhFKJbmd033-DW8koe9P4XUZQcX4mrA@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-29T20:00:17Z","receivedAt":"2013-05-29T20:00:17Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra\n> wrote:\n>> Bráulio Bhavamitra wrote:\n>>> root = rev-parse --show-toplevel\n>>\n>> What is your usecase for this?\n>\n> Some Git commands expect to be in the top level directory (e.g. git blame).\n\nUm, git blame revert.c when in builtin/ works for me: what am I missing?\n\n>>> out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD\n>>\n>> I didn't understand this at all. What are you doing?\n>\n> Finding out what changes haven't been pushed out yet?\n\n... but why would I want to club a slow network operation with\nsomething like log? Yeah, I use git log @{u}.. all the time.\n\n>>> in = pull --dry-run\n>>\n>> Why?\n>\n> Because it's very easy to mess things up with 'git pull'. This\n> probably wouldn't be needed if we change the default of 'git pull' to\n> barf when the changes are not a fast-forward, and print a message\n> suggesting to either merge or rebase, as it has been suggested.\n\nYeah, I saw that thread and I think shipping \"sane\" defaults is a lost\ncause. I really want to make pull more useable, but by making it more\nconfigurable.\n\n>>> unmerged = !git ls-files --unmerged | cut -f2 | uniq\n>>> untracked = ls-files --other --exclude-standard\n>>> staged = ls-files --staged\n>>> modified = ls-files --modified\n>>> deleted = ls-files --deleted\n>>\n>> What is wrong with git status showing a unified output?\n>\n> It's not easy to be used in \"scripts\", say, 'gvim -p $(git unmerged)'.\n\nRIght, but we shouldn't ship anything \"pretty\" for scripts, otherwise\nit'll become hard to understand them.\n\n>>> head = !git l -1\n>>\n>> What is git l again?\n>\n> 'git log', of course.\n\nI use 'git show' all the time.\n\n>>> current = rev-parse --abbrev-ref HEAD\n>>\n>> Why don't you use a prompt? Use the one in contrib/completion/git-prompt.sh.\n>\n> While this is probably a good idea, not everybody has a prompt\n> configured. Imagine ssh'ing to a machine you haven't touched before,\n> or shouldn't configure. Sure, right now you need to configure it\n> anyway, but the whole proposal is to make these default aliases.\n\nLike I said earlier, I'm really not interested in sane defaults: I\ndon't think all of us can agree on one thing.\n\n> In Mercurial 'hg branch' shows only the current branch, and I think\n> that's more appropriate.\n>\n> Before I configured my prompt, 'git branch' was by far the command I\n> used the most.\n\nYeah, we're fixing 'git branch' (by making it more configurable): the\ntopic is in progress.\n"},{"id":"218895","messageId":"7v38t5sg7k.fsf@alter.siamese.dyndns.org","threadId":"33975","inReplyTo":"CAMP44s1VFxarV4Gp5KsxhFKJbmd033-DW8koe9P4XUZQcX4mrA@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-29T20:07:11Z","receivedAt":"2013-05-29T20:07:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra\n> wrote:\n>> Bráulio Bhavamitra wrote:\n>>> root = rev-parse --show-toplevel\n>>\n>> What is your usecase for this?\n>\n> Some Git commands expect to be in the top level directory (e.g. git blame).\n\n\"Git\" things we can fix [*1*], but more importantly, build structure\nof many project may require you to go up to the top to build the\nwhole thing, so being able to get a relative path to the top when\nyou are deep inside is a necessity.\n\n\n[Footnote]\n\n*1* \"blame\" is an oddball (and I suspect the recent log -Ln,m:path\n may share the same) in that it really wants a concret path, not\n a pathspec, so you cannot even say\n\n\tcd Documentation; git blame :/Makefile\n\n I think the right fix is to teach it that the argument it has\n been taking as a pathname is actually a pathspec, match the\n pathspec with appropriate place (either in the working tree, or\n in the commit we start digging from), and use the path that the\n pathspec matches to a single one (otherwise barf).\n"},{"id":"218896","messageId":"CALkWK0=kA8mPt-8h8dYS9HrOcF1tx=0Pj-=jFHfa_UxdC=ehPQ@mail.gmail.com","threadId":"33975","inReplyTo":"7v38t5sg7k.fsf@alter.siamese.dyndns.org","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-29T20:19:17Z","receivedAt":"2013-05-29T20:19:17Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n>> Some Git commands expect to be in the top level directory (e.g. git blame).\n>\n> \"Git\" things we can fix [*1*], but more importantly, build structure\n> of many project may require you to go up to the top to build the\n> whole thing, so being able to get a relative path to the top when\n> you are deep inside is a necessity.\n\nHow is the project built? When I type `make` inside Documentation/, I\nwant documentation to be built. When I want a toplevel-build, I use a\ncustom git-make function (which does a cd before calling make).\n\n> [Footnote]\n>\n> *1* \"blame\" is an oddball (and I suspect the recent log -Ln,m:path\n> may share the same) in that it really wants a concret path, not\n> a pathspec, so you cannot even say\n>\n> cd Documentation; git blame :/Makefile\n\n*scratches head*\n\n cd Documentation; git blame ../Makefile\n\nIsn't this how pathspecs are specified everywhere?\n\n cd Documentation; git log ../Makefile\n cd Documentation; git log -L0,10:../Makefile\n\nWhat is the difference between \"concrete path\" and \"pathspec\"?\n"},{"id":"218897","messageId":"CALkWK0mBOB1RM+MXH+Nvos29M5vqc2yAtC__zPyowf7imfnz9Q@mail.gmail.com","threadId":"33975","inReplyTo":"CAMP44s0Cx-FCZLOFZxcpC86sY+H03HKBi0nKFMgit=B5XCy71g@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-29T20:27:54Z","receivedAt":"2013-05-29T20:27:54Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> We should probably also add typical shortucts:\n>\n> d = diff\n> l = log\n> f = fetch\n> p = push\n> r = reset\n> ci = commit\n> rb = rebase\n> co = checkout\n> st = status\n> pi = cherry-pick\n> mt = mergetool\n\nTerrible idea. We'll be eating up more subcommands that the user\ncannot override. I'm already unhappy with am not having been called\napply-mailbox, because I want am to mean am -3 -c (too lazy to write\nthose configuration variables).\n"},{"id":"218901","messageId":"7vtxllqyhz.fsf@alter.siamese.dyndns.org","threadId":"33975","inReplyTo":"CALkWK0=kA8mPt-8h8dYS9HrOcF1tx=0Pj-=jFHfa_UxdC=ehPQ@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-29T21:15:04Z","receivedAt":"2013-05-29T21:15:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n>> cd Documentation; git blame :/Makefile\n>\n> *scratches head*\n\nYou lean new things every day ;-).\n\n> cd Documentation; git blame ../Makefile\n>\n> Isn't this how pathspecs are specified everywhere?\n\nThe whole point of show-cdup is that people (especially those in\njava land) bury themselves in a hierarchy so deep that it is not\nfeasible to tell \"Go count the hierarchy and prefix that many ../\nyourself\" to them.\n\nThe answer to \"we cannot count ../\" issue is \":(top)\" aka \":/\" magic\npathspec modifier.\n\n\"git blame\" takes a single pathname, not \"a set of patterns to match\nagainst to select concrete paths\", which is what a pathspec is. \n"},{"id":"218902","messageId":"CALkWK0mZqaUHObNqXKeY7=BCOq-0iHtMvtc_eNANHN8Hw8G-fQ@mail.gmail.com","threadId":"33975","inReplyTo":"7vtxllqyhz.fsf@alter.siamese.dyndns.org","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-29T21:26:20Z","receivedAt":"2013-05-29T21:26:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> The whole point of show-cdup is that people (especially those in\n> java land) bury themselves in a hierarchy so deep that it is not\n> feasible to tell \"Go count the hierarchy and prefix that many ../\n> yourself\" to them.\n\nAh.\n\n> The answer to \"we cannot count ../\" issue is \":(top)\" aka \":/\" magic\n> pathspec modifier.\n\nI thought :/ was a revspec, which is why I was scratching my head so\nhard. Did we introduce this ambiguity intentionally?\n\nThis errors out:\n\n git log :/Makefile\n\nSo, I have to do either of these:\n\n git log :/Makefile --\n git log -- :/Makefile\n\ndepending on what I want.\n\n> \"git blame\" takes a single pathname, not \"a set of patterns to match\n> against to select concrete paths\", which is what a pathspec is.\n\nSo the problem is that I can't do:\n\n git blame -- :/Makefile\n\nSo blame has to be converted to use pathspec semantics, and should\nerror out when the pathspec doesn't match the concrete path of a file.\n"},{"id":"218904","messageId":"CALkWK0=5BwterP7ATM1GgFvLUs391w_MW4YrwbnvsbM6Q4_Opg@mail.gmail.com","threadId":"33975","inReplyTo":"CAJri6_uScqjovt5eK9f9+Z4ehtsdYQNuiEX1MERiDBEJWueAXg@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-29T21:32:39Z","receivedAt":"2013-05-29T21:32:39Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Bráulio Bhavamitra wrote:\n> Agree, these aliased should work as a fallback or as an automatic short\n> version\n\nMaking builtins override'able is also a terrible idea. It opens doors\nto potential bugs we don't want to deal with. Simple example:\n\n am = log -1\n log = am -3\n"},{"id":"218909","messageId":"20130529234335.GE28153@google.com","threadId":"33975","inReplyTo":"CALkWK0=5BwterP7ATM1GgFvLUs391w_MW4YrwbnvsbM6Q4_Opg@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-05-29T23:43:35Z","receivedAt":"2013-05-29T23:43:35Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Bráulio Bhavamitra wrote:\n\n>> Agree, these aliased should work as a fallback or as an automatic short\n>> version\n>\n> Making builtins override'able is also a terrible idea. It opens doors\n> to potential bugs we don't want to deal with. Simple example:\n>\n> am = log -1\n> log = am -3\n\nThat's detectable and could be made to error out, so it's not too bad.\n\nA bigger problem (in my opinion) with allowing arbitrary changes to\nthe meaning of existing commands is that scripts, whether placed in\n.sh files or given as commands to run over IRC, stop working\naltogether. It's nice to have commands like \"git log\" and \"git am\"\nmean the same thing no matter what machine I am on.\n\nHope that helps,\nJonathan\n"},{"id":"218924","messageId":"CAMP44s313TM_5=DGax4PfyiNf_eoWgf8Ls1g5h_uZ6_j3-2b=g@mail.gmail.com","threadId":"33975","inReplyTo":"CALkWK0=Sn2myT3QPCWJnoxKH4hm4s7MaB=UrPixP87MFSwKoug@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-30T02:48:05Z","receivedAt":"2013-05-30T02:48:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 29, 2013 at 3:00 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra\n>> wrote:\n>>> Bráulio Bhavamitra wrote:\n>>>> root = rev-parse --show-toplevel\n>>>\n>>> What is your usecase for this?\n>>\n>> Some Git commands expect to be in the top level directory (e.g. git blame).\n>\n> Um, git blame revert.c when in builtin/ works for me: what am I missing?\n\nI meant 'git bisect', but 'git blame' has a similar issue if it's\nreceiving it's arguments from other git commands.\n\n>>>> out = !git fetch `git upstream-remote` && git l `git upstream`..HEAD\n>>>\n>>> I didn't understand this at all. What are you doing?\n>>\n>> Finding out what changes haven't been pushed out yet?\n>\n> ... but why would I want to club a slow network operation with\n> something like log? Yeah, I use git log @{u}.. all the time.\n\nThen we would be out-of-date all the time.\n\n>>>> in = pull --dry-run\n>>>\n>>> Why?\n>>\n>> Because it's very easy to mess things up with 'git pull'. This\n>> probably wouldn't be needed if we change the default of 'git pull' to\n>> barf when the changes are not a fast-forward, and print a message\n>> suggesting to either merge or rebase, as it has been suggested.\n>\n> Yeah, I saw that thread and I think shipping \"sane\" defaults is a lost\n> cause. I really want to make pull more useable, but by making it more\n> configurable.\n\nSane defaults still make sense, and still will happen, sooner or later.\n\nIn the meantime 'pull --dry-run' makes sense.\n\n>>>> unmerged = !git ls-files --unmerged | cut -f2 | uniq\n>>>> untracked = ls-files --other --exclude-standard\n>>>> staged = ls-files --staged\n>>>> modified = ls-files --modified\n>>>> deleted = ls-files --deleted\n>>>\n>>> What is wrong with git status showing a unified output?\n>>\n>> It's not easy to be used in \"scripts\", say, 'gvim -p $(git unmerged)'.\n>\n> RIght, but we shouldn't ship anything \"pretty\" for scripts, otherwise\n> it'll become hard to understand them.\n\nNot at all. The user is specifically asking for unmerged files, a\nstraight-forward list is easier to understand that a list with a bunch\nof other stuff the user is not interested in, where the user has to\nmanually browse with his eyes until he finds the section he is\ninterested in.\n\nYour argument is akin to saying that 'ls foo' doesn't make sense,\nbecause the user can see 'foo' when he does 'ls'. That defeats the\nwhole notion of letting the user query what he is looking for.\n\n>>>> head = !git l -1\n>>>\n>>> What is git l again?\n>>\n>> 'git log', of course.\n>\n> I use 'git show' all the time.\n\nEven more characters to type.\n\n>>>> current = rev-parse --abbrev-ref HEAD\n>>>\n>>> Why don't you use a prompt? Use the one in contrib/completion/git-prompt.sh.\n>>\n>> While this is probably a good idea, not everybody has a prompt\n>> configured. Imagine ssh'ing to a machine you haven't touched before,\n>> or shouldn't configure. Sure, right now you need to configure it\n>> anyway, but the whole proposal is to make these default aliases.\n>\n> Like I said earlier, I'm really not interested in sane defaults: I\n> don't think all of us can agree on one thing.\n\nThis is not a matter of \"us\" (developers) agreeing, it's a matter of\nthe vast majority of *users* suffering.\n\nIf you are not interested in them, then don't distract us that do.\n\n>> In Mercurial 'hg branch' shows only the current branch, and I think\n>> that's more appropriate.\n>>\n>> Before I configured my prompt, 'git branch' was by far the command I\n>> used the most.\n>\n> Yeah, we're fixing 'git branch' (by making it more configurable): the\n> topic is in progress.\n\nThis is about the default. 'git branch' doesn't do what it should *by\ndefault*, so 'git current' makes sense in the meantime.\n\n-- \nFelipe Contreras\n"},{"id":"218927","messageId":"CAMP44s0YbQLAtmFxhgeY-18U63hF2n8L2LUOxaCnO8Mm7nsONQ@mail.gmail.com","threadId":"33975","inReplyTo":"CALkWK0mBOB1RM+MXH+Nvos29M5vqc2yAtC__zPyowf7imfnz9Q@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-30T03:04:04Z","receivedAt":"2013-05-30T03:04:04Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 29, 2013 at 3:27 PM, Ramkumar Ramachandra\n wrote:\n> Felipe Contreras wrote:\n>> We should probably also add typical shortucts:\n>>\n>> d = diff\n>> l = log\n>> f = fetch\n>> p = push\n>> r = reset\n>> ci = commit\n>> rb = rebase\n>> co = checkout\n>> st = status\n>> pi = cherry-pick\n>> mt = mergetool\n>\n> Terrible idea.\n\nA \"terrible idea\" that somehow each and every other SCM tool in the planet does.\n\nI don't see Mercurial users demanding that they take their useful\nshortcuts away, I see the opposite; they demand useful shortcuts for\nGit.\n\nI say it's a terrible idea **not** to do that.\n\n> We'll be eating up more subcommands that the user\n> cannot override.\n\nWe won't. We can easily implement these as special aliases that the\nmoment the user specifies something else.\n\nBut actually, we don't have to do anything because the current\nimplementation already does that.\n\nIf the user has 'alias.ci=commit -v', and then we specify a default\n'alias.ci=commit', the user's configuration takes precedence.\n\n> I'm already unhappy with am not having been called\n> apply-mailbox, because I want am to mean am -3 -c (too lazy to write\n> those configuration variables).\n\ncat > ~/bin/git-am <> ~/.profile\n\nDone.\n\nAnd I don't see what that has to do with default *aliases* the user\ncan override. This is a red herring.\n\n-- \nFelipe Contreras\n"},{"id":"218928","messageId":"CAMP44s3807Dk0SOZcBbaOKTLj5k36bW0SA9F5ZBY2MwS1Nnxiw@mail.gmail.com","threadId":"33975","inReplyTo":"20130529234335.GE28153@google.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-30T03:08:46Z","receivedAt":"2013-05-30T03:08:46Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>> Bráulio Bhavamitra wrote:\n>\n>>> Agree, these aliased should work as a fallback or as an automatic short\n>>> version\n>>\n>> Making builtins override'able is also a terrible idea. It opens doors\n>> to potential bugs we don't want to deal with. Simple example:\n>>\n>> am = log -1\n>> log = am -3\n>\n> That's detectable and could be made to error out, so it's not too bad.\n>\n> A bigger problem (in my opinion) with allowing arbitrary changes to\n> the meaning of existing commands is that scripts, whether placed in\n> .sh files or given as commands to run over IRC, stop working\n> altogether. It's nice to have commands like \"git log\" and \"git am\"\n> mean the same thing no matter what machine I am on.\n\nExcept that's not true:\n\n% git config --global format.pretty oneline\n\nEither way, this is a red herring, I don't see anybody pushing for\noverriding builtins.\n\n-- \nFelipe Contreras\n"},{"id":"218934","messageId":"20130530052318.GA2923@elie.Belkin","threadId":"33975","inReplyTo":"CAMP44s3807Dk0SOZcBbaOKTLj5k36bW0SA9F5ZBY2MwS1Nnxiw@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-05-30T05:23:18Z","receivedAt":"2013-05-30T05:23:18Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:\n>> Ramkumar Ramachandra wrote:\n\n>>> Making builtins override'able is also a terrible idea. It opens doors\n>>> to potential bugs we don't want to deal with. Simple example:\n>>>\n>>> am = log -1\n>>> log = am -3\n>>\n>> That's detectable and could be made to error out, so it's not too bad.\n>>\n>> A bigger problem (in my opinion) with allowing arbitrary changes to\n>> the meaning of existing commands is that scripts, whether placed in\n>> .sh files or given as commands to run over IRC, stop working\n>> altogether. It's nice to have commands like \"git log\" and \"git am\"\n>> mean the same thing no matter what machine I am on.\n>\n> Except that's not true:\n\nIt's not true that my opinion is that a bigger problem than the\nnon-problem Ram mentioned with allowing arbitrary changes to the\nmeaning of existing commands is that scripts stop working reliably?\n\nThis combative style of communication is toxic. It kills the chance\nof a calm, pleasant discussion, even with patient people who don't\neven fundamentally disagree. Please stop it.\n\nPerhaps you meant \"Commands like 'git log' and 'git am' actually don't\nmean the same thing on all machines. The default format of 'git log'\nis configurable. But that is neither here nor there\", which would\nhave been a pleasant (if irrelevant) response instead of an obnoxious\none.\n\nRegards,\nJonathan\n"},{"id":"218935","messageId":"CAMP44s2ZWA8+ShRDX0uS==THgHPWtoTfXwECFkPXyjSoyXHM=A@mail.gmail.com","threadId":"33975","inReplyTo":"20130530052318.GA2923@elie.Belkin","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-30T05:28:54Z","receivedAt":"2013-05-30T05:28:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:\n\n>>> A bigger problem (in my opinion) with allowing arbitrary changes to\n>>> the meaning of existing commands is that scripts, whether placed in\n>>> .sh files or given as commands to run over IRC, stop working\n>>> altogether. It's nice to have commands like \"git log\" and \"git am\"\n>>> mean the same thing no matter what machine I am on.\n>>\n>> Except that's not true:\n>\n> It's not true that my opinion is that a bigger problem than the\n> non-problem Ram mentioned with allowing arbitrary changes to the\n> meaning of existing commands is that scripts stop working reliably?\n\nIt's not true what you said:\n\ncommands like \"git log\" and \"git am\" mean the same thing no matter\nwhat machine I am on.\n\n> This combative style of communication is toxic. It kills the chance\n> of a calm, pleasant discussion, even with patient people who don't\n> even fundamentally disagree. Please stop it.\n\nStop assuming bad faith[1].\n\n[1] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith\n\n-- \nFelipe Contreras\n"},{"id":"218952","messageId":"CALkWK0mU1XhsjNaQdvOC=Lq5ELgMKnL7ykH8wt8o6coST48Y6Q@mail.gmail.com","threadId":"33975","inReplyTo":"20130529234335.GE28153@google.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-30T07:30:02Z","receivedAt":"2013-05-30T07:30:02Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> That's detectable and could be made to error out, so it's not too bad.\n\nSure it's possible, but I'm arguing about whether it's worth the\neffort. There can be loops like a -> b -> c -> d -> e -> a. Given\nthat nobody has even bothered to get git to print an error message\nwhen a builtin command is overridden, do you think anyone will be\ninterested in this?\n\n> A bigger problem (in my opinion) with allowing arbitrary changes to\n> the meaning of existing commands is that scripts, whether placed in\n> .sh files or given as commands to run over IRC, stop working\n> altogether. It's nice to have commands like \"git log\" and \"git am\"\n> mean the same thing no matter what machine I am on.\n\nYeah, I agree with this to a large extent. It's nice to have a\nminimal set of unambiguous commands for the purposes of communicating,\nand I'm quite happy with the present state of things.\n"},{"id":"219015","messageId":"20130530145447.GC4884@elie.Belkin","threadId":"33975","inReplyTo":"CAMP44s2ZWA8+ShRDX0uS==THgHPWtoTfXwECFkPXyjSoyXHM=A@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-05-30T14:54:47Z","receivedAt":"2013-05-30T14:54:47Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n> On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote:\n>> Felipe Contreras wrote:\n>>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:\n\n>>>> A bigger problem (in my opinion) with allowing arbitrary changes to\n>>>> the meaning of existing commands is that scripts, whether placed in\n>>>> .sh files or given as commands to run over IRC, stop working\n>>>> altogether. It's nice to have commands like \"git log\" and \"git am\"\n>>>> mean the same thing no matter what machine I am on.\n>>>\n>>> Except that's not true:\n>>\n>> It's not true that my opinion is that a bigger problem than the\n>> non-problem Ram mentioned with allowing arbitrary changes to the\n>> meaning of existing commands is that scripts stop working reliably?\n>\n> It's not true what you said:\n>\n> commands like \"git log\" and \"git am\" mean the same thing no matter\n> what machine I am on.\n\nIt's not true that it's nice when they do?\n\n>> This combative style of communication is toxic. It kills the chance\n>> of a calm, pleasant discussion, even with patient people who don't\n>> even fundamentally disagree. Please stop it.\n>\n> Stop assuming bad faith[1].\n\nPerhaps you mean \"I'm trying, but I'm human --- please bear with me\nwhile I work on improving. Know that my intentions are good.\"\n\nUnfortunately, good intentions are not enough. Communicating in a way\nthat clearly conveys what you mean instead of something else that\nderails the conversation is a real skill and, as I said, it's an\nimportant one that is basic to being able to have a productive\nconversation. If you are working on it and are not there yet, my best\nadvice would be to lurk more and speak less, to learn from the example\nof others, and to start by working on how to receive criticism and to\nclear up misunderstandings, which can at least mitigate the damage\nwhen things go wrong.\n\nYou have accused others of assuming bad faith in the past, which only\nescalates things. It's not a good way to move forward. It's possible\nthat the best way to move forward involves some way (e.g., mail client\nconfiguration that holds messages in \"drafts\" for a little while\nbefore sending them out) of being able to cool down when discussions\nget hot.\n\nSincerely,\nJonathan\n"},{"id":"219022","messageId":"CAMP44s2G3NVUyVViF2NP0TEEuGLp-3z+xf-uhsjC-Np80WA-tA@mail.gmail.com","threadId":"33975","inReplyTo":"20130530145447.GC4884@elie.Belkin","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-30T15:32:48Z","receivedAt":"2013-05-30T15:32:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 30, 2013 at 9:54 AM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>> On Thu, May 30, 2013 at 12:23 AM, Jonathan Nieder wrote:\n>>> Felipe Contreras wrote:\n>>>> On Wed, May 29, 2013 at 6:43 PM, Jonathan Nieder wrote:\n>\n>>>>> A bigger problem (in my opinion) with allowing arbitrary changes to\n>>>>> the meaning of existing commands is that scripts, whether placed in\n>>>>> .sh files or given as commands to run over IRC, stop working\n>>>>> altogether. It's nice to have commands like \"git log\" and \"git am\"\n>>>>> mean the same thing no matter what machine I am on.\n>>>>\n>>>> Except that's not true:\n>>>\n>>> It's not true that my opinion is that a bigger problem than the\n>>> non-problem Ram mentioned with allowing arbitrary changes to the\n>>> meaning of existing commands is that scripts stop working reliably?\n>>\n>> It's not true what you said:\n>>\n>> commands like \"git log\" and \"git am\" mean the same thing no matter\n>> what machine I am on.\n>\n> It's not true that it's nice when they do?\n\nYeah, it's nice that the sun is purple. Never-mind the fact that it's not true.\n\nThe consistency you experience across machines has absolutely nothing\nto do with Git, since Git can be configured in a way you don't\nconsider nice.\n\nSo this argument is invalid. Any proposed change to make Git more\nconfigurable is not affected by this argument, because Git can\n*already* be configured in a way that would break your experience, yet\nit doesn't happen.\n\nIn other words; it's the policy or your machine users you have to\nthank for, not Git's code, and changing Git's code is not going to\nchange that policy.\n\nEither way this is a straw man, again, nobody is pushing to allow\nbuiltins to be overridable.\n\nThe topic is default *aliases*.\n\n-- \nFelipe Contreras\n"},{"id":"219183","messageId":"7vobbonwuy.fsf@alter.siamese.dyndns.org","threadId":"33975","inReplyTo":"CALkWK0mZqaUHObNqXKeY7=BCOq-0iHtMvtc_eNANHN8Hw8G-fQ@mail.gmail.com","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-02T19:20:05Z","receivedAt":"2013-06-02T19:20:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> So the problem is that I can't do:\n>\n> git blame -- :/Makefile\n>\n> So blame has to be converted to use pathspec semantics, and should\n> error out when the pathspec doesn't match the concrete path of a file.\n\nCorrect, that is what I wrote in two messages ago in the footnote\nyou were responding to.\n"},{"id":"219316","messageId":"CACsJy8AbhCSSrFnLiS-Gz4GrDiEuK9PM=CGv7fq0pa6Mm6LgRw@mail.gmail.com","threadId":"33975","inReplyTo":"7v38t5sg7k.fsf@alter.siamese.dyndns.org","subject":"Re: [git-users] Highlevel (but simple to implement) commands provided by default for git","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-06-03T23:22:44Z","receivedAt":"2013-06-03T23:22:44Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 30, 2013 at 3:07 AM, Junio C Hamano wrote:\n> *1* \"blame\" is an oddball (and I suspect the recent log -Ln,m:path\n> may share the same) in that it really wants a concret path, not\n> a pathspec, so you cannot even say\n>\n> cd Documentation; git blame :/Makefile\n>\n> I think the right fix is to teach it that the argument it has\n> been taking as a pathname is actually a pathspec, match the\n> pathspec with appropriate place (either in the working tree, or\n> in the commit we start digging from), and use the path that the\n> pathspec matches to a single one (otherwise barf).\n\nYou should have CCed me when it's about pathspec :) At least we can\nsafely turn on :/ trick for git-blame and reject other features (like\nglobbing) that blame can't handle. I'll look into how easy/hard to\nmake git-blame support pathspec.\n--\nDuy\n"}]}