Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> Of course, but how do you implement that? That's mixing refspecs and
> revlist arguments, which AFAIK don't mix:
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*].
> % git fast-export ^next:new-next master:new-master --not
> refs/tags/*:refs/tags/backup/*
I thought you stopped mentioning the bottom of the range
(e.g. ^next) in the output from export stream at around 49266e8a11cf
(fast-export: don't handle uninteresting refs, 2012-11-28).
What does ^next:new-next (or mapping after "--not" in general) even
mean? They would not make sense, would they?
So I would imagine you would be spelling that as:
git fast-export master:new-master --not next refs/tags/*
or something, no?
[Footnote]
*1* Of course, unlike "git push", but similar to "git bundle",
export does not know who the "receiving side" is and what they
have, so in addition to the positives, you would need to tell
the command where the bottoms of the range you are exporting
are, so there needs to be some difference between the way "git
push" and export/bundle specify the ranges.
But that does not affect what should happen on the positive end
of the ranges, which both "git push" and export/bundle need to
specify anyway.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html