Junio C Hamano <gits...@pobox.com> writes:

> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> On Thu, May 9, 2013 at 6:23 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> Simple.  You treat everything as refspecs and form revision ranges
>>> out of them.  Note that that is exactly the reason why "git push"
>>> can take "master" as a short-hand for "master:master" [*1*].
>> ...
>>> So I would imagine you would be spelling that as:
>>>     git fast-export master:new-master --not next refs/tags/*
>>> or something, no?
>> rev-list doesn't accept 'refs/tags/*'.
> I think you misunderstood.  That is meant to illustrate what your
> end users feed "fast-export". "fast-export" in turn expands that
> into a revision range, which needs to happen anyway when it strips
> :new-master from the positive end of the range to make the range
> into
>       master ^next ^refs/tags/v1.0 ^refs/tags/v1.1 ...

A few corrections and a related random thought.

 * The original --not "refs/tags/*:refs/tags/backup/*" fooled me. As
   my primary point was that an earlier change to fast-export made
   the uninteresting bottom not appear as reset in the output
   stream, I omitted everything after colon without much thought.

   If the current fast-export does not let you say "refs/tags/*" to
   export all the tags, we do not have to extend it to allow it to
   do so.

 * On the other hand, "git log 'fc/*'" might be a handy thing for
   any command that wants to have multiple starting points for
   revision traversal, so in principle I would not mind such an
   enhancement to rev-list machinery.

   But that does not have to be part of this series.

 * I alluded to the similarity between fast-export and bundle,
   meaning to hint that "git bundle" might also benefit from being
   able to say "record these refs under different name", but after
   thinking about it a bit more, I think it is unnecessary.

   The user of the bundle's output, either fetch or clone, can use
   the usual refspec mapping to use the data in any way it wants.
   If the bundle says refs/heads/master is at one commit, the _user_
   of that bundle can decide to map it to refs/remotes/origin/master
   (or refs/heads/origin, for that matter).

   It is a very powerful concept that we can generate data once,
   cast it in stone, and delay the decision on _how_ it is used
   until the last minute, much better than mapping at export time.
   So bundle does not need a similar refspec mechanism to map what
   it exports.  I haven't thought things through to see if the same
   logic applies to fast-export output (if so, it would mean it is
   better to allow the consumer of the stream take the refspec
   parameter and map the tips it finds in its input), though.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to