# BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline 3 messages from 2012-02-02 to 2012-02-04. Participants: Mark Jason Dominus, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/29530 ## Mark Jason Dominus, 2012-02-02 22:09 Subject: BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline Message-ID: <15093.1328220568@plover.com> URL: https://gitlist.dev/e/15093.1328220568%40plover.com ``` Here I use git symbolic-ref to update HEAD with a ref whose name contains trailing newlines: $ git symbolic-ref -m "this message does not appear" HEAD 'refs/heads/master > > > ' The newlines are inserted into .git/HEAD, but are innocuous, because other git commands ignore them. The bug is that the -m option is completely ignored: $ git reflog HEAD | grep 'message does not appear' $ If trailing newlines are considered acceptable, the -m option should be honored. If not, an error message should be printed and thecommand should exit with a nonzero exit status. I will prepare a patch if you will say which behavior would be preferable. Mark Jason Dominus mjd@plover.com ``` ## Jeff King, 2012-02-02 22:32 Subject: Re: BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline Message-ID: <20120202223250.GA28618@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120202223250.GA28618%40sigill.intra.peff.net In-Reply-To: <15093.1328220568@plover.com> ``` On Thu, Feb 02, 2012 at 05:09:28PM -0500, Mark Jason Dominus wrote: > Here I use git symbolic-ref to update HEAD with a ref whose name > contains trailing newlines: > > $ git symbolic-ref -m "this message does not appear" HEAD 'refs/heads/master > > > > > > ' > > The newlines are inserted into .git/HEAD, but are innocuous, because > other git commands ignore them. The bug is that the -m option is > completely ignored: > > $ git reflog HEAD | grep 'message does not appear' Is it trailing newlines, or is simply pointing to a ref that does not exist? Because I believe we do not create a HEAD reflog entry in that case, as we would have nothing to write in the "new sha1" field. I guess we could write an entry that it went to "0{40}", though I'm not sure how things like "git reflog show" would handle that. The logic is at the very end of refs.c:create_symref if you want to experiment. As far as the newlines go, I'm surprised we don't reject that. We should probably run check_refname_format on the proposed contents of the symbolic-ref. -Peff ``` ## Junio C Hamano, 2012-02-04 08:11 Subject: Re: BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline Message-ID: <7vliojhvc5.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vliojhvc5.fsf%40alter.siamese.dyndns.org In-Reply-To: <20120202223250.GA28618@sigill.intra.peff.net> ``` Jeff King writes: > As far as the newlines go, I'm surprised we don't reject that. We should > probably run check_refname_format on the proposed contents of the > symbolic-ref. Historically the plumbing commands were deliberately left loose on the input side in the beginning, for the explicit purpose of allowing us to more easily experiment, tweaking the low level data structures and file formats. It's like being able to use a disk editor to experiment with the filesystem. You feed good data, and you will see expected results. You perform something other parts of the system does not yet expect, and you find places that need further adjusting if you were to extend the format you are futzing with the "bare metal manipulation tool" ;-) It is not surprising at all that we haven't tightened the ones that normal users would not use, and symbolic-ref is one of them. You needed to write scripts that would use symbolic-ref yourself more often in the early days of Git, but back in those days, (1) people who wrote scripts with plumbing commands tended to know what they were doing and (2) we did not have that much interaction between subsystems, like reflogs vs symrefs. Now, those days are long gone, and we are done with experiments pretty much. We should tighten remaining holes as we find them. ```