Re: Passing rev-list options in git-filter-branch broken

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 27, 2014, 18:31 UTC
Message-ID: <xmqq1tua2oi5.fsf@gitster.dls.corp.google.com>
In-Reply-To: <987cd4ccd2b86a840b900a25e0edf0f9@tribut.de>

Felix Eckhofer <felix@tribut.de> writes:

Show 10 quoted lines

> When trying to rewrite svn revisions in commit messages to
> corresponding git commit hashes, I came across the following problem
> (using git 1.9.1):
>
>   $ git filter-branch --msg-filter svnrev2git.py -- --date-order --all
>   fatal: options not supported in --stdin mode
>   Could not get the commits
>
> This seems to have been caused by 3361a548db. After reverting this
> commit, using --date-order appears to work again.

Hmph, unfortunate.

3361a548 (Allow git-filter-branch to process large repositories with lots of branches., 2013-09-10) has this change:

 
    -rev_args=$(git rev-parse --revs-only "$@")
    +git rev-parse --revs-only "$@" >../parse

and then later feeds ../parse from the standard input of rev-list.

The --revs-only option, because --date-order *is* a rev-list related argument, is emitted by the above rev-parse, along with the tip of refs (which come from --all). But --stdin mode of rev-list is meant to receive *only* revisions, not options. When it gets to the point to accept the list of tips to start traversing from, it is too late to give it an option.

Changing the above to something like:

	git rev-parse --revs-only --no-flags "$@" >../parse

would be a better workaround that would not break repositories with large number of references, but it obviously will lose --date-order option (why would it be even necessary, though? I suspect that forcing the date-order will make the resulting pack a lot worse by robbing the data stream of locality).