{"thread":{"id":"49516","subject":"[PATCH 0/2] branch: introduce --current display option","startedAt":"2018-10-09T18:27:28Z","lastAt":"2018-10-10T23:51:17Z","messageCount":9,"participants":["Daniels Umanovskis","Junio C Hamano","Eric Sunshine","Rafael Ascensão","Ævar Arnfjörð Bjarmason","Stefan Beller","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"359932","messageId":"20181009182006.9446-1-daniels@umanovskis.se","threadId":"49516","inReplyTo":null,"subject":"[PATCH 0/2] branch: introduce --current display option","fromName":"Daniels Umanovskis","fromEmail":"daniels@umanovskis.se","sentAt":"2018-10-09T18:20:04Z","receivedAt":"2018-10-09T18:27:28Z","isPatch":true,"sender":{"key":"daniels@umanovskis.se","avatar":"https://avatars.githubusercontent.com/u/5055233?v=4"},"body":"I often find myself needing the current branch name, for which currently there's git rev-parse --abrev-ref HEAD. I would expect `git branch` to have an option to output the branch name instead.\n\nThis is my first patch to Git, so process-related comments (patch formatting, et cetera) are quite welcome.\n\nDaniels Umanovskis (2):\n  branch: introduce --current display option\n  doc/git-branch: Document the --current option\n\n Documentation/git-branch.txt |  6 +++++-\n builtin/branch.c             | 16 ++++++++++++++++\n t/t3203-branch-output.sh     | 18 ++++++++++++++++++\n 3 files changed, 39 insertions(+), 1 deletion(-)\n\n-- \n2.19.1.272.gf84b9b09d.dirty\n\n"},{"id":"359948","messageId":"xmqq8t36q1k6.fsf@gitster-ct.c.googlers.com","threadId":"49516","inReplyTo":"20181009182006.9446-1-daniels@umanovskis.se","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-09T20:59:05Z","receivedAt":"2018-10-09T20:59:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniels Umanovskis <daniels@umanovskis.se> writes:\n\n> I often find myself needing the current branch name, for which\n> currently there's git rev-parse --abrev-ref HEAD. I would expect\n> `git branch` to have an option to output the branch name instead.\n\n[jc:  wrapped an overlong line]\n\nIf \"git branch\" had many operations that work on multiple branches\nby default, and we were adding an option to work on a single branch\nthat is currently checked out, then I would find \"--current\" is a\nvery good name for an option that turns all these operations to work\nonly on the one that is currently checked out.\n\nBut I do not think that is what is going on.  There is \"--list\" that\nlists branches whose name match given patterns, and at the end-user\nlevel (I haven't seen the implementation) this is another mode of\nthat operation that limits itself to the one that is currently\nchecked out, and you do not even allowed to give the \"--list\" option\nexplicitly so that in the future when \"git branch\" learns to perform\nan operation other than \"list\" (let's call it 'distim') to bunch of\nbranches by default, you cannot say \"git --distim --current\" to\nlimit the distimming to the branch that you are currently on.\n\nI do not offhand know if we want \"show the current one only\" option\nthat is \"command mode\" sitting next to \"list\", \"delete\", \"rename\"\netc., or \"limit the operation to the one that is currently cheked\nout\".  If we want the former, the name of the option must *NOT* be\njust \"current\".  Have a verb in its name to avoid it from getting\nmistaken as a botched attempt to do the latter.  Somethng like\n\"--show-current\", \"--list-current\", \"--display-current\", etc.\n\nEven if we were doing the latter (i.e. focused \"this is only for\nlisting/showing\"), if we do not want to close the door to later\nextend the concept of \"current\" to the former (i.e. \"--show-current\"\nbecomes a convenience synonym for \"--list --current-only\") we also\nneed to think about what to do with the detached HEAD state.  When\nthe concept of \"current\" is extended to become \"usually an operation\ncan work on multiple branches but we are limiting it to the current\none\", detached HEAD state is conceptually \"not having any current\nbranch\".  We could fail the operation (i.e. you told me to distim\nthe branch but there is no such branch) or make it a silent no-op\n(i.e. you told me to distim no branch, so nothing happened and there\nis no error).\n\nMy inclination is to recommend to:\n\n (1) name the \"show the current one\" not \"--current\" but with some\n     verb\n\n (2) display nothing when there is no current branch (i.e. detached\n     HEAD) and without any error.\n\n\n\n\n\n"},{"id":"359990","messageId":"CAPig+cTp-cFKX2Kqj-yV7OtgmxDo7Mp7i0TUXU7JGYdgtbHiug@mail.gmail.com","threadId":"49516","inReplyTo":"xmqq8t36q1k6.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-10-10T09:29:09Z","receivedAt":"2018-10-10T09:30:56Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Oct 9, 2018 at 4:59 PM Junio C Hamano <gitster@pobox.com> wrote:\n> My inclination is to recommend to:\n>\n>  (1) name the \"show the current one\" not \"--current\" but with some\n>      verb\n>\n>  (2) display nothing when there is no current branch (i.e. detached\n>      HEAD) and without any error.\n\nSensible suggestions. Also, please documentation any new option(s) in\nDocumentation/git-branch.txt.\n"},{"id":"359991","messageId":"CAPig+cToXS+pT4Kp0uejtRkvJdSmso9a_Q=Odrhox5htzqBvTw@mail.gmail.com","threadId":"49516","inReplyTo":"CAPig+cTp-cFKX2Kqj-yV7OtgmxDo7Mp7i0TUXU7JGYdgtbHiug@mail.gmail.com","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-10-10T09:42:52Z","receivedAt":"2018-10-10T09:43:05Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Oct 10, 2018 at 5:29 AM Eric Sunshine <sunshine@sunshineco.com> wrote:\n> On Tue, Oct 9, 2018 at 4:59 PM Junio C Hamano <gitster@pobox.com> wrote:\n> > My inclination is to recommend to:\n> >\n> >  (1) name the \"show the current one\" not \"--current\" but with some\n> >      verb\n> >\n> >  (2) display nothing when there is no current branch (i.e. detached\n> >      HEAD) and without any error.\n>\n> Sensible suggestions. Also, please documentation any new option(s) in\n> Documentation/git-branch.txt.\n\nSorry, I was expecting to see the documentation update in patch 1 and\ndidn't notice that it was being done by patch 2. The reason I had that\nexpectation is that a change of functionality and the documentation of\nthat change are logically related, thus (usually) ought to be\npresented together. Therefore, when you re-roll, you may want to\nconsider squashing the two patches into one.\n"},{"id":"360028","messageId":"20181010142423.GA3390@rigel","threadId":"49516","inReplyTo":"xmqq8t36q1k6.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"Rafael Ascensão","fromEmail":"rafa.almas@gmail.com","sentAt":"2018-10-10T14:24:34Z","receivedAt":"2018-10-10T14:24:48Z","isPatch":true,"sender":{"key":"rafa.almas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1923789?v=4"},"body":"On Wed, Oct 10, 2018 at 05:59:05AM +0900, Junio C Hamano wrote:\n>\n> But I do not think that is what is going on.  There is \"--list\" that\n> lists branches whose name match given patterns, and at the end-user\n> level (I haven't seen the implementation) this is another mode of\n> that operation that limits itself to the one that is currently\n> checked out\n>\n\nGiven the idea that showing the current branch is a particular case of\nwhat --list does, one option could be to treat the 'HEAD' pattern\nspecially.\n\n[After writing another version of this email, I found that we\nalready special case the pattern 'HEAD']\n\n$git branch; already treats the 'HEAD' pattern specially to print\nsomething like: \"* (HEAD detached at e83c516331)\" when the HEAD is\ndetached. But returns without output when the HEAD is attached.\n\nWe could make $git branch --list HEAD; print the current branch\nparalleling nicely with what $git rev-parse --abrev-ref HEAD; already\ndoes when given attached and detached HEAD; But keeping the perks of the\nmore human-readable output (color, * marker, formatting, etc).\n\nSince the output of git branch isn't meant to be parsable, changing this\nbehaviour shouldn't affect users, and introduce the feature without the\nneed of new options.\n\nBut I suspect this approach may be diverging from the spirit of this\npatch.\n\nFrom my time spent on #git, I find that the concept of 'HEAD' is\nsomething that many new users misunderstand. So, if the original\nmotivation behind this patch is to be able to determine the current\nbranch without using the concept of 'HEAD', my suggestion falls short.\n\nCheers,\nRafael Ascensão\n\n"},{"id":"360032","messageId":"87woqpetd3.fsf@evledraar.gmail.com","threadId":"49516","inReplyTo":"20181009182006.9446-1-daniels@umanovskis.se","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-10-10T15:03:52Z","receivedAt":"2018-10-10T15:03:57Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Oct 09 2018, Daniels Umanovskis wrote:\n\n> I often find myself needing the current branch name, for which\n> currently there's git rev-parse --abrev-ref HEAD. I would expect `git\n> branch` to have an option to output the branch name instead.\n>\n> This is my first patch to Git, so process-related comments (patch\n> formatting, et cetera) are quite welcome.\n\nThanks for your first patch, and sorry to give you this feedback on it\n:)\n\nI'm mildly negative on this because git-rev-parse is plumbing, but\ngit-branch is porcelain, as listed in \"man git\", and it helps to be able\nto clearly say what's a stable API or not.\n\nBut of course I wrote the above paragraph seeing that that's a lie. We\nalso list git-rev-parse as porcelain, just under \"Porcelain / Ancillary\nCommands / Interrogators\".\n\nShould we just move it to plumbing? I don't know.\n\nIn any case, if we're adding such a feature to an existing command it\nshould be prominently noted in the docs that this option and not others\nin git-branch are plumbing-ish, like we do for the (very confusingly\nnamed) --porcelain option to git-status. Users writing scripts need some\nreasonable high-level overview of what they can and can't use for\nscripting purposes if they expect the output to be stable.\n\nAlso, as much as our current scripting interface can be very confusing\n(you might not think \"get current branch\" is under rev-parse), I can't\nhelp but think that adding two different ways to spew out the exact same\nthing to two different commands is heading in the wrong\ndirection. I.e. should we perhaps instead add a new git-ref-info and\nstart slowly moving/recommending to use that for the various ref (but\nnot rev) stuff that git-rev-parse is doing, or maybe add a \"git\nrev-parse --current-branch\" and document that it's just a convenience\nalias for \"git rev-parse --abbrev-ref HEAD\"?\n"},{"id":"360046","messageId":"d6e8a7a4-2de1-7ffe-2848-d372cb550a2d@umanovskis.se","threadId":"49516","inReplyTo":"87woqpetd3.fsf@evledraar.gmail.com","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"Daniels Umanovskis","fromEmail":"daniels@umanovskis.se","sentAt":"2018-10-10T16:29:57Z","receivedAt":"2018-10-10T16:30:08Z","isPatch":true,"sender":{"key":"daniels@umanovskis.se","avatar":"https://avatars.githubusercontent.com/u/5055233?v=4"},"body":"On 10/10/18 5:03 PM, Ævar Arnfjörð Bjarmason wrote:\n> \n> I'm mildly negative on this because git-rev-parse is plumbing, but\n> git-branch is porcelain [..]\n> \n> We also list git-rev-parse as porcelain, just under \"Porcelain / Ancillary\n> Commands / Interrogators\".\n> \n> Should we just move it to plumbing? I don't know.\n\nFrom my perspective as a Git user, not developer, git-rev-parse is\nbetween plumbing and porcelain, but much more plumbing. It's listed as\nporcelain but is connected to the plumbing git-rev-list, and for the\nmost part it does things incomprehensible without understanding Git\ninternals. Then it also has a bunch of options that are very useful in\nscripts but unrelated to revisions, here I mean --git-dir or\n--is-inside-work-tree.\n\nI'd be happy to submit a documentation patch for discussion that\nformally moves rev-parse to plumbing.\n\n> Also, as much as our current scripting interface can be very confusing\n> (you might not think \"get current branch\" is under rev-parse), I can't\n> help but think that adding two different ways to spew out the exact same\n> thing to two different commands is heading in the wrong\n> direction.\n\nAgreed, so I'm very much inclined to move forward with Junio's preferred\nsolution on this, which would also act differently by only outputting\nthe branch when you're really on a branch, and being silent in e.g.\ndetached HEAD.\n"},{"id":"360051","messageId":"CAGZ79kamNFs8hugoEv9M_fk97Bm2jkUywbrCoD4CwsZ=UsFPmg@mail.gmail.com","threadId":"49516","inReplyTo":"d6e8a7a4-2de1-7ffe-2848-d372cb550a2d@umanovskis.se","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-10-10T18:08:40Z","receivedAt":"2018-10-10T18:08:54Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> I'd be happy to submit a documentation patch for discussion that\n> formally moves rev-parse to plumbing.\n\nI'd be happy to see such a patch.\n"},{"id":"360111","messageId":"20181010235108.GW432229@genre.crustytoothpaste.net","threadId":"49516","inReplyTo":"xmqq8t36q1k6.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 0/2] branch: introduce --current display option","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-10-10T23:51:08Z","receivedAt":"2018-10-10T23:51:17Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Wed, Oct 10, 2018 at 05:59:05AM +0900, Junio C Hamano wrote:\n> I do not offhand know if we want \"show the current one only\" option\n> that is \"command mode\" sitting next to \"list\", \"delete\", \"rename\"\n> etc., or \"limit the operation to the one that is currently cheked\n> out\".  If we want the former, the name of the option must *NOT* be\n> just \"current\".  Have a verb in its name to avoid it from getting\n> mistaken as a botched attempt to do the latter.  Somethng like\n> \"--show-current\", \"--list-current\", \"--display-current\", etc.\n\nI had considered sending a patch with this option spelled \"--show\".\nThis is certainly a highly desired feature (hence my intent to send a\npatch), and I think there's room for both a porcelain (this series) and\na plumbing (git rev-parse --abbrev-ref) version.\n\n> Even if we were doing the latter (i.e. focused \"this is only for\n> listing/showing\"), if we do not want to close the door to later\n> extend the concept of \"current\" to the former (i.e. \"--show-current\"\n> becomes a convenience synonym for \"--list --current-only\") we also\n> need to think about what to do with the detached HEAD state.  When\n> the concept of \"current\" is extended to become \"usually an operation\n> can work on multiple branches but we are limiting it to the current\n> one\", detached HEAD state is conceptually \"not having any current\n> branch\".  We could fail the operation (i.e. you told me to distim\n> the branch but there is no such branch) or make it a silent no-op\n> (i.e. you told me to distim no branch, so nothing happened and there\n> is no error).\n\nWhat I would suggest is the same thing git status shows: \"HEAD (detached\nat...)\".  I'll admit it isn't strictly a branch, but that's what most\npeople will want to see, I expect.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"}]}