Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision
- From
Sverre Rabbelier <srabbelier@gmail.com>
- Date
- Aug 21, 2011, 22:29 UTC
- Message-ID
- <CAGdFq_iiTt8F+kPXwZZT3fAKwZLCpPr7BOYtistxvv6s52Q5nQ@mail.gmail.com>
- In-Reply-To
- <20110817231922.GA28966@sigill.intra.peff.net>
Heya,
On Wed, Aug 17, 2011 at 16:19, Jeff King <peff@peff.net> wrote:
Show 20 quoted lines
> On Wed, Aug 17, 2011 at 03:30:14PM -0700, Junio C Hamano wrote: > >> You can think of "fast-export" an off-line "push" command [*1*]; instead >> of giving a random commit object, e.g. "git fast-export HEAD~1", that can >> not be used as a ref, you can use the refspec notation to tell where the >> result should go, e.g. "git fast-export HEAD~1:refs/heads/a-bit-older", >> from the command line of fast-export. >> >> I suspect that also may clarify what Sverre was trying to do in his recent >> series. The root cause of both this and the issue Sverre wanted to fix is >> the design mistake of fast-export that tries to reuse the notation of >> object range specification for a different purpose of telling which "ref" >> to update, I think. > > Yes, this was the conclusion I came to when I looked at this a month or > so ago. You really need to give fast-export a mapping of objects to > refnames, and it should output ref names _only_ for the mapping. That > would handle this "not a ref" case, but would also let you push > "refs/heads/foo" when it is equivalent to "refs/heads/master", without > fast-export mentioning "refs/heads/master" at all.
Does this bring any new insights into how the problem I was pointing out (trying to push next if master points at the same commit does nothing) could/should be solved?
-- Cheers, Sverre Rabbelier