BUG 1.7.9: git-update-ref strange behavior with ref with trailing newline

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

On Thu, Feb 02, 2012 at 05:09:28PM -0500, Mark Jason Dominus wrote:

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

Jeff King <peff@peff.net> writes:

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.