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

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

[Mark Jason Dominus]

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

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

[Jeff King]

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> 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.