{"thread":{"id":"37010","subject":"Passing rev-list options in git-filter-branch broken","startedAt":"2014-06-27T16:26:04Z","lastAt":"2014-06-29T14:00:49Z","messageCount":4,"participants":["Felix Eckhofer","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"245077","messageId":"987cd4ccd2b86a840b900a25e0edf0f9@tribut.de","threadId":"37010","inReplyTo":null,"subject":"Passing rev-list options in git-filter-branch broken","fromName":"Felix Eckhofer","fromEmail":"felix@tribut.de","sentAt":"2014-06-27T16:26:04Z","receivedAt":"2014-06-27T16:26:04Z","isPatch":false,"sender":{"key":"felix@tribut.de","avatar":null},"body":"Hey.\n\nWhen trying to rewrite svn revisions in commit messages to corresponding \ngit commit hashes, I came across the following problem (using git \n1.9.1):\n\n   $ git filter-branch --msg-filter svnrev2git.py -- --date-order --all\n   fatal: options not supported in --stdin mode\n   Could not get the commits\n\nThis seems to have been caused by 3361a548db. After reverting this \ncommit, using --date-order appears to work again.\n\n\nRegards\nfelix\n"},{"id":"245086","messageId":"xmqq1tua2oi5.fsf@gitster.dls.corp.google.com","threadId":"37010","inReplyTo":"987cd4ccd2b86a840b900a25e0edf0f9@tribut.de","subject":"Re: Passing rev-list options in git-filter-branch broken","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-27T18:31:13Z","receivedAt":"2014-06-27T18:31:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felix Eckhofer <felix@tribut.de> writes:\n\n> When trying to rewrite svn revisions in commit messages to\n> corresponding git commit hashes, I came across the following problem\n> (using git 1.9.1):\n>\n>   $ git filter-branch --msg-filter svnrev2git.py -- --date-order --all\n>   fatal: options not supported in --stdin mode\n>   Could not get the commits\n>\n> This seems to have been caused by 3361a548db. After reverting this\n> commit, using --date-order appears to work again.\n\nHmph, unfortunate.\n\n3361a548 (Allow git-filter-branch to process large repositories with\nlots of branches., 2013-09-10) has this change:\n\n \n    -rev_args=$(git rev-parse --revs-only \"$@\")\n    +git rev-parse --revs-only \"$@\" >../parse\n\nand then later feeds ../parse from the standard input of rev-list.\n\nThe --revs-only option, because --date-order *is* a rev-list related\nargument, is emitted by the above rev-parse, along with the tip of\nrefs (which come from --all).  But --stdin mode of rev-list is meant\nto receive *only* revisions, not options.  When it gets to the point\nto accept the list of tips to start traversing from, it is too late\nto give it an option.\n\nChanging the above to something like:\n\n\tgit rev-parse --revs-only --no-flags \"$@\" >../parse\n\nwould be a better workaround that would not break repositories with\nlarge number of references, but it obviously will lose --date-order\noption (why would it be even necessary, though?  I suspect that\nforcing the date-order will make the resulting pack a lot worse by\nrobbing the data stream of locality).\n"},{"id":"245102","messageId":"xmqq4mz60zb0.fsf@gitster.dls.corp.google.com","threadId":"37010","inReplyTo":"xmqq1tua2oi5.fsf@gitster.dls.corp.google.com","subject":"Re: Passing rev-list options in git-filter-branch broken","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-27T22:20:51Z","receivedAt":"2014-06-27T22:20:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Felix Eckhofer <felix@tribut.de> writes:\n>\n>> This seems to have been caused by 3361a548db. After reverting this\n>> commit, using --date-order appears to work again.\n>\n> Hmph, unfortunate.\n>\n> 3361a548 (Allow git-filter-branch to process large repositories with\n> lots of branches., 2013-09-10) has this change:\n>\n>  \n>     -rev_args=$(git rev-parse --revs-only \"$@\")\n>     +git rev-parse --revs-only \"$@\" >../parse\n>\n> and then later feeds ../parse from the standard input of rev-list.\n>\n> The --revs-only option, because --date-order *is* a rev-list related\n> argument, is emitted by the above rev-parse, along with the tip of\n> refs (which come from --all).  But --stdin mode of rev-list is meant\n> to receive *only* revisions, not options.  When it gets to the point\n> to accept the list of tips to start traversing from, it is too late\n> to give it an option.\n>\n> Changing the above to something like:\n>\n> \tgit rev-parse --revs-only --no-flags \"$@\" >../parse\n>\n> would be a better workaround that would not break repositories with\n> large number of references, but it obviously will lose --date-order\n> option (why would it be even necessary, though?  I suspect that\n> forcing the date-order will make the resulting pack a lot worse by\n> robbing the data stream of locality).\n\nAs the original \"../parse\" file will have mixture of revs (i.e. the\nobject names) and whatever rev-list options (e.g. \"--date-order\")\nyou gave from the command line, here is a band-aid to sift them into\ntwo, to be applied on top of 3361a548 (Allow git-filter-branch to\nprocess large repositories with lots of branches., 2013-09-10).\n\nI wish there was a way to tell rev-parse \"give us only flags\nrelevant to rev-list, don't include revs in the output\", but I do\nnot think there was ever any such option (we can get revs without\nany flags with --no-flags, though).\n\n\n git-filter-branch.sh | 7 +++++--\n 1 file changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex ca3d539..ed55c01 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -255,7 +255,9 @@ else\n \tremap_to_ancestor=t\n fi\n \n-git rev-parse --revs-only \"$@\" >../parse\n+git rev-parse --revs-only \"$@\" >../parse.revs.flags\n+sed -ne '/^[0-9a-f][0-9a-f][0-9a-f]*[0-9a-f]$/p' <../parse.revs.flags >../parse.revs\n+sed -e '/^[0-9a-f][0-9a-f][0-9a-f]*[0-9a-f]$/d' <../parse.revs.flags >../parse.flags\n \n case \"$filter_subdir\" in\n \"\")\n@@ -268,7 +270,8 @@ case \"$filter_subdir\" in\n esac\n \n git rev-list --reverse --topo-order --default HEAD \\\n-\t--parents --simplify-merges --stdin \"$@\" <../parse >../revs ||\n+\t--parents --simplify-merges --stdin \"$@\" \\\n+\t$(cat ../parse.flags) <../parse.revs >../revs ||\n \tdie \"Could not get the commits\"\n commits=$(wc -l <../revs | tr -d \" \")\n \n"},{"id":"245158","messageId":"cacf17948e270ab33cc9ff145c4a1af7@tribut.de","threadId":"37010","inReplyTo":"xmqq1tua2oi5.fsf@gitster.dls.corp.google.com","subject":"Re: Passing rev-list options in git-filter-branch broken","fromName":"Felix Eckhofer","fromEmail":"felix@tribut.de","sentAt":"2014-06-29T14:00:49Z","receivedAt":"2014-06-29T14:00:49Z","isPatch":false,"sender":{"key":"felix@tribut.de","avatar":null},"body":"Junio,\n\nthanks for your reply and your patch.\n\nAm 27.06.2014 20:31, schrieb Junio C Hamano:\n> [...]\n> would be a better workaround that would not break repositories with\n> large number of references, but it obviously will lose --date-order\n> option (why would it be even necessary, though?  I suspect that\n> forcing the date-order will make the resulting pack a lot worse by\n> robbing the data stream of locality).\n\nWe're migrating some svn repositories to git. The use case is to replace \nmentions of svn revisions in commit messages by the corresponding commit \nhash. Therefore, the commits must be ordered by svn revision number, \nwhich is not guaranteed for commits on different branches with \n--topo-order.\n\n\nRegards\nfelix\n"}]}