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

Felix Eckhofer [off-list ref] writes:

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).

Junio,

thanks for your reply and your patch.

Am 27.06.2014 20:31, schrieb Junio C Hamano:

[...]
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).

We're migrating some svn repositories to git. The use case is to replace 
mentions of svn revisions in commit messages by the corresponding commit 
hash. Therefore, the commits must be ordered by svn revision number, 
which is not guaranteed for commits on different branches with 
--topo-order.


Regards
felix