Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision

On Mon, Aug 22, 2011 at 09:54:47AM -0700, Sverre Rabbelier wrote:

Do you agree that this is expected behavior?

$ git init test
Initialized empty Git repository in /home/sverre/code/test/.git/
$ cd test/
$ echo content >> foo
sverre@laptop-sverre:~/code/test
$ git add foo
$ git commit -m first
[master (root-commit) 821176f] first
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 foo
$ echo content >> foo
$ git commit -am second
[master 1934282] second
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git branch other
$ git fast-export ^master other
reset refs/heads/other
from 1934282469e3a83a5ef827fd31e074cfb4f3eadf

Yeah, that seems reasonable to me.

Because in current git.git, this doesn't work (the above is generated
using a git that has the patch series Dscho and I sent out). Current
git will instead do the following:

$ git fast-export ^master other
reset refs/heads/other
from :0

The 'from :0' here is obviously a bug (which is fixed by our patch series).

Yep, the current behavior is definitely wrong. But I thought your
question was about accidentally mentioning refs/heads/master, which this
doesn't do (nor should it).

I just read through the remote-helper threads from early June, and the
only mention of triggering that is when you actually have a rename
(i.e., your "refs/heads/foo" becomes remote's "refs/heads/bar", but we
mention "refs/heads/foo" in the export stream). I was thinking there was
another case, but I couldn't find mention of it.

You might wonder, 'why would anyone do that', well, for example, they
might be using marks:

$ git fast-export --export-marks=marksfile  master > /dev/null
$ git fast-export --import-marks=marksfile  other
reset refs/heads/other
from :4

Again, the above is generated with my patched git, current git.git
simply outputs nothing.

$ git fast-export --import-marks=marksfile other

Yeah, the behavior of your patch looks fine to me. I thought the point
in contention was that having export understand refspecs would fix a lot
of _other_ cases, too.

-Peff