{"thread":{"id":"29530","subject":"BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline","startedAt":"2012-02-02T22:09:28Z","lastAt":"2012-02-04T08:11:06Z","messageCount":3,"participants":["Mark Jason Dominus","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183673","messageId":"15093.1328220568@plover.com","threadId":"29530","inReplyTo":null,"subject":"BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline","fromName":"Mark Jason Dominus","fromEmail":"mjd@plover.com","sentAt":"2012-02-02T22:09:28Z","receivedAt":"2012-02-02T22:09:28Z","isPatch":false,"sender":{"key":"mjd@plover.com","avatar":"https://gravatar.com/avatar/a874d23a21a54fc9c5e9d91614219a150bd89c90c1cb0ef970e689f5b88c098b?d=mp&s=160"},"body":"\nHere I use git symbolic-ref to update HEAD with a ref whose name\ncontains trailing newlines:\n\n        $ git symbolic-ref -m \"this message does not appear\" HEAD 'refs/heads/master\n        >\n        >\n        > '\n\nThe newlines are inserted into .git/HEAD, but are innocuous, because\nother git commands ignore them.  The bug is that the -m option is\ncompletely ignored:\n\n        $ git reflog HEAD | grep 'message does not appear'\n        $\n\nIf trailing newlines are considered acceptable, the -m option should\nbe honored.  If not, an error message should be printed and thecommand\nshould exit with a nonzero exit status.\n\nI will prepare a patch if you will say which behavior would be\npreferable.\n\nMark Jason Dominus \t  \t\t\t                 mjd@plover.com\n"},{"id":"183676","messageId":"20120202223250.GA28618@sigill.intra.peff.net","threadId":"29530","inReplyTo":"15093.1328220568@plover.com","subject":"Re: BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-02T22:32:50Z","receivedAt":"2012-02-02T22:32:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 02, 2012 at 05:09:28PM -0500, Mark Jason Dominus wrote:\n\n> Here I use git symbolic-ref to update HEAD with a ref whose name\n> contains trailing newlines:\n> \n>         $ git symbolic-ref -m \"this message does not appear\" HEAD 'refs/heads/master\n>         >\n>         >\n>         > '\n> \n> The newlines are inserted into .git/HEAD, but are innocuous, because\n> other git commands ignore them.  The bug is that the -m option is\n> completely ignored:\n> \n>         $ git reflog HEAD | grep 'message does not appear'\n\nIs it trailing newlines, or is simply pointing to a ref that does not\nexist? Because I believe we do not create a HEAD reflog entry in that\ncase, as we would have nothing to write in the \"new sha1\" field. I guess\nwe could write an entry that it went to \"0{40}\", though I'm not sure how\nthings like \"git reflog show\" would handle that. The logic is at the\nvery end of refs.c:create_symref if you want to experiment.\n\nAs far as the newlines go, I'm surprised we don't reject that. We should\nprobably run check_refname_format on the proposed contents of the\nsymbolic-ref.\n\n-Peff\n"},{"id":"183816","messageId":"7vliojhvc5.fsf@alter.siamese.dyndns.org","threadId":"29530","inReplyTo":"20120202223250.GA28618@sigill.intra.peff.net","subject":"Re: BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-04T08:11:06Z","receivedAt":"2012-02-04T08:11:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> As far as the newlines go, I'm surprised we don't reject that.  We should\n> probably run check_refname_format on the proposed contents of the\n> symbolic-ref.\n\nHistorically the plumbing commands were deliberately left loose on the\ninput side in the beginning, for the explicit purpose of allowing us to\nmore easily experiment, tweaking the low level data structures and file\nformats.  It's like being able to use a disk editor to experiment with the\nfilesystem.  You feed good data, and you will see expected results.  You\nperform something other parts of the system does not yet expect, and you\nfind places that need further adjusting if you were to extend the format\nyou are futzing with the \"bare metal manipulation tool\" ;-)\n\nIt is not surprising at all that we haven't tightened the ones that normal\nusers would not use, and symbolic-ref is one of them.  You needed to write\nscripts that would use symbolic-ref yourself more often in the early days\nof Git, but back in those days, (1) people who wrote scripts with plumbing\ncommands tended to know what they were doing and (2) we did not have that\nmuch interaction between subsystems, like reflogs vs symrefs.\n\nNow, those days are long gone, and we are done with experiments pretty\nmuch.  We should tighten remaining holes as we find them.\n"}]}