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