{"thread":{"id":"16956","subject":"git-branch --print-current","startedAt":"2009-01-02T03:28:12Z","lastAt":"2009-01-07T04:58:44Z","messageCount":28,"participants":["Karl Chen","David Aguilar","Miklos Vajna","Junio C Hamano","Arnaud Lacombe","Alexandre Dulaunoy","demerphq","Adeodato Simó","Jakub Narebski","Shawn O. Pearce","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"99143","messageId":"quack.20090101T1928.lthzliaqtdf@roar.cs.berkeley.edu","threadId":"16956","inReplyTo":null,"subject":"git-branch --print-current","fromName":"Karl Chen","fromEmail":"quarl@cs.berkeley.edu","sentAt":"2009-01-02T03:28:12Z","receivedAt":"2009-01-02T03:28:12Z","isPatch":false,"sender":{"key":"quarl@cs.berkeley.edu","avatar":null},"body":"\nHow about an option to git-branch that just prints the name of the\ncurrent branch for scripts' sake? To replace:\n\n git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'\n"},{"id":"99144","messageId":"402731c90901012026j470f35ffj1eaa189a837054f3@mail.gmail.com","threadId":"16956","inReplyTo":"quack.20090101T1928.lthzliaqtdf@roar.cs.berkeley.edu","subject":"Re: git-branch --print-current","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-01-02T04:26:29Z","receivedAt":"2009-01-02T04:26:29Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Thu, Jan 1, 2009 at 7:28 PM, Karl Chen wrote:\n>\n> How about an option to git-branch that just prints the name of\n> the current branch for scripts' sake? To replace:\n>\n> git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'\n\n\nThe justification I've heard before is that 'git branch' is a\nporcelain and thus we shouldn't rely on its output for scripting\npurposes.\n\nYou might want to use 'git symbolic-ref' instead.\n\n$ git symbolic-ref HEAD\nrefs/heads/master\n\n$ git symbolic-ref HEAD | sed -e 's,refs/heads/,,'\nmaster\n\n\n-- \n David\n"},{"id":"99277","messageId":"quack.20090103T1818.lth7i5bg6f7@roar.cs.berkeley.edu","threadId":"16956","inReplyTo":"402731c90901012026j470f35ffj1eaa189a837054f3@mail.gmail.com","subject":"Re: git-branch --print-current","fromName":"Karl Chen","fromEmail":"quarl@cs.berkeley.edu","sentAt":"2009-01-04T02:18:36Z","receivedAt":"2009-01-04T02:18:36Z","isPatch":false,"sender":{"key":"quarl@cs.berkeley.edu","avatar":null},"body":">>>>> On 2009-01-01 20:26 PST, David Aguilar writes:\n\n David> You might want to use 'git symbolic-ref' instead.\n\n David> $ git symbolic-ref HEAD | sed -e 's,refs/heads/,,'\n David> master\n\nThanks, that is better.\n\nHow about an option to git-symbolic-ref that gets rid of the\nrefs/heads/ ?\n"},{"id":"99278","messageId":"20090104033839.GD21154@genesis.frugalware.org","threadId":"16956","inReplyTo":"quack.20090103T1818.lth7i5bg6f7@roar.cs.berkeley.edu","subject":"Re: git-branch --print-current","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-01-04T03:38:39Z","receivedAt":"2009-01-04T03:38:39Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sat, Jan 03, 2009 at 06:18:36PM -0800, Karl Chen wrote:\n> How about an option to git-symbolic-ref that gets rid of the\n> refs/heads/ ?\n\nMake an alias?\n\ngit config alias.cb '!sh -c \"git symbolic-ref HEAD|sed s,refs/heads/,,\"'\n\n$ git cb\nmaster\n\n(Where cb can stand for 'current branch', for example.)\n"},{"id":"99279","messageId":"quack.20090103T2026.lth3afzg0hx@roar.cs.berkeley.edu","threadId":"16956","inReplyTo":"20090104033839.GD21154@genesis.frugalware.org","subject":"Re: git-branch --print-current","fromName":"Karl Chen","fromEmail":"quarl@cs.berkeley.edu","sentAt":"2009-01-04T04:26:34Z","receivedAt":"2009-01-04T04:26:34Z","isPatch":false,"sender":{"key":"quarl@cs.berkeley.edu","avatar":null},"body":">>>>> On 2009-01-03 19:38 PST, Miklos Vajna writes:\n\n Miklos> On Sat, Jan 03, 2009 at 06:18:36PM -0800, Karl Chen wrote:\n >> How about an option to git-symbolic-ref that gets rid of\n >> the refs/heads/ ?\n\n Miklos> Make an alias?\n\nThanks for the suggestion. I don't have any problems making\naliases or using git-branch for interactive output; it's not an\nissue of typing less.\n\nI guess the broader point is that people use these \"porcelain\"\ncommands in scripts and parse their output even when they\nshouldn't, and it's better to take action to prevent that. This\nreminds me of the issue of debugfs supposedly not being an ABI but\npeople rely on anyway since it's stable enough - people are\nstarting to rely on 'git branch' output just to print the current\nbranch name. Better to create or at least publicly point out a\ngood alternative to nip this in the bud.\n\nI suppose \"user education\" in the form of a big warning in the\ngit-branch man page would also help. How do you even tell in the\nman page whether a command is porcelain or not? Still, I think\nsomething like this is worth making slightly easier. Another\nminor argument for something like git branch --print-name is that\nit's annoying to check the exit code inside a pipeline.\n\nFor example: Google for how to add the name of the git branch to\nthe bash prompt and you'll find countless examples of people using\ngit-branch. And they're all different, so people aren't just\nblindly copying one guy; here is a small sample:\n \n export PS1='...`git branch 2> /dev/null | grep -e ^* | sed\n -E s/^\\\\\\\\\\*\\ \\(.+\\)$/\\(\\\\\\\\\\1\\)\\\n \n $(git branch &>/dev/null; if [ $? -eq 0 ]; then echo \"\n ($(git branch | grep '^*' |sed s/\\*\\ //))\"; fi)\n \n `ruby -e \\\"print (%x{git branch 2>\n /dev/null}.grep(/^\\*/).first || '').gsub(/^\\* (.+)$/, '(\\1)\n ')\\\"\\`\n \n parse_git_branch() {\n git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \\(.*\\)/(\\1)/'\n }\n \n `git branch 2>/dev/null|cut -f2 -d\\* -s`\n \n git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \\(.*\\)/(\\1)/'\n \n git_branch=`git branch 2>/dev/null | grep -e '^*' | sed -E 's/^\\* (.+)$/(\\1) /'`\n \nThere were a few using git-symbolic-ref but most used git-branch.\n"},{"id":"99280","messageId":"7vzli73b1g.fsf@gitster.siamese.dyndns.org","threadId":"16956","inReplyTo":"quack.20090103T2026.lth3afzg0hx@roar.cs.berkeley.edu","subject":"Re: git-branch --print-current","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-04T05:17:15Z","receivedAt":"2009-01-04T05:17:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Chen writes:\n\n> For example: Google for how to add the name of the git branch to\n> the bash prompt and you'll find countless examples of people using\n> git-branch. And they're all different, so people aren't just\n> blindly copying one guy; here is a small sample:\n> ...\n> There were a few using git-symbolic-ref but most used git-branch.\n\nThat is a good point about user education, and is a demonstration why a\nnew option to cover a very narrow-special case to symbolic-ref will not\nhelp the situation. People will add their own embellishments around the\nname of the branch anyway, and the most generic symbolic-ref output is\njust as useful as a special case option to show without refs/heads/.\n\nWhat you quoted are all inferior implementations of showing the name of\nthe current branch in the bash prompt. The most correct way (in the sense\nthat it won't be broken in future git) is always found in the bash\ncompletion script in contrib/completion/git-completion.bash and it reads:\n\n PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n\nYou can of course change this to suit your taste. For example, here is a\nvariant I personally use:\n\n PS1=': \\h \\W$(__git_ps1 \"/%s\"); '\n\nThe point is that __git_ps1 shell function is defined to be used for this\nexact purpose and is documented in the completion script.\n\nBesides showing the current branch, it knows how to interpret the various\nstate clues git operations leave in the repository and the work tree, and\nreminds them what you are in the middle of (e.g. applying patch series\nusing \"git am\", rebasing interactively, resolving conflicts after a merge\ndid not autoresolve, etc.), and also knows how to show the detached HEAD.\n"},{"id":"99284","messageId":"1a69a9d80901040021i1dae2c6j7337cf57eed6476a@mail.gmail.com","threadId":"16956","inReplyTo":"quack.20090101T1928.lthzliaqtdf@roar.cs.berkeley.edu","subject":"Re: git-branch --print-current","fromName":"Arnaud Lacombe","fromEmail":"lacombar@gmail.com","sentAt":"2009-01-04T08:21:47Z","receivedAt":"2009-01-04T08:21:47Z","isPatch":false,"sender":{"key":"lacombar@gmail.com","avatar":"https://gravatar.com/avatar/411d40b6ba69fff936664b1ff7cff65f3ca23f236700f0f0d0313b6b43abd344?d=mp&s=160"},"body":"Hi,\n\nOn Thu, Jan 1, 2009 at 10:28 PM, Karl Chen wrote:\n>\n> How about an option to git-branch that just prints the name of the\n> current branch for scripts' sake? To replace:\n>\n> git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'\nFWIW, I had this in a stalled modification in a tree, it just add the\n'-c' (as \"current\") option to git branch. Patch is mostly for the\nrecord :/\n\nThe main trouble I have with pipe stuff is that it forks a process for\nsomething that can be done natively. Previously, I was using awk(1) to\nextract the current branch:\n\n$ git branch | awk '/^\\*/ {print $2}'\n\n - Arnaud\n\n\ndiff --git a/builtin-branch.c b/builtin-branch.c\nindex 494cbac..2846768 100644\n--- a/builtin-branch.c\n+++ b/builtin-branch.c\n@@ -17,7 +17,7 @@\n #include \"revision.h\"\n \n static const char * const builtin_branch_usage[] = {\n-\t\"git branch [options] [-r | -a] [--merged | --no-merged]\",\n+\t\"git branch [options] [-r | -a | -c] [--merged | --no-merged]\",\n \t\"git branch [options] [-l] [-f] []\",\n \t\"git branch [options] [-r] (-d | -D) \",\n \t\"git branch [options] (-m | -M) [] \",\n@@ -312,9 +312,6 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,\n \tint color;\n \tstruct commit *commit = item->commit;\n \n-\tif (!matches_merge_filter(commit))\n-\t\treturn;\n-\n \tswitch (item->kind) {\n \tcase REF_LOCAL_BRANCH:\n \t\tcolor = COLOR_BRANCH_LOCAL;\n@@ -373,18 +370,58 @@ static int calc_maxwidth(struct ref_list *refs)\n \treturn w;\n }\n \n-static void print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)\n+static inline int is_current(struct ref_item *item, int detached)\n+{\n+\n+\tif (detached ||\n+\t item->kind != REF_LOCAL_BRANCH ||\n+\t strcmp(item->name, head) != 0)\n+\t\treturn 0;\n+\n+\treturn 1;\n+}\n+\n+static void print_ref_list(struct ref_list *ref_list, int kinds, int detached,\n+ int verbose, int abbrev, struct commit_list *with_commit)\n {\n+\tstruct commit *head_commit;\n \tint i;\n+\n+\thead_commit = lookup_commit_reference_gently(head_sha1, 1);\n+\n+\tdetached = (detached && (kinds & REF_LOCAL_BRANCH));\n+\tif (detached && head_commit && has_commit(head_commit, with_commit)) {\n+\t\tstruct ref_item item;\n+\t\titem.name = xstrdup(\"(no branch)\");\n+\t\titem.kind = REF_LOCAL_BRANCH;\n+\t\titem.commit = head_commit;\n+\t\tif (strlen(item.name) > ref_list->maxwidth)\n+\t\t\tref_list->maxwidth = strlen(item.name);\n+\t\tprint_ref_item(&item, ref_list->maxwidth, verbose, abbrev, 1);\n+\t\tfree(item.name);\n+\t}\n+\tfor (i = 0; i < ref_list->index; i++) {\n+\t\tint current = is_current(&ref_list->list[i], detached);\n+\t\tprint_ref_item(&ref_list->list[i], ref_list->maxwidth, verbose,\n+\t\t\t abbrev, current);\n+\t}\n+\n+}\n+\n+static void print_branch(int kinds, int detached, int verbose, int abbrev,\n+\t\t\t int only_current, struct commit_list *with_commit)\n+{\n \tstruct ref_list ref_list;\n-\tstruct commit *head_commit = lookup_commit_reference_gently(head_sha1, 1);\n+\tint i;\n \n \tmemset(&ref_list, 0, sizeof(ref_list));\n \tref_list.kinds = kinds;\n \tref_list.with_commit = with_commit;\n \tif (merge_filter != NO_FILTER)\n \t\tinit_revisions(&ref_list.revs, NULL);\n+\n \tfor_each_ref(append_ref, &ref_list);\n+\n \tif (merge_filter != NO_FILTER) {\n \t\tstruct commit *filter;\n \t\tfilter = lookup_commit_reference_gently(merge_filter_ref, 0);\n@@ -399,29 +436,24 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str\n \n \tqsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);\n \n-\tdetached = (detached && (kinds & REF_LOCAL_BRANCH));\n-\tif (detached && head_commit && has_commit(head_commit, with_commit)) {\n-\t\tstruct ref_item item;\n-\t\titem.name = xstrdup(\"(no branch)\");\n-\t\titem.kind = REF_LOCAL_BRANCH;\n-\t\titem.commit = head_commit;\n-\t\tif (strlen(item.name) > ref_list.maxwidth)\n-\t\t\tref_list.maxwidth = strlen(item.name);\n-\t\tprint_ref_item(&item, ref_list.maxwidth, verbose, abbrev, 1);\n-\t\tfree(item.name);\n-\t}\n+\tif (only_current) {\n+\t\tfor (i = 0; i < ref_list.index; i++) {\n+\t\t\tif (!is_current(&ref_list.list[i], detached))\n+\t\t\t\tcontinue;\n+\t\t\tif (!matches_merge_filter(ref_list.list[i].commit))\n+\t\t\t\tcontinue;\n \n-\tfor (i = 0; i < ref_list.index; i++) {\n-\t\tint current = !detached &&\n-\t\t\t(ref_list.list[i].kind == REF_LOCAL_BRANCH) &&\n-\t\t\t!strcmp(ref_list.list[i].name, head);\n-\t\tprint_ref_item(&ref_list.list[i], ref_list.maxwidth, verbose,\n-\t\t\t abbrev, current);\n+\t\t\tprintf(\"%s\\n\", ref_list.list[i].name);\n+\t\t}\n+\t\tgoto free_it;\n \t}\n \n+\tprint_ref_list(&ref_list, kinds, detached, verbose,\n+\t abbrev, with_commit);\n+\n+free_it:\n \tfree_ref_list(&ref_list);\n }\n-\n static void rename_branch(const char *oldname, const char *newname, int force)\n {\n \tstruct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;\n@@ -499,7 +531,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n {\n \tint delete = 0, rename = 0, force_create = 0;\n \tint verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;\n-\tint reflog = 0;\n+\tint only_current = 0, reflog = 0;\n \tenum branch_track track;\n \tint kinds = REF_LOCAL_BRANCH;\n \tstruct commit_list *with_commit = NULL;\n@@ -524,6 +556,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\t\tPARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,\n \t\t\topt_parse_with_commit, (intptr_t) \"HEAD\",\n \t\t},\n+\t\tOPT_SET_INT('c', NULL, &only_current, \"show only current branch\", 1),\n \t\tOPT__ABBREV(&abbrev),\n \n \t\tOPT_GROUP(\"Specific git-branch actions:\"),\n@@ -576,9 +609,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \n \tif (delete)\n \t\treturn delete_branches(argc, argv, delete > 1, kinds);\n-\telse if (argc == 0)\n-\t\tprint_ref_list(kinds, detached, verbose, abbrev, with_commit);\n-\telse if (rename && (argc == 1))\n+\telse if (argc == 0) {\n+\t\tprint_branch(kinds, detached, verbose, abbrev, only_current,\n+\t\t with_commit);\n+\t}else if (rename && (argc == 1))\n \t\trename_branch(head, argv[0], rename > 1);\n \telse if (rename && (argc == 2))\n \t\trename_branch(argv[0], argv[1], rename > 1);\n"},{"id":"99290","messageId":"1baa801f0901040207r64195594m64359dbc60a5f662@mail.gmail.com","threadId":"16956","inReplyTo":"quack.20090101T1928.lthzliaqtdf@roar.cs.berkeley.edu","subject":"Re: git-branch --print-current","fromName":"Alexandre Dulaunoy","fromEmail":"adulau@gmail.com","sentAt":"2009-01-04T10:07:20Z","receivedAt":"2009-01-04T10:07:20Z","isPatch":false,"sender":{"key":"adulau@gmail.com","avatar":null},"body":"On Fri, Jan 2, 2009 at 4:28 AM, Karl Chen wrote:\n>\n> How about an option to git-branch that just prints the name of the\n> current branch for scripts' sake? To replace:\n>\n> git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'\n\nI tend to support your request especially that extracting the current\nbranch is something that is done regularly. Looking in my own scripts/aliases\nand some of my colleagues, there are plenty of variation using Perl,\nsed, awk, tr\nand Python to extract the current branch.\n\nUsing git-symbolic-ref is not obvious, especially that the summary/name\n of the man page is :\n\n\"git-symbolic-ref - Read and modify symbolic refs\"\n\nBut the description is pretty clear :\n\n\"Given one argument, reads which branch head the given symbolic ref refers to\nand outputs its path, relative to the .git/ directory. Typically you\nwould give HEAD\nas the argument to see on which branch your working tree is on.\"\n\nBut naturally, as a lazy user, you will pick git-branch especially\nthat's the tools is listed\nwith the most commonly used git commands with a very attractive description :\n\n\"branch List, create, or delete branches\"\n\nOn an user perspective, having the option in git-branch seems more natural.\n\nJust a comment,\n\n-- \n-- Alexandre Dulaunoy (adulau) -- http://www.foo.be/\n-- http://www.foo.be/cgi-bin/wiki.pl/Diary\n-- \"Knowledge can create problems, it is not through ignorance\n-- that we can solve them\" Isaac Asimov\n"},{"id":"99296","messageId":"9b18b3110901040431j5c318007kcec4694446434764@mail.gmail.com","threadId":"16956","inReplyTo":"1baa801f0901040207r64195594m64359dbc60a5f662@mail.gmail.com","subject":"Re: git-branch --print-current","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-01-04T12:31:50Z","receivedAt":"2009-01-04T12:31:50Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/1/4 Alexandre Dulaunoy :\n> On Fri, Jan 2, 2009 at 4:28 AM, Karl Chen wrote:\n>>\n>> How about an option to git-branch that just prints the name of the\n>> current branch for scripts' sake? To replace:\n>>\n>> git branch --no-color 2>/dev/null | perl -ne '/^[*] (.*)/ && print $1'\n>\n> I tend to support your request especially that extracting the current\n> branch is something that is done regularly. Looking in my own scripts/aliases\n> and some of my colleagues, there are plenty of variation using Perl,\n> sed, awk, tr\n> and Python to extract the current branch.\n>\n> Using git-symbolic-ref is not obvious, especially that the summary/name\n> of the man page is :\n>\n> \"git-symbolic-ref - Read and modify symbolic refs\"\n>\n> But the description is pretty clear :\n>\n> \"Given one argument, reads which branch head the given symbolic ref refers to\n> and outputs its path, relative to the .git/ directory. Typically you\n> would give HEAD\n> as the argument to see on which branch your working tree is on.\"\n>\n> But naturally, as a lazy user, you will pick git-branch especially\n> that's the tools is listed\n> with the most commonly used git commands with a very attractive description :\n\nI dont think it has to do with lazyness. It has to do with the fact\nthat parsing git branch gives you a branch name that you can use an an\nargument to many other git commands. Whereas git-symbolic-ref doesnt.\nIt requires additional post-processing that unless you are very git\naware is not at all clear. Like for instance in this thread the\nrecommendation is to use sed like this:\n\n git symbolic-ref HEAD|sed s,refs/heads/,,\n\nhowever, that makes me think \"how do i do that on a windows box? does\nthe presence of git on a windows box mean that they will necessarily\nhave sed available? Can i rely on that? Can i rely on the sed rule\nbeing sufficient? And what happens with this command if im not on a\nbranch at all? Well it turns out that git symbolic-ref HEAD *dies*\nwith a fatal error on this command. SO it probably should be:\n\n git symbolic-ref HEAD 2>/dev/null|sed s,refs/heads/,,\n\nbut now its even less portable. Even if sed is available on windows\n/dev/null isnt.\n\nId very much like a proper way to find the usable form of the branch\nname as it would make a lot of thing easier. In particular requiring\npeople use pipes means that there is a portability issue with scripts.\nHow does one make this happen on a windows box for instance?\n\nId also very much like a way to find the \"upstream\" for a branch. IOW,\nid very much like to know where I will push to if i issue a \"git push\"\ncommand, or what i will merge if i do a git pull. There doesnt seem to\nbe an easy way to find this out currently. And its very useful\ninformation.\n\nIm coming from the point of view of someone trying to make the perl\nbuild process a bit more \"git aware\". Unfortunately Perl has to build\nout of the box on so many platforms that unix-centric tricks like huge\ncommand pipes arent very helpful. They immediately fall down when you\nstart dealing with oddball platforms like Windows and VMS.\n\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"99297","messageId":"quack.20090104T0434.lthfxjz1c8x_-_@roar.cs.berkeley.edu","threadId":"16956","inReplyTo":"7vzli73b1g.fsf@gitster.siamese.dyndns.org","subject":"git-rev-parse --symbolic-abbrev-name [was Re: git-branch --print-current]","fromName":"Karl Chen","fromEmail":"quarl@cs.berkeley.edu","sentAt":"2009-01-04T12:34:06Z","receivedAt":"2009-01-04T12:34:06Z","isPatch":false,"sender":{"key":"quarl@cs.berkeley.edu","avatar":null},"body":">>>>> On 2009-01-03 21:17 PST, Junio C Hamano writes:\n\n Junio> That is a good point about user education, and is a\n Junio> demonstration why a new option to cover a very\n Junio> narrow-special case to symbolic-ref will not help the\n Junio> situation. People will add their own embellishments\n Junio> around the name of the branch anyway, and the most\n Junio> generic symbolic-ref output is just as useful as a\n Junio> special case option to show without refs/heads/.\n\nThat's arguable :) you really think \"branchfoo\" instead of\n\"refs/heads/branchfoo\" is a narrow special case? Seems like a\ncommon case for everyone except plumbing tools.\n\nHere's a more general idea you might like better:\n\n git symbolic-ref --abbrev BLAH\nor even\n git rev-parse --symbolic-abbrev-name BLAH\n\nThis would be like git-rev-parse --symbolic-full-name, but strips\nthe \"refs/x/\" iff the result is unambiguous. Since it's much more\nwork for a script to check whether the stripped version is\nambiguous, this functionality is appropriate as a builtin option.\n\n(Hmm, I guess to be able to specify a ref it has to already be\nunambiguous, so the main use that --symbolic doesn't already cover\nis for symbolic refs such as HEAD.)\n\n Junio> What you quoted are all inferior implementations of\n Junio> showing the name of the current branch in the bash\n Junio> prompt.\n\nYup, that was the point - it's so ugly seeing all these things\nfloating around, but that's where things stand right now.\n\n Junio> ... __git_ps1 shell function is defined to be used for\n Junio> this exact purpose and is documented in the completion\n Junio> script.\n\nThanks for the detailed explanation. I actually use zsh rather\nthan of bash and I did already find git-completion.bash. But\nobviously all those people posting on blogs don't know about it :)\n"},{"id":"99298","messageId":"9b18b3110901040440i70ce50d0v8996b8fef33a58cf@mail.gmail.com","threadId":"16956","inReplyTo":"quack.20090104T0434.lthfxjz1c8x_-_@roar.cs.berkeley.edu","subject":"Re: git-rev-parse --symbolic-abbrev-name [was Re: git-branch --print-current]","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-01-04T12:40:08Z","receivedAt":"2009-01-04T12:40:08Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/1/4 Karl Chen :\n>>>>>> On 2009-01-03 21:17 PST, Junio C Hamano writes:\n>\n> Junio> That is a good point about user education, and is a\n> Junio> demonstration why a new option to cover a very\n> Junio> narrow-special case to symbolic-ref will not help the\n> Junio> situation. People will add their own embellishments\n> Junio> around the name of the branch anyway, and the most\n> Junio> generic symbolic-ref output is just as useful as a\n> Junio> special case option to show without refs/heads/.\n>\n> That's arguable :) you really think \"branchfoo\" instead of\n> \"refs/heads/branchfoo\" is a narrow special case? Seems like a\n> common case for everyone except plumbing tools.\n\nI agree. All the scripting I've done involves using the non qualified form.\n\n> Here's a more general idea you might like better:\n>\n> git symbolic-ref --abbrev BLAH\n> or even\n> git rev-parse --symbolic-abbrev-name BLAH\n>\n> This would be like git-rev-parse --symbolic-full-name, but strips\n> the \"refs/x/\" iff the result is unambiguous. Since it's much more\n> work for a script to check whether the stripped version is\n> ambiguous, this functionality is appropriate as a builtin option.\n\nI vote for this, I could and would use it many scripts. Also please\ndont make it die if BLAH is not a symbolic ref if this option is used.\nJust return nothing.\n\ncheers,\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"99299","messageId":"quack.20090104T0440.lthbpun1bxo@roar.cs.berkeley.edu","threadId":"16956","inReplyTo":"1a69a9d80901040021i1dae2c6j7337cf57eed6476a@mail.gmail.com","subject":"Re: git-branch --print-current","fromName":"Karl Chen","fromEmail":"quarl@cs.berkeley.edu","sentAt":"2009-01-04T12:40:51Z","receivedAt":"2009-01-04T12:40:51Z","isPatch":false,"sender":{"key":"quarl@cs.berkeley.edu","avatar":null},"body":">>>>> On 2009-01-04 00:21 PST, Arnaud Lacombe writes:\n\n Arnaud> FWIW, I had this in a stalled modification in a tree,\n Arnaud> it just add the '-c' (as \"current\") option to git\n Arnaud> branch. Patch is mostly for the record :/\n\nThanks, glad someone else wanted this too. If we modified\ngit-symbolic-ref it would probably be less code since it doesn't\nhave to loop over all branches, though from a UI perspective I\nstill prefer git-branch. Anyway doesn't look like people like the\nidea so how about that git-rev-parse --symbolic-abbrev-name idea\n:)\n\n Arnaud> The main trouble I have with pipe stuff is that it\n Arnaud> forks a process for something that can be done\n Arnaud> natively. Previously, I was using awk(1) to extract\n Arnaud> the current branch:\n\n Arnaud> $ git branch | awk '/^\\*/ {print $2}'\n\nYet another addition to the list of ways to pipeline it, this one\nprobably the shortest :)\n\n[BTW, your patch mime type was application/octet-stream :(]\n"},{"id":"99300","messageId":"9b18b3110901040449x65c63d6fo3d9fec9ddd5670c@mail.gmail.com","threadId":"16956","inReplyTo":"quack.20090104T0440.lthbpun1bxo@roar.cs.berkeley.edu","subject":"Re: git-branch --print-current","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-01-04T12:49:11Z","receivedAt":"2009-01-04T12:49:11Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/1/4 Karl Chen :\n>>>>>> On 2009-01-04 00:21 PST, Arnaud Lacombe writes:\n>\n> Arnaud> FWIW, I had this in a stalled modification in a tree,\n> Arnaud> it just add the '-c' (as \"current\") option to git\n> Arnaud> branch. Patch is mostly for the record :/\n>\n> Thanks, glad someone else wanted this too. If we modified\n> git-symbolic-ref it would probably be less code since it doesn't\n> have to loop over all branches, though from a UI perspective I\n> still prefer git-branch. Anyway doesn't look like people like the\n> idea so how about that git-rev-parse --symbolic-abbrev-name idea\n> :)\n\nFWIW: I like the idea. Ive always thought that a --current flag to git\nbranch was missing. IOW i should be able to do:\n\n branch=`git branch --current`\n\nand get back a usable branch name. I dont think one should need to\nrely on awk or sed or scripts to find this out, if only for\nportability reasons.\n\n>\n> Arnaud> The main trouble I have with pipe stuff is that it\n> Arnaud> forks a process for something that can be done\n> Arnaud> natively. Previously, I was using awk(1) to extract\n> Arnaud> the current branch:\n>\n> Arnaud> $ git branch | awk '/^\\*/ {print $2}'\n>\n> Yet another addition to the list of ways to pipeline it, this one\n> probably the shortest :)\n\nUnfortunately it doesnt work well when you arent on a branch:\n\n $ git branch | awk '/^\\*/ {print $2}'\n (no\n\nSo far two apparently expert git people have given solutions to this\nproblem that don't elegantly handle the edge cases.\n\nThat seems to me to be a powerful argument that it is actually more\ndifficult to do than is being represented here on the list, and\ndeserves to be native level git functionality.\n\nCheers,\nyves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"99303","messageId":"9b18b3110901040535m1f67cb7er95823d31443ee971@mail.gmail.com","threadId":"16956","inReplyTo":"7vzli73b1g.fsf@gitster.siamese.dyndns.org","subject":"Re: git-branch --print-current","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-01-04T13:35:58Z","receivedAt":"2009-01-04T13:35:58Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/1/4 Junio C Hamano :\n> Karl Chen writes:\n>\n>> For example: Google for how to add the name of the git branch to\n>> the bash prompt and you'll find countless examples of people using\n>> git-branch. And they're all different, so people aren't just\n>> blindly copying one guy; here is a small sample:\n>> ...\n>> There were a few using git-symbolic-ref but most used git-branch.\n>\n> That is a good point about user education, and is a demonstration why a\n> new option to cover a very narrow-special case to symbolic-ref will not\n> help the situation. People will add their own embellishments around the\n> name of the branch anyway, and the most generic symbolic-ref output is\n> just as useful as a special case option to show without refs/heads/.\n>\n> What you quoted are all inferior implementations of showing the name of\n> the current branch in the bash prompt. The most correct way (in the sense\n> that it won't be broken in future git) is always found in the bash\n> completion script in contrib/completion/git-completion.bash and it reads:\n>\n> PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n>\n> You can of course change this to suit your taste. For example, here is a\n> variant I personally use:\n>\n> PS1=': \\h \\W$(__git_ps1 \"/%s\"); '\n>\n> The point is that __git_ps1 shell function is defined to be used for this\n> exact purpose and is documented in the completion script.\n>\n> Besides showing the current branch, it knows how to interpret the various\n> state clues git operations leave in the repository and the work tree, and\n> reminds them what you are in the middle of (e.g. applying patch series\n> using \"git am\", rebasing interactively, resolving conflicts after a merge\n> did not autoresolve, etc.), and also knows how to show the detached HEAD.\n\nThe version im using, from git version 1.6.0.4.724.ga0d3a produces the\nfollowing error:\n\ncut: ./HEAD: No such file or directory\n\nwhen in the .git/refs directory.\n\nCheers,\nyves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"99315","messageId":"1a69a9d80901040955v51671b1dv6ca6fc644455b6b1@mail.gmail.com","threadId":"16956","inReplyTo":"9b18b3110901040449x65c63d6fo3d9fec9ddd5670c@mail.gmail.com","subject":"Re: git-branch --print-current","fromName":"Arnaud Lacombe","fromEmail":"lacombar@gmail.com","sentAt":"2009-01-04T17:55:44Z","receivedAt":"2009-01-04T17:55:44Z","isPatch":false,"sender":{"key":"lacombar@gmail.com","avatar":"https://gravatar.com/avatar/411d40b6ba69fff936664b1ff7cff65f3ca23f236700f0f0d0313b6b43abd344?d=mp&s=160"},"body":"Hi,\n\nOn Sun, Jan 4, 2009 at 7:49 AM, demerphq wrote:\n> 2009/1/4 Karl Chen :\n>> On 2009-01-04 00:21 PST, Arnaud Lacombe writes:\n>> Arnaud> $ git branch | awk '/^\\*/ {print $2}'\n>>\n>> Yet another addition to the list of ways to pipeline it, this one\n>> probably the shortest :)\n>\n> Unfortunately it doesnt work well when you arent on a branch:\n>\n> $ git branch | awk '/^\\*/ {print $2}'\n> (no\n>\n> So far two apparently expert git people have given solutions to this\n> problem that don't elegantly handle the edge cases.\n>\nmy bad:\n$ git branch | awk '/^\\*/ {print substr($0, 3)}'\n\n - Arnaud\n"},{"id":"99317","messageId":"20090104180208.GA12298@chistera.yi.org","threadId":"16956","inReplyTo":"quack.20090104T0440.lthbpun1bxo@roar.cs.berkeley.edu","subject":"Re: git-branch --print-current","fromName":"Adeodato Simó","fromEmail":"dato@net.com.org.es","sentAt":"2009-01-04T18:02:08Z","receivedAt":"2009-01-04T18:02:08Z","isPatch":false,"sender":{"key":"dato@net.com.org.es","avatar":"https://gravatar.com/avatar/952ec7d5d5663eb8baf631b5c37f9c58480a881920dd5f8a2d3a71f969b72b53?d=mp&s=160"},"body":"* Karl Chen [Sun, 04 Jan 2009 04:40:51 -0800]:\n\n> Arnaud> $ git branch | awk '/^\\*/ {print $2}'\n\n> Yet another addition to the list of ways to pipeline it, this one\n> probably the shortest :)\n\nHeh, if we're playing golf:\n\n $ git branch | sed -n 's/^\\* //p'\n\n-- \nAdeodato Simó dato at net.com.org.es\nDebian Developer adeodato at debian.org\n \nQue no te vendan amor sin espinas\n -- Joaquín Sabina, Noches de boda\n"},{"id":"99322","messageId":"7v63kuyibi.fsf@gitster.siamese.dyndns.org","threadId":"16956","inReplyTo":"quack.20090104T0434.lthfxjz1c8x_-_@roar.cs.berkeley.edu","subject":"Re: git-rev-parse --symbolic-abbrev-name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-04T19:36:33Z","receivedAt":"2009-01-04T19:36:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Karl Chen writes:\n\n> ... you really think \"branchfoo\" instead of\n> \"refs/heads/branchfoo\" is a narrow special case?\n\nOf course it is narrower. There are namespaces other than \"heads\" under\nrefs, and not everybody is interested in branches.\n\n> obviously all those people posting on blogs don't know about it :)\n\nYes, and that won't be helped by any new option to the plumbing.\n\nThe above two does not necessarily mean that it is useless to add a new\noption to help a narrow special case that is common, though.\n"},{"id":"99325","messageId":"1a69a9d80901041223r1f3d2956ne05996793bb23e97@mail.gmail.com","threadId":"16956","inReplyTo":"7v63kuyibi.fsf@gitster.siamese.dyndns.org","subject":"Re: git-rev-parse --symbolic-abbrev-name","fromName":"Arnaud Lacombe","fromEmail":"lacombar@gmail.com","sentAt":"2009-01-04T20:23:03Z","receivedAt":"2009-01-04T20:23:03Z","isPatch":false,"sender":{"key":"lacombar@gmail.com","avatar":"https://gravatar.com/avatar/411d40b6ba69fff936664b1ff7cff65f3ca23f236700f0f0d0313b6b43abd344?d=mp&s=160"},"body":"Hi,\n\nOn Sun, Jan 4, 2009 at 2:36 PM, Junio C Hamano wrote:\n> Karl Chen writes:\n>\n>> ... you really think \"branchfoo\" instead of\n>> \"refs/heads/branchfoo\" is a narrow special case?\n>\n> Of course it is narrower. There are namespaces other than \"heads\" under\n> refs, and not everybody is interested in branches.\n>\n>> obviously all those people posting on blogs don't know about it :)\n>\n> Yes, and that won't be helped by any new option to the plumbing.\n>\n> The above two does not necessarily mean that it is useless to add a new\n> option to help a narrow special case that is common, though.\n>\nYou'll find hereafter two patches which implements this in\ngit-symbolic-ref and git-rev-parse. Feel free to choose the one you\nfind the best. If you choose to integrate one of these, tells me and\nI'll do a proper documentation bits and patch submission.\n\nSample output:\n\n~/git/% ./git-rev-parse --symbolic-short-name HEAD\nmaster\n~/git/% ./git-symbolic-ref -a HEAD\nmaster\n~/git/% git checkout v1.6.1\n~/git/% ./git-rev-parse --symbolic-short-name HEAD\nHEAD\n~/git/% ./git-symbolic-ref -a HEAD\nfatal: ref HEAD is not a symbolic ref\n~/git/% ./git-symbolic-ref -qa HEAD\n~/git/%\n\nThanks in advance,\n\n - Arnaud\n\nps: I choose --symbolic-short-name as the opposite of\n--symbolic-full-name for consistency.\nps2: sorry for the bogus mime-type\n\n\ndiff --git a/builtin-rev-parse.c b/builtin-rev-parse.c\nindex 81d5a6f..70f4a33 100644\n--- a/builtin-rev-parse.c\n+++ b/builtin-rev-parse.c\n@@ -24,6 +24,7 @@ static int show_type = NORMAL;\n \n #define SHOW_SYMBOLIC_ASIS 1\n #define SHOW_SYMBOLIC_FULL 2\n+#define SHOW_SYMBOLIC_SHORT 3\n static int symbolic;\n static int abbrev;\n static int output_sq;\n@@ -110,7 +111,10 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)\n \tdef = NULL;\n \n \tif (symbolic && name) {\n-\t\tif (symbolic == SHOW_SYMBOLIC_FULL) {\n+\t\tswitch (symbolic) {\n+\t\tcase SHOW_SYMBOLIC_FULL:\n+\t\tcase SHOW_SYMBOLIC_SHORT:\n+\t\t\t{\n \t\t\tunsigned char discard[20];\n \t\t\tchar *full;\n \n@@ -125,13 +129,20 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)\n \t\t\t\t */\n \t\t\t\tbreak;\n \t\t\tcase 1: /* happy */\n+\t\t\t\tif (symbolic == SHOW_SYMBOLIC_SHORT) {\n+\t\t\t\t\tchar *p;\n+\t\t\t\t\tp = strrchr(full, (int)'/');\n+\t\t\t\t\tif (p != NULL)\n+\t\t\t\t\t\tfull = p + 1;\n+\t\t\t\t}\n \t\t\t\tshow_with_type(type, full);\n \t\t\t\tbreak;\n \t\t\tdefault: /* ambiguous */\n \t\t\t\terror(\"refname '%s' is ambiguous\", name);\n-\t\t\t\tbreak;\n \t\t\t}\n-\t\t} else {\n+\t\t\tbreak;\n+\t\t\t}\n+\t\tdefault:\n \t\t\tshow_with_type(type, name);\n \t\t}\n \t}\n@@ -506,6 +517,10 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)\n \t\t\t\tsymbolic = SHOW_SYMBOLIC_FULL;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--symbolic-short-name\")) {\n+\t\t\t\tsymbolic = SHOW_SYMBOLIC_SHORT;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--all\")) {\n \t\t\t\tfor_each_ref(show_reference, NULL);\n \t\t\t\tcontinue;\n\n\ndiff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c\nindex bfc78bb..ff9ff46 100644\n--- a/builtin-symbolic-ref.c\n+++ b/builtin-symbolic-ref.c\n@@ -8,7 +8,7 @@ static const char * const git_symbolic_ref_usage[] = {\n \tNULL\n };\n \n-static void check_symref(const char *HEAD, int quiet)\n+static void check_symref(const char *HEAD, int quiet, int abbrev)\n {\n \tunsigned char sha1[20];\n \tint flag;\n@@ -22,15 +22,21 @@ static void check_symref(const char *HEAD, int quiet)\n \t\telse\n \t\t\texit(1);\n \t}\n+\tif (abbrev) {\n+\t\tchar *p = strrchr(refs_heads_master, (int)'/');\n+\t\tif (p != NULL)\n+\t\t\trefs_heads_master = p + 1;\n+\t}\n \tputs(refs_heads_master);\n }\n \n int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)\n {\n-\tint quiet = 0;\n+\tint abbrev = 0, quiet = 0;\n \tconst char *msg = NULL;\n \tstruct option options[] = {\n \t\tOPT__QUIET(&quiet),\n+\t\tOPT_BOOLEAN('a', NULL, &abbrev, \"show only branch name\"),\n \t\tOPT_STRING('m', NULL, &msg, \"reason\", \"reason of the update\"),\n \t\tOPT_END(),\n \t};\n@@ -41,7 +47,7 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)\n \t\tdie(\"Refusing to perform update with empty message\");\n \tswitch (argc) {\n \tcase 1:\n-\t\tcheck_symref(argv[0], quiet);\n+\t\tcheck_symref(argv[0], quiet, abbrev);\n \t\tbreak;\n \tcase 2:\n \t\tcreate_symref(argv[0], argv[1], msg);\n"},{"id":"99329","messageId":"m3bpumbv5c.fsf@localhost.localdomain","threadId":"16956","inReplyTo":"20090104180208.GA12298@chistera.yi.org","subject":"Re: git-branch --print-current","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-01-04T21:48:03Z","receivedAt":"2009-01-04T21:48:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Adeodato Simó writes:\n> * Karl Chen [Sun, 04 Jan 2009 04:40:51 -0800]:\n> \n> > Arnaud> $ git branch | awk '/^\\*/ {print $2}'\n> \n> > Yet another addition to the list of ways to pipeline it, this one\n> > probably the shortest :)\n> \n> Heh, if we're playing golf:\n> \n> $ git branch | sed -n 's/^\\* //p'\n\nEven if you want to reimplement __git_ps1 provided with bash\ncompletion in completion/git-completion.bash instead of reusing it,\nyou still have to deal with many situations: not being in git\nrepository, being on detached HEAD, being in intermediate state\n(during git-am, git-rebase, git-bisect etc.), etc. Additionally you\nwould probably want name of git repository and relative path inside\ngit repository in prompt.\n\nTherefore you need to use script anyway. And for scripting you should\nuse plumbing (which output format shouldn't change) and not porcelain\ngit-branch (which output might change, for example having '-v' on by\ndefault, or something; and you might have color.ui set to true by\nmistake and have to deal with color codes). And then you don't need\nsed nor awk: POSIX shell features would be enough:\n\n BR=$(git symbolic-ref HEAD 2>/dev/null)\n BR=${BR#refs/heads/}\n BR=${BR:-HEAD} # one of possibilities to show detached HEAD / no branch\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"99334","messageId":"20090104223819.GI21154@genesis.frugalware.org","threadId":"16956","inReplyTo":"1a69a9d80901041223r1f3d2956ne05996793bb23e97@mail.gmail.com","subject":"Re: git-rev-parse --symbolic-abbrev-name","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-01-04T22:38:19Z","receivedAt":"2009-01-04T22:38:19Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, Jan 04, 2009 at 03:23:03PM -0500, Arnaud Lacombe wrote:\n> ps: I choose --symbolic-short-name as the opposite of\n> --symbolic-full-name for consistency.\n> ps2: sorry for the bogus mime-type\n\nThat's not a problem, just don't attach your patch. Please read\nDocumentation/SubmittingPatches.\n\nThanks.\n"},{"id":"99339","messageId":"7v1vvitwio.fsf@gitster.siamese.dyndns.org","threadId":"16956","inReplyTo":"9b18b3110901040535m1f67cb7er95823d31443ee971@mail.gmail.com","subject":"Re: git-branch --print-current","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-05T00:41:03Z","receivedAt":"2009-01-05T00:41:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n> The version im using, from git version 1.6.0.4.724.ga0d3a produces the\n> following error:\n>\n> cut: ./HEAD: No such file or directory\n>\n> when in the .git/refs directory.\n\nPersonally, I think you are nuts to be in .git/refs and want to use that\ninformation for anything useful, but if it is an easy enough fix, a patch\nwould be useful.\n\nShawn?\n"},{"id":"99342","messageId":"20090105021832.GA20973@spearce.org","threadId":"16956","inReplyTo":"7v1vvitwio.fsf@gitster.siamese.dyndns.org","subject":"Re: git-branch --print-current","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-01-05T02:18:32Z","receivedAt":"2009-01-05T02:18:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> demerphq writes:\n> \n> > The version im using, from git version 1.6.0.4.724.ga0d3a produces the\n> > following error:\n> >\n> > cut: ./HEAD: No such file or directory\n> >\n> > when in the .git/refs directory.\n> \n> Personally, I think you are nuts to be in .git/refs and want to use that\n> information for anything useful, but if it is an easy enough fix, a patch\n> would be useful.\n\nI agree, its nuts to be there. But this also does show up in 1.6.1.\nWhat's odd is the output of rev-parse --git-dir is wrong:\n\n $ cd .git/refs\n $ git rev-parse --git-dir\n .\n\nIts *not* \".\", its \"..\", I'm *in* the directory. This throws off\na lot of the other operations we do in __git_ps1, like detecting\nthe repository state by checking MERGE_HEAD or rebase-apply.\n\nI think we should fix rev-parse --git-dir if we can, not the bash\ncompletion code.\n\n-- \nShawn.\n"},{"id":"99346","messageId":"7vsknys8y1.fsf@gitster.siamese.dyndns.org","threadId":"16956","inReplyTo":"20090105021832.GA20973@spearce.org","subject":"Re: git-branch --print-current","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-05T03:55:34Z","receivedAt":"2009-01-05T03:55:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Junio C Hamano wrote:\n>> demerphq writes:\n>> \n>> > The version im using, from git version 1.6.0.4.724.ga0d3a produces the\n>> > following error:\n>> >\n>> > cut: ./HEAD: No such file or directory\n>> >\n>> > when in the .git/refs directory.\n>> \n>> Personally, I think you are nuts to be in .git/refs and want to use that\n>> information for anything useful, but if it is an easy enough fix, a patch\n>> would be useful.\n>\n> I agree, its nuts to be there. But this also does show up in 1.6.1.\n> What's odd is the output of rev-parse --git-dir is wrong:\n>\n> $ cd .git/refs\n> $ git rev-parse --git-dir\n> .\n>\n> Its *not* \".\", its \"..\", I'm *in* the directory. This throws off\n> a lot of the other operations we do in __git_ps1, like detecting\n> the repository state by checking MERGE_HEAD or rebase-apply.\n>\n> I think we should fix rev-parse --git-dir if we can, not the bash\n> completion code.\n\nSigh, yeah, that is what I thought would be happening.\n"},{"id":"99348","messageId":"1a69a9d80901042135w5f1c4aa2jd56ff1d9e4ffd38a@mail.gmail.com","threadId":"16956","inReplyTo":"20090104223819.GI21154@genesis.frugalware.org","subject":"Re: git-rev-parse --symbolic-abbrev-name","fromName":"Arnaud Lacombe","fromEmail":"lacombar@gmail.com","sentAt":"2009-01-05T05:35:23Z","receivedAt":"2009-01-05T05:35:23Z","isPatch":false,"sender":{"key":"lacombar@gmail.com","avatar":"https://gravatar.com/avatar/411d40b6ba69fff936664b1ff7cff65f3ca23f236700f0f0d0313b6b43abd344?d=mp&s=160"},"body":"Hi,\n\nOn Sun, Jan 4, 2009 at 5:38 PM, Miklos Vajna wrote:\n> On Sun, Jan 04, 2009 at 03:23:03PM -0500, Arnaud Lacombe wrote:\n>> ps: I choose --symbolic-short-name as the opposite of\n>> --symbolic-full-name for consistency.\n>> ps2: sorry for the bogus mime-type\n>\n> That's not a problem, just don't attach your patch. Please read\n> Documentation/SubmittingPatches.\n>\nok, looks, I did these patch this morning quickly, didn't commit\nanything or so. If there worth anything, then I'll spent time\ncommiting, doing nice integration, documentation, whatsoever ... Just\nneed a quick yes or no, these as patch are really trivial.\n\n - Arnaud\n\nps: btw, Documentation/git-format-patch.txt does not describe the -M\nflag, not does it describe the -B flag\n"},{"id":"99349","messageId":"20090105055010.GA13189@coredump.intra.peff.net","threadId":"16956","inReplyTo":"7vsknys8y1.fsf@gitster.siamese.dyndns.org","subject":"Re: git-branch --print-current","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-05T05:50:10Z","receivedAt":"2009-01-05T05:50:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jan 04, 2009 at 07:55:34PM -0800, Junio C Hamano wrote:\n\n> > I agree, its nuts to be there. But this also does show up in 1.6.1.\n> > What's odd is the output of rev-parse --git-dir is wrong:\n> >\n> > $ cd .git/refs\n> > $ git rev-parse --git-dir\n> > .\n> >\n> > Its *not* \".\", its \"..\", I'm *in* the directory. This throws off\n> > a lot of the other operations we do in __git_ps1, like detecting\n> > the repository state by checking MERGE_HEAD or rebase-apply.\n> >\n> > I think we should fix rev-parse --git-dir if we can, not the bash\n> > completion code.\n> \n> Sigh, yeah, that is what I thought would be happening.\n\nI took a quick look at this. I think there is something fundamentally\nwrong with the logic for reporting relative git-dir. It basically ends\nup doing something like (this is in setup_git_directory_gently, but the\nvalue is just printed directly in rev-parse):\n\n while (1) {\n if (is_git_dir(\".\")) {\n setenv(\"GIT_DIR\", \".\");\n break;\n }\n chdir(\"..\");\n }\n\nSo yes, it's true at the end of that loop that we the git dir _is_ \".\",\nbut that isn't suitable for telling any other processes who didn't\nfollow the chdir with us.\n\nThe quick fix is for rev-parse to turn that into an absolute path. I\ndon't know if that breaks any callers.\n\nA better fix is probably for setup_git_directory to not require changing\nthe directory (or to chdir back to the original at the end, and set the\nGIT_DIR in a properly relative manner).\n\n-Peff\n"},{"id":"99353","messageId":"20090105064556.GM21154@genesis.frugalware.org","threadId":"16956","inReplyTo":"1a69a9d80901042135w5f1c4aa2jd56ff1d9e4ffd38a@mail.gmail.com","subject":"Re: git-rev-parse --symbolic-abbrev-name","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-01-05T06:45:56Z","receivedAt":"2009-01-05T06:45:56Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Jan 05, 2009 at 12:35:23AM -0500, Arnaud Lacombe wrote:\n> ps: btw, Documentation/git-format-patch.txt does not describe the -M\n> flag, not does it describe the -B flag\n\nBut has a 'include::diff-options.txt[]', so the generated manpage does.\n;-)\n"},{"id":"99439","messageId":"7vocykkftg.fsf@gitster.siamese.dyndns.org","threadId":"16956","inReplyTo":"1a69a9d80901041223r1f3d2956ne05996793bb23e97@mail.gmail.com","subject":"Re: git-rev-parse --symbolic-abbrev-name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-06T08:18:51Z","receivedAt":"2009-01-06T08:18:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Arnaud Lacombe\" writes:\n\n> You'll find hereafter two patches which implements this in\n> git-symbolic-ref and git-rev-parse. Feel free to choose the one you\n> find the best. If you choose to integrate one of these, tells me and\n> I'll do a proper documentation bits and patch submission.\n\n> diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c\n> index 81d5a6f..70f4a33 100644\n> --- a/builtin-rev-parse.c\n> +++ b/builtin-rev-parse.c\n> @@ -24,6 +24,7 @@ static int show_type = NORMAL;\n> \n> #define SHOW_SYMBOLIC_ASIS 1\n> #define SHOW_SYMBOLIC_FULL 2\n> +#define SHOW_SYMBOLIC_SHORT 3\n> static int symbolic;\n> static int abbrev;\n> static int output_sq;\n\nI think --symbolic-short makes the most sense.\n\n> @@ -125,13 +129,20 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)\n> \t\t\t\t */\n> \t\t\t\tbreak;\n> \t\t\tcase 1: /* happy */\n> +\t\t\t\tif (symbolic == SHOW_SYMBOLIC_SHORT) {\n> +\t\t\t\t\tchar *p;\n> +\t\t\t\t\tp = strrchr(full, (int)'/');\n> +\t\t\t\t\tif (p != NULL)\n> +\t\t\t\t\t\tfull = p + 1;\n> +\t\t\t\t}\n\nHowever, this is not a good way to do it, I suspect. This patch most\nlikely will be queued to the al/symbolic-short topic branch, but you are\nlosing information here. You'd probably want to try substings from the\ntail of the full name (e.g. symbolic-short, al/symbolic-short,\nheads/al/symbolic-short, and finally refs/heads/al/symbolic-short) and\nfeed them to dwim_ref() and pick the shortest one that yields the same ref\nunambiguously, or something like that.\n\nBy the way, I do not see why you need to cast '/'.\n"},{"id":"99540","messageId":"1a69a9d80901062058n2e6c51b9vfb2332c79463de37@mail.gmail.com","threadId":"16956","inReplyTo":"7vocykkftg.fsf@gitster.siamese.dyndns.org","subject":"Re: git-rev-parse --symbolic-abbrev-name","fromName":"Arnaud Lacombe","fromEmail":"lacombar@gmail.com","sentAt":"2009-01-07T04:58:44Z","receivedAt":"2009-01-07T04:58:44Z","isPatch":false,"sender":{"key":"lacombar@gmail.com","avatar":"https://gravatar.com/avatar/411d40b6ba69fff936664b1ff7cff65f3ca23f236700f0f0d0313b6b43abd344?d=mp&s=160"},"body":"On Tue, Jan 6, 2009 at 3:18 AM, Junio C Hamano wrote:\n>> diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c\n>> index 81d5a6f..70f4a33 100644\n>> --- a/builtin-rev-parse.c\n>> +++ b/builtin-rev-parse.c\n>> @@ -24,6 +24,7 @@ static int show_type = NORMAL;\n>>\n>> #define SHOW_SYMBOLIC_ASIS 1\n>> #define SHOW_SYMBOLIC_FULL 2\n>> +#define SHOW_SYMBOLIC_SHORT 3\n>> static int symbolic;\n>> static int abbrev;\n>> static int output_sq;\n>\n> I think --symbolic-short makes the most sense.\n>\nok, thanks.\n\n>> @@ -125,13 +129,20 @@ static void show_rev(int type, const unsigned char *sha1, const char *name)\n>> */\n>> break;\n>> case 1: /* happy */\n>> + if (symbolic == SHOW_SYMBOLIC_SHORT) {\n>> + char *p;\n>> + p = strrchr(full, (int)'/');\n>> + if (p != NULL)\n>> + full = p + 1;\n>> + }\n>\n> However, this is not a good way to do it, I suspect. This patch most\n> likely will be queued to the al/symbolic-short topic branch, but you are\n> losing information here. You'd probably want to try substings from the\n> tail of the full name (e.g. symbolic-short, al/symbolic-short,\n> heads/al/symbolic-short, and finally refs/heads/al/symbolic-short) and\n> feed them to dwim_ref() and pick the shortest one that yields the same ref\n> unambiguously, or something like that.\n>\nok, I see what you mean, I'll rework the patch to fix this. I was\nabout to do a proper patch submission when I saw you reply, so it will\nbe for next time!\n\n> By the way, I do not see why you need to cast '/'.\n>\noverzealous type casting due to lack of cafeine in blood :-)\n\nregards,\n\n - Arnaud\n"}]}