On Thu, May 9, 2013 at 5:32 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>> +test_expect_success 'use refspec' '
>> + git fast-export --refspec refs/heads/master:refs/heads/foobar master |
>> + grep "^commit " | sort | uniq > actual &&
> You do not need backslash after the pipe symbol at the end of line;
> the shell knows you haven't finished speaking at that point.
> The usual "pipe hides the error status of upstream commands" applies
> here. The command may die after writing enough to fill the pipe
> buffer and showing the lines that begin with "commit".
> Also it makes it harder to debug the test when something goes wrong.
> By the way, don't you find that something does not feel quite right
> with this command line?
> git fast-export --refspec=refs/heads/master:refs/heads/foobar master
> Why do we even have to say "master" at the end, when the other
> option makes it clear that we are shipping "master" out?
> Without thinking ramifications through, my gut feeling is that it
> would feel more natural if we took:
> git fast-export master:foobar
> to mean the same thing (which is what happens to the users of "git
> push"). Is there a case where you have some ref on the left hand
> side of the --refspec but you do not push out the history leading to
> With such an update, this part of the test would of course look
> git fast-export master:foobar >actual.dump &&
> grep "^commit " actual.dump |
> sort -u >actual &&
> and we do not need a new option. Just a new extension to express
> what gets pushed out.
> But of course I may be missing some cases why there need to be a
> separate option.
Of course, but how do you implement that? That's mixing refspecs and
revlist arguments, which AFAIK don't mix:
% git fast-export ^next:new-next master:new-master --not
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