{"thread":{"id":"26102","subject":"Commiting automatically (2)","startedAt":"2010-12-19T08:29:50Z","lastAt":"2011-01-03T17:34:08Z","messageCount":13,"participants":["Maaartin","Taylor Hedberg","Jonathan Nieder","Junio C Hamano","Enrico Weigelt","Jakub Narebski","Maaartin-1"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"158355","messageId":"loom.20101219T090500-396@post.gmane.org","threadId":"26102","inReplyTo":null,"subject":"Commiting automatically (2)","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-12-19T08:29:50Z","receivedAt":"2010-12-19T08:29:50Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"Some time ago I asked how to make a commit of the working tree in a way \ninfluencing neither the current branch nor the index:\nhttp://comments.gmane.org/gmane.comp.version-control.git/157056\nI'm going to use it for taking a snapshot of the current working tree without \ndisturbing my work. It seem to work except for one thing:\n\nThere are files tracked by git and later added to .gitignore. AFAIK listing \nthem in .gitignore is a no-op, since I haven't removed them from the index. \nUntil now I haven't known about them at all, I'm currently undecided what to do \nto them.\n\nHowever, when I use my git-autocom script, those files get marked as deleted. \nThis is quite strange, especially because of them still existing. I'd strongly \nprefer git-autocom to behave just like git commit (i.e., tracking the files).\n\nThe relevant part of my script follows:\n\nexport GIT_INDEX_FILE=.git/autocom.tmp\ngit add -A &&\ntree=$(git write-tree) &&\ncommit=$(echo \"$message\" | git commit-tree $tree $parent1 $parent2) &&\ngit update-ref -m \"$message\" refs/heads/autocom $commit\n\nI'd say using another index is the reason for this behavior. The index gets \ncreated on the first use, which is probably why those files look like being \ndeleted. Should I always\n/bin/cp .git/index $GIT_INDEX_FILE\nor is there a better way?\n\nThere's one more problem. My script doesn't recognize deleted files, since\ngit add -A\ndoes nothing to them. I'm quite sure I saw a solution to this, but can't find \nit now...\n"},{"id":"158360","messageId":"20101219150850.GC12136@foodlogiq3-xp-d620.thebe.ath.cx","threadId":"26102","inReplyTo":"loom.20101219T090500-396@post.gmane.org","subject":"Re: Commiting automatically (2)","fromName":"Taylor Hedberg","fromEmail":"tmhedberg@gmail.com","sentAt":"2010-12-19T15:08:51Z","receivedAt":"2010-12-19T15:08:51Z","isPatch":false,"sender":{"key":"tmhedberg@gmail.com","avatar":"https://gravatar.com/avatar/d046da5ea94a7957169aef0fe122771a1f8d9387d39bc68fcfb1332978e11a6c?d=mp&s=160"},"body":"On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:\n> There's one more problem. My script doesn't recognize deleted files, since\n> git add -A\n> does nothing to them. I'm quite sure I saw a solution to this, but can't find \n> it now...\n\nI believe \"git add -u\" will do the same thing as \"git add -A\", plus\nhandle deleted files.\n"},{"id":"158367","messageId":"20101219183619.GB11955@burratino","threadId":"26102","inReplyTo":"20101219150850.GC12136@foodlogiq3-xp-d620.thebe.ath.cx","subject":"Re: Commiting automatically (2)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-19T18:36:19Z","receivedAt":"2010-12-19T18:36:19Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Taylor Hedberg wrote:\n> On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:\n\n>> There's one more problem. My script doesn't recognize deleted files, since\n>> git add -A\n>> does nothing to them. I'm quite sure I saw a solution to this, but can't find \n>> it now...\n>\n> I believe \"git add -u\" will do the same thing as \"git add -A\", plus\n> handle deleted files.\n\nHmm, the \"git add\" manual suggests it is the other way around:\n\n -A, --all\n\tLike -u, but match against files in the working\n\ttree in addition to the index. That means that it will find new\n\tfiles as well as staging modified content and removing files\n\tthat are no longer in the working tree.\n\nSo I would expect \"git add -A\" to do the same thing as \"git add -u\",\nplus handling added files.\n\nMaaartin, could you give an example showing where add -A goes wrong?\n"},{"id":"158368","messageId":"7vaak1ftin.fsf@alter.siamese.dyndns.org","threadId":"26102","inReplyTo":"loom.20101219T090500-396@post.gmane.org","subject":"Re: Commiting automatically (2)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-19T19:32:32Z","receivedAt":"2010-12-19T19:32:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Maaartin writes:\n\n> However, when I use my git-autocom script, those files get marked as deleted. \n> This is quite strange, especially because of them still existing. I'd strongly \n> prefer git-autocom to behave just like git commit (i.e., tracking the files).\n>\n> The relevant part of my script follows:\n>\n> export GIT_INDEX_FILE=.git/autocom.tmp\n> git add -A &&\n\nIf you really want \"just like commit\", then it would be more like \"make a\ncommit object out of the current index, and put that somewhere outside the\ncurrent branch\", and will not involve any \"git add\", no?\n\nA useful goal would be \"as if I said 'git add -u && git commit' from the\ncurrent state\" (alternatively, you could say s/-u/-A/).\n\nIf this autocom.tmp starts out empty, \"add\" will of course honor what you\nwrote in .gitignore hence would not add ignored files. You may have '*.o'\nin the ignore mechanism to exclude usual build products. Until you\nsomehow tell git that you care about a vendor-supplied binary blob file\n\"binblob1.o\" even though it has a name for usual ignored ones, you don't\nwant to get it tracked, and once you have done so with \"git add -f\", you\ndo want to get it tracked from that point. But your script cannot be\nclever enough to selectively say \"add -f\" for such a file.\n\nThe \"from the current state\" part of the sentence of your goal (clarified\nby the second paragraph above) fundamentally means you need to start from\nyour real index, so \"cp -p .git/index $TMP_INDEX\" is both appropriate and\ninevitable for your script.\n"},{"id":"158370","messageId":"20101219201736.GA12653@burratino","threadId":"26102","inReplyTo":"20101219183619.GB11955@burratino","subject":"Re: Commiting automatically (2)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-19T20:17:36Z","receivedAt":"2010-12-19T20:17:36Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n>> On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:\n\n>>> There's one more problem. My script doesn't recognize deleted files, since\n>>> git add -A\n>>> does nothing to them.\n[...]\n> Maaartin, could you give an example showing where add -A goes wrong?\n\nPlease ignore; looks like Taylor and Junio figured it out. (For\nanyone else who was confused like me: the files in question were\nremoved with the equivalent of\n\n\tgit rm --cached generated.c\n\nrather than\n\n\trm -f irrelevant.c\n\n.)\n"},{"id":"158384","messageId":"loom.20101220T060758-200@post.gmane.org","threadId":"26102","inReplyTo":"20101219183619.GB11955@burratino","subject":"Re: Commiting automatically (2)","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-12-20T05:12:57Z","receivedAt":"2010-12-20T05:12:57Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"Jonathan Nieder gmail.com> writes:\n> Hmm, the \"git add\" manual suggests it is the other way around:\n> \n> -A, --all\n> \tLike -u, but match against files in the working\n> \ttree in addition to the index. That means that it will find new\n> \tfiles as well as staging modified content and removing files\n> \tthat are no longer in the working tree.\n> \n> So I would expect \"git add -A\" to do the same thing as \"git add -u\",\n> plus handling added files.\n> \n> Maaartin, could you give an example showing where add -A goes wrong?\n\nI can't, since I was wrong. These commits have two parents (I'm not sure if this \nis a good idea), and that's why I saw no changes in the log. Actually, \"git add -\nA\" does everything I need, and with \"/bin/cp .git/index $GIT_INDEX_FILE\" \neverything seems to work. Sorry for the noise.\n"},{"id":"158385","messageId":"loom.20101220T062209-24@post.gmane.org","threadId":"26102","inReplyTo":"7vaak1ftin.fsf@alter.siamese.dyndns.org","subject":"Re: Commiting automatically (2)","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-12-20T05:46:47Z","receivedAt":"2010-12-20T05:46:47Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"Junio C Hamano pobox.com> writes:\n\n> Maaartin seznam.cz> writes:\n> \n> > However, when I use my git-autocom script, those files get marked as \ndeleted. \n> > This is quite strange, especially because of them still existing. I'd \nstrongly \n> > prefer git-autocom to behave just like git commit (i.e., tracking the \nfiles).\n> >\n> > The relevant part of my script follows:\n> >\n> > export GIT_INDEX_FILE=.git/autocom.tmp\n> > git add -A &&\n> \n> If you really want \"just like commit\", then it would be more like \"make a\n> commit object out of the current index, and put that somewhere outside the\n> current branch\", and will not involve any \"git add\", no?\n\nYou're right, I was using the wrong term, what I wanted was to take a SNAPSHOT \nof the current working dir (this is called \"commit\" in csv/svn but not in git, \nI know).\n\n> A useful goal would be \"as if I said 'git add -u && git commit' from the\n> current state\" (alternatively, you could say s/-u/-A/).\n\nYes, I wonder why it wasn't already implemented. I do something like\nmake all; git snapshot; send_the_executable_to_the_customer\nwhich is IMHO needed quite often.\n\n> If this autocom.tmp starts out empty, \"add\" will of course honor what you\n> wrote in .gitignore hence would not add ignored files. You may have '*.o'\n> in the ignore mechanism to exclude usual build products. Until you\n> somehow tell git that you care about a vendor-supplied binary blob file\n> \"binblob1.o\" even though it has a name for usual ignored ones, you don't\n> want to get it tracked, and once you have done so with \"git add -f\", you\n> do want to get it tracked from that point. But your script cannot be\n> clever enough to selectively say \"add -f\" for such a file.\n> \n> The \"from the current state\" part of the sentence of your goal (clarified\n> by the second paragraph above) fundamentally means you need to start from\n> your real index, so \"cp -p .git/index $TMP_INDEX\" is both appropriate and\n> inevitable for your script.\n\nNow it's clear, thank you for the explanation.\n"},{"id":"158387","messageId":"20101220073312.GA23482@nibiru.local","threadId":"26102","inReplyTo":"loom.20101220T062209-24@post.gmane.org","subject":"Re: Commiting automatically (2)","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-12-20T07:33:12Z","receivedAt":"2010-12-20T07:33:12Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Maaartin wrote:\n\n> Yes, I wonder why it wasn't already implemented. I do something like\n> make all; git snapshot; send_the_executable_to_the_customer\n> which is IMHO needed quite often.\n\nPerhaps it's wise to just use a separate repository on the same \nrepository. Maybe make it more convenient using some little\nshell functions. I'm also using that for backup purposes, where\nthe repo lies outside the to-be-backed-up tree.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"158429","messageId":"loom.20101221T092948-59@post.gmane.org","threadId":"26102","inReplyTo":"20101220073312.GA23482@nibiru.local","subject":"Re: Commiting automatically (2)","fromName":"Maaartin","fromEmail":"grajcar1@seznam.cz","sentAt":"2010-12-21T08:36:30Z","receivedAt":"2010-12-21T08:36:30Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"Enrico Weigelt metux.de> writes:\n\n> * Maaartin seznam.cz> wrote:\n> \n> > Yes, I wonder why it wasn't already implemented. I do something like\n> > make all; git snapshot; send_the_executable_to_the_customer\n> > which is IMHO needed quite often.\n> \n> Perhaps it's wise to just use a separate repository on the same \n> repository. Maybe make it more convenient using some little\n> shell functions. I'm also using that for backup purposes, where\n> the repo lies outside the to-be-backed-up tree.\n\nI considered using a separate repository, too, but having \"all in one\" feels \nsomehow better. It allows me to push everything to a single remote repo and \ncompare the snapshots to ordinal commits, etc.\n\nI let the snapshot point to the current head, which is where I get a problem now:\ngit show-ref HEAD\nreturns nothing,\ngit show-ref --head\nreturns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD \nreference? I'm using git version 1.7.2.3 on cygwin.\n"},{"id":"158433","messageId":"m34oa7l1hq.fsf@localhost.localdomain","threadId":"26102","inReplyTo":"loom.20101221T092948-59@post.gmane.org","subject":"Re: Commiting automatically (2)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-21T13:06:39Z","receivedAt":"2010-12-21T13:06:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Please try to not cull Cc list (use 'reply via email', if possible)\n\nMaaartin writes:\n\n> I let the snapshot point to the current head, which is where I get a problem now:\n>\n> git show-ref HEAD\n>\n> returns nothing,\n>\n> git show-ref --head\n>\n> returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD \n> reference? I'm using git version 1.7.2.3 on cygwin.\n\nYou can use `git rev-parse --verify HEAD`, for example. Generally\nscripted commands (including those in contrib/examples/) are good\nsources of inspiration. Or if you want symbolic name, you can use\n`git symbolic-ref HEAD` or `git rev-parse --symbolic-full-name HEAD`.\n\nAs for `git show-ref HEAD` - git-show-ref uses its own way of pattern\nmatching; in new enough version of git-show-ref manpage you can read\nthat:\n\n ...::\n\n Show references matching one or more patterns. Patterns are matched from\n the end of the full name, and only complete parts are matched, e.g.\n 'master' matches 'refs/heads/master', 'refs/remotes/origin/master',\n 'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor\n 'refs/remotes/master/jedi'.\n\nSo `git show-ref HEAD` would match 'refs/.../HEAD`, e.g. `refs/remotes/origin/HEAD`,\nbut not `HEAD` which is outside `refs/`.\n\nI tripped over strange git-show-ref semantic too.\n\nP.S. there is also git-for-each-ref.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"158619","messageId":"201012271304.03915.jnareb@gmail.com","threadId":"26102","inReplyTo":"4D1190A6.4070201@seznam.cz","subject":"Re: Commiting automatically (2)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-27T12:04:02Z","receivedAt":"2010-12-27T12:04:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 22 Dec 2010, Maaartin-1 wrote:\n> On 10-12-21 14:06, Jakub Narebski wrote:\n>>\n>> Please try to not cull Cc list (use 'reply via email', if possible)\n> \n> I don't know what \"cull\" means and\n> http://dictionary.reference.com/browse/cull\n> doesn't help me at all. Could you explain?\n\nhttp://en.wiktionary.org/wiki/cull\n\n to cull\n [...]\n 3. To select animals from a group and then kill them in order to\n reduce the numbers of the group in a controlled manner.\n\nIn the context (\"to cull Cc list\") it means removing entries from Cc\nlist (courtesy copy, copy-to), i.e. not replying to all people\nparticipating in given (sub)thread.\n\n>> Maaartin writes:\n>> \n>>> I let the snapshot point to the current head, which is where I get a problem now:\n>>>\n>>> git show-ref HEAD\n>>>\n>>> returns nothing,\n>>>\n>>> git show-ref --head\n>>>\n>>> returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD \n>>> reference? I'm using git version 1.7.2.3 on cygwin.\n[...]\n>> As for `git show-ref HEAD` - git-show-ref uses its own way of pattern\n>> matching; in new enough version of git-show-ref manpage you can read\n>> that:\n>> \n>> ...::\n>> \n>> Show references matching one or more patterns. Patterns are matched from\n>> the end of the full name, and only complete parts are matched, e.g.\n>> 'master' matches 'refs/heads/master', 'refs/remotes/origin/master',\n>> 'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor\n>> 'refs/remotes/master/jedi'.\n>> \n>> So `git show-ref HEAD` would match 'refs/.../HEAD`, e.g. `refs/remotes/origin/HEAD`,\n>> but not `HEAD` which is outside `refs/`.\n> \n> IMHO, it's quite broken. Alone it would be fine, but should really\n> git-show-ref behave that different from git-symbolic-ref?\n\ngit-symbolic-ref is about querying and manipulating _single_ symbolic\nreference, using fully qualified branch names (ref names).\n\ngit-show-ref is about querying multiple refs; I think the design goal\nbehind its strange pattern matching semantic is to make it easy to get\nall refs with the same short name.\n\n> Moreover, git-show-ref --head shows all branches and tags, this can't be\n> right, can it? According to your above explanation, getting HEAD using a\n> pattern is impossible, so I'd say that's what is \"--head\" good for.\n> \n> Moreover, \"git-show-ref --heads\" shows less than \"git-show-ref --head\",\n> despite the plural.\n\n\"git show-ref --head\" is strange in that it doesn't play well\nwith '--heads' and '--tags' and ''.\n\nI think it is a bit of misdesign, but I don't know how it should be\nfixed; current output of \"git show-ref --head\" has to be kept because\nof backward compatibility - git-show-ref is plumbing.\n\n>> I tripped over strange git-show-ref semantic too.\n>> \n>> P.S. there is also git-for-each-ref.\n\nI don't know why there is git-show-ref when we have git-for-each-ref\nfor scripting; I guess they were added nearly at the same time...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"158825","messageId":"4D211AA4.4050108@seznam.cz","threadId":"26102","inReplyTo":"201012271304.03915.jnareb@gmail.com","subject":"Re: Commiting automatically (2)","fromName":"Maaartin-1","fromEmail":"grajcar1@seznam.cz","sentAt":"2011-01-03T00:39:00Z","receivedAt":"2011-01-03T00:39:00Z","isPatch":false,"sender":{"key":"grajcar1@seznam.cz","avatar":null},"body":"On 10-12-27 13:04, Jakub Narebski wrote:\n> On Wed, 22 Dec 2010, Maaartin-1 wrote:\n>> On 10-12-21 14:06, Jakub Narebski wrote:\n>>>\n>>> Please try to not cull Cc list (use 'reply via email', if possible)\n>>\n>> I don't know what \"cull\" means and\n>> http://dictionary.reference.com/browse/cull\n>> doesn't help me at all. Could you explain?\n> \n> http://en.wiktionary.org/wiki/cull\n> \n> to cull\n> [...]\n> 3. To select animals from a group and then kill them in order to\n> reduce the numbers of the group in a controlled manner.\n> \n> In the context (\"to cull Cc list\") it means removing entries from Cc\n> list (courtesy copy, copy-to), i.e. not replying to all people\n> participating in given (sub)thread.\n\nI was using the gmane page, which did it. Next time I replied using\nemail, but forgot to add the CC. There are things I hate more than\nmailing lists, but they're fairly rare.\n\n>> IMHO, it's quite broken. Alone it would be fine, but should really\n>> git-show-ref behave that different from git-symbolic-ref?\n> \n> git-symbolic-ref is about querying and manipulating _single_ symbolic\n> reference, using fully qualified branch names (ref names).\n\nOK, this is a sort of acceptable.\n\n> git-show-ref is about querying multiple refs; I think the design goal\n> behind its strange pattern matching semantic is to make it easy to get\n> all refs with the same short name.\n\nOK, the strange pattern matching is not that bad.\n\n>> Moreover, git-show-ref --head shows all branches and tags, this can't be\n>> right, can it? According to your above explanation, getting HEAD using a\n>> pattern is impossible, so I'd say that's what is \"--head\" good for.\n>>\n>> Moreover, \"git-show-ref --heads\" shows less than \"git-show-ref --head\",\n>> despite the plural.\n> \n> \"git show-ref --head\" is strange in that it doesn't play well\n> with '--heads' and '--tags' and ''.\n> \n> I think it is a bit of misdesign, but I don't know how it should be\n> fixed; current output of \"git show-ref --head\" has to be kept because\n> of backward compatibility - git-show-ref is plumbing.\n\nI wonder what\ngit show-ref --head\nreally does. It seems to output everything, is this the expected (albeit\nstrange) behavior? Maybe, I know now, s. below.\n\nFor sure, either the doc is completely wrong or the implementation. I\nhope I understand \"Show the HEAD reference\" correctly as showing the\nHEAD reference, don't I? So it must show a single reference (singular).\nInstead I get all tags and all heads. Could anybody either fix the doc\nor convince me that the many lines I'm seeing are a single one?\n\nShouldn't there be an option *really* doing what --head is expected and\ndocumented to do? I mean something like\ngit show-ref --head --yes-I-really-mean-the-head\nwith the output consisting of a single line like\n4ba2b422cf3cc229d894bb31c429c0c588de85c0 HEAD\nMaybe it could be called --head-only.\n\nIt could help a lot to add the word \"additionally\" to the doc like\n--head\nAdditionally show the HEAD reference.\n\n>>> I tripped over strange git-show-ref semantic too.\n>>>\n>>> P.S. there is also git-for-each-ref.\n> \n> I don't know why there is git-show-ref when we have git-for-each-ref\n> for scripting; I guess they were added nearly at the same time...\n\nI guess, I can get the single line I wanted using\ngit for-each-ref $(git symbolic-ref HEAD)\nright?\n"},{"id":"158849","messageId":"201101031834.09115.jnareb@gmail.com","threadId":"26102","inReplyTo":"4D211AA4.4050108@seznam.cz","subject":"Re: Commiting automatically (2)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-01-03T17:34:08Z","receivedAt":"2011-01-03T17:34:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 3 Jan 2011, Maaartin-1 wrote:\n> On 10-12-27 13:04, Jakub Narebski wrote:\n>> On Wed, 22 Dec 2010, Maaartin-1 wrote:\n\n>>> Moreover, git-show-ref --head shows all branches and tags, this can't be\n>>> right, can it? According to your above explanation, getting HEAD using a\n>>> pattern is impossible, so I'd say that's what is \"--head\" good for.\n>>>\n>>> Moreover, \"git-show-ref --heads\" shows less than \"git-show-ref --head\",\n>>> despite the plural.\n>> \n>> \"git show-ref --head\" is strange in that it doesn't play well\n>> with '--heads' and '--tags' and ''.\n>> \n>> I think it is a bit of misdesign, but I don't know how it should be\n>> fixed; current output of \"git show-ref --head\" has to be kept because\n>> of backward compatibility - git-show-ref is plumbing.\n> \n> I wonder what\n> git show-ref --head\n> really does. It seems to output everything, is this the expected (albeit\n> strange) behavior? Maybe, I know now, s. below.\n> \n> For sure, either the doc is completely wrong or the implementation. I\n> hope I understand \"Show the HEAD reference\" correctly as showing the\n> HEAD reference, don't I? So it must show a single reference (singular).\n> Instead I get all tags and all heads. Could anybody either fix the doc\n> or convince me that the many lines I'm seeing are a single one?\n\nWell, it might be that *both* documentation and implementation are wrong.\n\n> \n> Shouldn't there be an option *really* doing what --head is expected and\n> documented to do? I mean something like\n> git show-ref --head --yes-I-really-mean-the-head\n> with the output consisting of a single line like\n> 4ba2b422cf3cc229d894bb31c429c0c588de85c0 HEAD\n> Maybe it could be called --head-only.\n> \n> It could help a lot to add the word \"additionally\" to the doc like\n> --head\n> Additionally show the HEAD reference.\n\nWell, actually it doesn't do that. If '--head' is *alone* ref selector\n(e.g. \"git show-ref --head\") it shows HEAD reference in addition to all\nother refs (e.g. what \"git show-ref\" would show). But it doesn't seem\nto work in described way when combined with any of ref specifiers; neither\n\"git show-ref --head --heads\" not \"git show-ref --head master\" work as \none would expect.\n\n> \n>>>> I tripped over strange git-show-ref semantic too.\n>>>>\n>>>> P.S. there is also git-for-each-ref.\n>> \n>> I don't know why there is git-show-ref when we have git-for-each-ref\n>> for scripting; I guess they were added nearly at the same time...\n> \n> I guess, I can get the single line I wanted using\n> git for-each-ref $(git symbolic-ref HEAD)\n> right?\n\nWell, both git-show-ref and git-for-each-ref are meant for checking or\nviewing multiple refs at once. If you are working with a single ref,\nthen git-rev-parse (e.g. \"git rev-parse --symboolic HEAD\" or \n\"git rev-parse --symbolic-full-name HEAD\") or git-symbolic-ref would be\na better choice IMHO.\n\n-- \nJakub Narebski\nPoland\n"}]}