{"thread":{"id":"9782","subject":"[RFC/PATCH] git-svn: add support for --first-parent","startedAt":"2007-09-05T09:35:29Z","lastAt":"2007-09-15T15:49:35Z","messageCount":22,"participants":["Lars Hjemli","Eric Wong","David Kastrup","Steven Grimm","Peter Baumann","Fernando J. Pereda"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"52574","messageId":"1188984929315-git-send-email-hjemli@gmail.com","threadId":"9782","inReplyTo":null,"subject":"[RFC/PATCH] git-svn: add support for --first-parent","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-05T09:35:29Z","receivedAt":"2007-09-05T09:35:29Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit\nmessages, it can get confused when local history contains merges with\nother git-svn branches. But if --first-parent is supplied to git-log,\nworking_head_info() will only see 'branch-local' commits and thus the\nfirst commit containing a 'git-svn-id' line should refer to the correct\nsubversion branch.\n\nSigned-off-by: Lars Hjemli \n---\n\nThis passes the test-suite and I've used it to correctly dcommit against a\nreal-life repository after merging subversion-branches in git ('dcommit -n'\nreported the wrong subversion branch while 'dcommit -n --first-parent' got\nit right, so I did 'dcommit --first-parent' and then inspected the logs and\ndiffs in the subversion repo and everything looked swell).\n\nBut I'm not a perl person, my understanding of git-svn is limited and the\nuse of --first-parent may not be the right solution to the problem...\n\n Documentation/git-svn.txt | 10 ++++++++++\n git-svn.perl | 17 +++++++++++++----\n 2 files changed, 23 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex be2e34e..42d7b82 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -317,6 +317,16 @@ This is only used with the 'dcommit' command.\n Print out the series of git arguments that would show\n which diffs would be committed to SVN.\n \n+--first-parent::\n+\n+This is only used with the 'dcommit', 'rebase', 'log', 'find-rev' and\n+'show-ignore' commands.\n+\n+These commands tries to detect the upstream subversion branch by means of\n+the embedded 'git-svn-id' line in commit messages. When --first-parent is\n+specified, git-svn only follows the first parent of each commit, effectively\n+ignoring commits brought into the current branch through merge-operations.\n+\n --\n \n ADVANCED OPTIONS\ndiff --git a/git-svn.perl b/git-svn.perl\nindex d3c8cd0..d21eb7f 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -59,7 +59,7 @@ my ($_stdin, $_help, $_edit,\n \t$_template, $_shared,\n \t$_version, $_fetch_all, $_no_rebase,\n \t$_merge, $_strategy, $_dry_run, $_local,\n-\t$_prefix, $_no_checkout, $_verbose);\n+\t$_prefix, $_no_checkout, $_verbose, $_first_parent);\n $Git::SVN::_follow_parent = 1;\n my %remote_opts = ( 'username=s' => \\$Git::SVN::Prompt::_username,\n 'config-dir=s' => \\$Git::SVN::Ra::config_dir,\n@@ -119,12 +119,15 @@ my %cmd = (\n \t\t\t 'dry-run|n' => \\$_dry_run,\n \t\t\t 'fetch-all|all' => \\$_fetch_all,\n \t\t\t 'no-rebase' => \\$_no_rebase,\n+\t\t\t 'first-parent' => \\$_first_parent,\n \t\t\t%cmt_opts, %fc_opts } ],\n \t'set-tree' => [ \\&cmd_set_tree,\n \t \"Set an SVN repository to a git tree-ish\",\n \t\t\t{ 'stdin|' => \\$_stdin, %cmt_opts, %fc_opts, } ],\n \t'show-ignore' => [ \\&cmd_show_ignore, \"Show svn:ignore listings\",\n-\t\t\t{ 'revision|r=i' => \\$_revision } ],\n+\t\t\t{ 'revision|r=i' => \\$_revision,\n+\t\t\t 'first-parent' => \\$_first_parent\n+\t\t\t} ],\n \t'multi-fetch' => [ \\&cmd_multi_fetch,\n \t \"Deprecated alias for $0 fetch --all\",\n \t\t\t { 'revision|r=s' => \\$_revision, %fc_opts } ],\n@@ -145,15 +148,19 @@ my %cmd = (\n \t\t\t 'authors-file|A=s' => \\$_authors,\n \t\t\t 'color' => \\$Git::SVN::Log::color,\n \t\t\t 'pager=s' => \\$Git::SVN::Log::pager,\n+\t\t\t 'first-parent' => \\$_first_parent\n \t\t\t} ],\n \t'find-rev' => [ \\&cmd_find_rev, \"Translate between SVN revision numbers and tree-ish\",\n-\t\t\t{ } ],\n+\t\t\t{\n+\t\t\t 'first-parent' => \\$_first_parent\n+\t\t\t} ],\n \t'rebase' => [ \\&cmd_rebase, \"Fetch and rebase your working directory\",\n \t\t\t{ 'merge|m|M' => \\$_merge,\n \t\t\t 'verbose|v' => \\$_verbose,\n \t\t\t 'strategy|s=s' => \\$_strategy,\n \t\t\t 'local|l' => \\$_local,\n \t\t\t 'fetch-all|all' => \\$_fetch_all,\n+\t\t\t 'first-parent' => \\$_first_parent,\n \t\t\t %fc_opts } ],\n \t'commit-diff' => [ \\&cmd_commit_diff,\n \t 'Commit a diff between two trees',\n@@ -811,7 +818,9 @@ sub cmt_metadata {\n \n sub working_head_info {\n \tmy ($head, $refs) = @_;\n-\tmy ($fh, $ctx) = command_output_pipe('log', '--no-color', $head);\n+\tmy @args = ('log', '--no-color');\n+\tpush @args, '--first-parent' if $_first_parent;\n+\tmy ($fh, $ctx) = command_output_pipe(@args, $head);\n \tmy $hash;\n \tmy %max;\n \twhile (<$fh>) {\n-- \n1.5.3.1.g7e90d-dirty\n"},{"id":"52579","messageId":"20070905101929.GB11074@soma","threadId":"9782","inReplyTo":"1188984929315-git-send-email-hjemli@gmail.com","subject":"Re: [RFC/PATCH] git-svn: add support for --first-parent","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-05T10:19:29Z","receivedAt":"2007-09-05T10:19:29Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Lars Hjemli wrote:\n> When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit\n> messages, it can get confused when local history contains merges with\n> other git-svn branches. But if --first-parent is supplied to git-log,\n> working_head_info() will only see 'branch-local' commits and thus the\n> first commit containing a 'git-svn-id' line should refer to the correct\n> subversion branch.\n> \n> Signed-off-by: Lars Hjemli \n> ---\n> \n> This passes the test-suite and I've used it to correctly dcommit against a\n> real-life repository after merging subversion-branches in git ('dcommit -n'\n> reported the wrong subversion branch while 'dcommit -n --first-parent' got\n> it right, so I did 'dcommit --first-parent' and then inspected the logs and\n> diffs in the subversion repo and everything looked swell).\n> \n> But I'm not a perl person, my understanding of git-svn is limited and the\n> use of --first-parent may not be the right solution to the problem...\n\nAt first glance this seems reasonable. I didn't know about git-log\n--first-parent until now, but it seems like a good 80% solution.\n\nIdeally, we'd probably stop, say something and give the user the choice\nof branches if multiple parents available.\n\nAcked-by-for-next-or-pu: Eric Wong \n\n> Documentation/git-svn.txt | 10 ++++++++++\n> git-svn.perl | 17 +++++++++++++----\n> 2 files changed, 23 insertions(+), 4 deletions(-)\n> \n> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\n> index be2e34e..42d7b82 100644\n> --- a/Documentation/git-svn.txt\n> +++ b/Documentation/git-svn.txt\n> @@ -317,6 +317,16 @@ This is only used with the 'dcommit' command.\n> Print out the series of git arguments that would show\n> which diffs would be committed to SVN.\n> \n> +--first-parent::\n> +\n> +This is only used with the 'dcommit', 'rebase', 'log', 'find-rev' and\n> +'show-ignore' commands.\n> +\n> +These commands tries to detect the upstream subversion branch by means of\n> +the embedded 'git-svn-id' line in commit messages. When --first-parent is\n> +specified, git-svn only follows the first parent of each commit, effectively\n> +ignoring commits brought into the current branch through merge-operations.\n> +\n> --\n> \n> ADVANCED OPTIONS\n> diff --git a/git-svn.perl b/git-svn.perl\n> index d3c8cd0..d21eb7f 100755\n> --- a/git-svn.perl\n> +++ b/git-svn.perl\n> @@ -59,7 +59,7 @@ my ($_stdin, $_help, $_edit,\n> \t$_template, $_shared,\n> \t$_version, $_fetch_all, $_no_rebase,\n> \t$_merge, $_strategy, $_dry_run, $_local,\n> -\t$_prefix, $_no_checkout, $_verbose);\n> +\t$_prefix, $_no_checkout, $_verbose, $_first_parent);\n> $Git::SVN::_follow_parent = 1;\n> my %remote_opts = ( 'username=s' => \\$Git::SVN::Prompt::_username,\n> 'config-dir=s' => \\$Git::SVN::Ra::config_dir,\n> @@ -119,12 +119,15 @@ my %cmd = (\n> \t\t\t 'dry-run|n' => \\$_dry_run,\n> \t\t\t 'fetch-all|all' => \\$_fetch_all,\n> \t\t\t 'no-rebase' => \\$_no_rebase,\n> +\t\t\t 'first-parent' => \\$_first_parent,\n> \t\t\t%cmt_opts, %fc_opts } ],\n> \t'set-tree' => [ \\&cmd_set_tree,\n> \t \"Set an SVN repository to a git tree-ish\",\n> \t\t\t{ 'stdin|' => \\$_stdin, %cmt_opts, %fc_opts, } ],\n> \t'show-ignore' => [ \\&cmd_show_ignore, \"Show svn:ignore listings\",\n> -\t\t\t{ 'revision|r=i' => \\$_revision } ],\n> +\t\t\t{ 'revision|r=i' => \\$_revision,\n> +\t\t\t 'first-parent' => \\$_first_parent\n> +\t\t\t} ],\n> \t'multi-fetch' => [ \\&cmd_multi_fetch,\n> \t \"Deprecated alias for $0 fetch --all\",\n> \t\t\t { 'revision|r=s' => \\$_revision, %fc_opts } ],\n> @@ -145,15 +148,19 @@ my %cmd = (\n> \t\t\t 'authors-file|A=s' => \\$_authors,\n> \t\t\t 'color' => \\$Git::SVN::Log::color,\n> \t\t\t 'pager=s' => \\$Git::SVN::Log::pager,\n> +\t\t\t 'first-parent' => \\$_first_parent\n> \t\t\t} ],\n> \t'find-rev' => [ \\&cmd_find_rev, \"Translate between SVN revision numbers and tree-ish\",\n> -\t\t\t{ } ],\n> +\t\t\t{\n> +\t\t\t 'first-parent' => \\$_first_parent\n> +\t\t\t} ],\n> \t'rebase' => [ \\&cmd_rebase, \"Fetch and rebase your working directory\",\n> \t\t\t{ 'merge|m|M' => \\$_merge,\n> \t\t\t 'verbose|v' => \\$_verbose,\n> \t\t\t 'strategy|s=s' => \\$_strategy,\n> \t\t\t 'local|l' => \\$_local,\n> \t\t\t 'fetch-all|all' => \\$_fetch_all,\n> +\t\t\t 'first-parent' => \\$_first_parent,\n> \t\t\t %fc_opts } ],\n> \t'commit-diff' => [ \\&cmd_commit_diff,\n> \t 'Commit a diff between two trees',\n> @@ -811,7 +818,9 @@ sub cmt_metadata {\n> \n> sub working_head_info {\n> \tmy ($head, $refs) = @_;\n> -\tmy ($fh, $ctx) = command_output_pipe('log', '--no-color', $head);\n> +\tmy @args = ('log', '--no-color');\n> +\tpush @args, '--first-parent' if $_first_parent;\n> +\tmy ($fh, $ctx) = command_output_pipe(@args, $head);\n> \tmy $hash;\n> \tmy %max;\n> \twhile (<$fh>) {\n\n-- \nEric Wong\n"},{"id":"52707","messageId":"8c5c35580709060018p50398071s32b271d52f4dc7e3@mail.gmail.com","threadId":"9782","inReplyTo":"20070905101929.GB11074@soma","subject":"Re: [RFC/PATCH] git-svn: add support for --first-parent","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-06T07:18:30Z","receivedAt":"2007-09-06T07:18:30Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/5/07, Eric Wong wrote:\n> Lars Hjemli wrote:\n> > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit\n> > messages, it can get confused when local history contains merges with\n> > other git-svn branches. But if --first-parent is supplied to git-log,\n> > working_head_info() will only see 'branch-local' commits and thus the\n> > first commit containing a 'git-svn-id' line should refer to the correct\n> > subversion branch.\n>\n> Ideally, we'd probably stop, say something and give the user the choice\n> of branches if multiple parents available.\n\nCould you elaborate? (I don't understand how following the first\nparent of a merge could end up at the wrong svn branch)\n\n--\nlarsh\n"},{"id":"52708","messageId":"20070906075104.GA10192@hand.yhbt.net","threadId":"9782","inReplyTo":"8c5c35580709060018p50398071s32b271d52f4dc7e3@mail.gmail.com","subject":"Re: [RFC/PATCH] git-svn: add support for --first-parent","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-06T07:51:04Z","receivedAt":"2007-09-06T07:51:04Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Lars Hjemli wrote:\n> On 9/5/07, Eric Wong wrote:\n> > Lars Hjemli wrote:\n> > > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit\n> > > messages, it can get confused when local history contains merges with\n> > > other git-svn branches. But if --first-parent is supplied to git-log,\n> > > working_head_info() will only see 'branch-local' commits and thus the\n> > > first commit containing a 'git-svn-id' line should refer to the correct\n> > > subversion branch.\n> >\n> > Ideally, we'd probably stop, say something and give the user the choice\n> > of branches if multiple parents available.\n> \n> Could you elaborate? (I don't understand how following the first\n> parent of a merge could end up at the wrong svn branch)\n\nWell, if the user didn't know about --first-parent (like me yesterday\n:), they could still end up miscommitting to any branch. That's been a\ncomplaint of users for a while now. Thinking more about it,\n--first-parent should probably be the default.\n\nBut, if they want to commit a different branch instead of the one they\nmerged into (so the second/third/fourth parent), --first-parent would\nnever give them that chance.\n\n-- \nEric Wong\n"},{"id":"52709","messageId":"85ejhcfccp.fsf@lola.goethe.zz","threadId":"9782","inReplyTo":"20070906075104.GA10192@hand.yhbt.net","subject":"Re: [RFC/PATCH] git-svn: add support for --first-parent","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-06T08:05:10Z","receivedAt":"2007-09-06T08:05:10Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Eric Wong writes:\n\n> Lars Hjemli wrote:\n>> On 9/5/07, Eric Wong wrote:\n>> > Lars Hjemli wrote:\n>> > > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit\n>> > > messages, it can get confused when local history contains merges with\n>> > > other git-svn branches. But if --first-parent is supplied to git-log,\n>> > > working_head_info() will only see 'branch-local' commits and thus the\n>> > > first commit containing a 'git-svn-id' line should refer to the correct\n>> > > subversion branch.\n>> >\n>> > Ideally, we'd probably stop, say something and give the user the choice\n>> > of branches if multiple parents available.\n>> \n>> Could you elaborate? (I don't understand how following the first\n>> parent of a merge could end up at the wrong svn branch)\n>\n> Well, if the user didn't know about --first-parent (like me yesterday\n> :), they could still end up miscommitting to any branch. That's been a\n> complaint of users for a while now. Thinking more about it,\n> --first-parent should probably be the default.\n>\n> But, if they want to commit a different branch instead of the one they\n> merged into (so the second/third/fourth parent), --first-parent would\n> never give them that chance.\n\nIf they want to commit to a different branch, they can b****y well\ncheck out that branch and merge to _that_. That is the way all the\nrest of git works and nobody whines that this is a restriction.\n\nQuite the opposite: that git-svn does not feel constrained to actually\ncommit to the base of the checked-out branch is a complete nuisance.\n_Why_ would anybody want to dcommit to a Subversion branch not\nassociated with the current branch?\n\nJust yesterday, I _again_ had git-svn dcommit to a nonsensical branch\n(this time, the commit was to branch instead of the trunk, while more\noften the catastrophes happen the other way round). And it is not\nlike git-svn gives you a chance to override this bad decision: you\nhave to rebase -i all of your commit messages from potential\ncherrypicks or whatever else and remove the git-svn taglines manually\nfor every commit before git-svn will deign to dcommit to the same\nbranch as before.\n\nEric, this is not \"flexibility\". This is madness. If you think that\nit is essential to dcommit to a branch unrelated to the current HEAD,\nthen create a sane command line interface for it that takes effect at\nthe time of dcommit. But the current interface is just throwing dice\nas far as the user is concerned, since the addition of git-svn tags to\ncommit messages happens behind his back, and any merge or cherrypick\nor rebase 5 revisions back might come to bite you.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52710","messageId":"8c5c35580709060134x22ed48d2nc9123e234fc6cf70@mail.gmail.com","threadId":"9782","inReplyTo":"20070906075104.GA10192@hand.yhbt.net","subject":"Re: [RFC/PATCH] git-svn: add support for --first-parent","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-06T08:34:14Z","receivedAt":"2007-09-06T08:34:14Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/6/07, Eric Wong wrote:\n> Lars Hjemli wrote:\n> > On 9/5/07, Eric Wong wrote:\n> > > Lars Hjemli wrote:\n> > > > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit\n> > > > messages, it can get confused when local history contains merges with\n> > > > other git-svn branches. But if --first-parent is supplied to git-log,\n> > > > working_head_info() will only see 'branch-local' commits and thus the\n> > > > first commit containing a 'git-svn-id' line should refer to the correct\n> > > > subversion branch.\n> > >\n> > > Ideally, we'd probably stop, say something and give the user the choice\n> > > of branches if multiple parents available.\n> >\n> > Could you elaborate? (I don't understand how following the first\n> > parent of a merge could end up at the wrong svn branch)\n>\n> Well, if the user didn't know about --first-parent (like me yesterday\n> :), they could still end up miscommitting to any branch. That's been a\n> complaint of users for a while now. Thinking more about it,\n> --first-parent should probably be the default.\n>\n> But, if they want to commit a different branch instead of the one they\n> merged into (so the second/third/fourth parent), --first-parent would\n> never give them that chance.\n\nOk, so maybe '--first-parent' should be the default unless the user\nspecified something like '--upstream ', like this:\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex d21eb7f..0590299 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -819,8 +819,13 @@ sub cmt_metadata {\n sub working_head_info {\n my ($head, $refs) = @_;\n my @args = ('log', '--no-color');\n- push @args, '--first-parent' if $_first_parent;\n- my ($fh, $ctx) = command_output_pipe(@args, $head);\n+ if ($_revspec) {\n+ push @args, $_revspec;\n+ } else {\n+ push @args, '--first-parent';\n+ push @args, $head;\n+ }\n+ my ($fh, $ctx) = command_output_pipe(@args);\n my $hash;\n my %max;\n while (<$fh>) {\n\nThis should give the user plenty of rope ;-)\n\n--\nlarsh\n"},{"id":"52775","messageId":"1189096669534-git-send-email-hjemli@gmail.com","threadId":"9782","inReplyTo":"20070906075104.GA10192@hand.yhbt.net","subject":"[PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-06T16:37:49Z","receivedAt":"2007-09-06T16:37:49Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"This makes git-svn always issue the --first-parent option to git-log when\ntrying to establish the \"base\" subversion branch, so the --first-parent\noption to git-svn is no longer needed. Instead a new option, --upstream\n, is introduced. When this is specified the search for embedded\ngit-svn-id lines in commit messages starts at the specified revision, if\nnot specified the search starts at HEAD.\n\nSigned-off-by: Lars Hjemli \n---\n Documentation/git-svn.txt | 10 +++++-----\n git-svn.perl | 18 +++++++++---------\n 2 files changed, 14 insertions(+), 14 deletions(-)\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex 42d7b82..2903777 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -317,15 +317,15 @@ This is only used with the 'dcommit' command.\n Print out the series of git arguments that would show\n which diffs would be committed to SVN.\n \n---first-parent::\n+--upstream=::\n \n This is only used with the 'dcommit', 'rebase', 'log', 'find-rev' and\n 'show-ignore' commands.\n \n-These commands tries to detect the upstream subversion branch by means of\n-the embedded 'git-svn-id' line in commit messages. When --first-parent is\n-specified, git-svn only follows the first parent of each commit, effectively\n-ignoring commits brought into the current branch through merge-operations.\n+These commands tries to detect the upstream subversion branch by traversing\n+the first parent of each commit (starting at HEAD), looking for an embedded\n+'git-svn-id' line in the commit messages. When --upstream is specified,\n+git-svn starts the traversal at the specified commit instead of HEAD.\n \n --\n \ndiff --git a/git-svn.perl b/git-svn.perl\nindex d21eb7f..947a944 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -59,7 +59,7 @@ my ($_stdin, $_help, $_edit,\n \t$_template, $_shared,\n \t$_version, $_fetch_all, $_no_rebase,\n \t$_merge, $_strategy, $_dry_run, $_local,\n-\t$_prefix, $_no_checkout, $_verbose, $_first_parent);\n+\t$_prefix, $_no_checkout, $_verbose, $_upstream);\n $Git::SVN::_follow_parent = 1;\n my %remote_opts = ( 'username=s' => \\$Git::SVN::Prompt::_username,\n 'config-dir=s' => \\$Git::SVN::Ra::config_dir,\n@@ -119,14 +119,14 @@ my %cmd = (\n \t\t\t 'dry-run|n' => \\$_dry_run,\n \t\t\t 'fetch-all|all' => \\$_fetch_all,\n \t\t\t 'no-rebase' => \\$_no_rebase,\n-\t\t\t 'first-parent' => \\$_first_parent,\n+\t\t\t 'upstream=s' => \\$_upstream,\n \t\t\t%cmt_opts, %fc_opts } ],\n \t'set-tree' => [ \\&cmd_set_tree,\n \t \"Set an SVN repository to a git tree-ish\",\n \t\t\t{ 'stdin|' => \\$_stdin, %cmt_opts, %fc_opts, } ],\n \t'show-ignore' => [ \\&cmd_show_ignore, \"Show svn:ignore listings\",\n \t\t\t{ 'revision|r=i' => \\$_revision,\n-\t\t\t 'first-parent' => \\$_first_parent\n+\t\t\t 'upstream=s' => \\$_upstream\n \t\t\t} ],\n \t'multi-fetch' => [ \\&cmd_multi_fetch,\n \t \"Deprecated alias for $0 fetch --all\",\n@@ -148,11 +148,11 @@ my %cmd = (\n \t\t\t 'authors-file|A=s' => \\$_authors,\n \t\t\t 'color' => \\$Git::SVN::Log::color,\n \t\t\t 'pager=s' => \\$Git::SVN::Log::pager,\n-\t\t\t 'first-parent' => \\$_first_parent\n+\t\t\t 'upstream=s' => \\$_upstream\n \t\t\t} ],\n \t'find-rev' => [ \\&cmd_find_rev, \"Translate between SVN revision numbers and tree-ish\",\n \t\t\t{\n-\t\t\t 'first-parent' => \\$_first_parent\n+\t\t\t 'upstream=s' => \\$_upstream\n \t\t\t} ],\n \t'rebase' => [ \\&cmd_rebase, \"Fetch and rebase your working directory\",\n \t\t\t{ 'merge|m|M' => \\$_merge,\n@@ -160,7 +160,7 @@ my %cmd = (\n \t\t\t 'strategy|s=s' => \\$_strategy,\n \t\t\t 'local|l' => \\$_local,\n \t\t\t 'fetch-all|all' => \\$_fetch_all,\n-\t\t\t 'first-parent' => \\$_first_parent,\n+\t\t\t 'upstream=s' => \\$_upstream,\n \t\t\t %fc_opts } ],\n \t'commit-diff' => [ \\&cmd_commit_diff,\n \t 'Commit a diff between two trees',\n@@ -818,9 +818,9 @@ sub cmt_metadata {\n \n sub working_head_info {\n \tmy ($head, $refs) = @_;\n-\tmy @args = ('log', '--no-color');\n-\tpush @args, '--first-parent' if $_first_parent;\n-\tmy ($fh, $ctx) = command_output_pipe(@args, $head);\n+\tmy @args = ('log', '--no-color', '--first-parent');\n+\tpush @args, ($_upstream ? $_upstream : $head);\n+\tmy ($fh, $ctx) = command_output_pipe(@args);\n \tmy $hash;\n \tmy %max;\n \twhile (<$fh>) {\n-- \n1.5.3.1.g0e33-dirty\n"},{"id":"52787","messageId":"46E03DB8.8060809@midwinter.com","threadId":"9782","inReplyTo":"1189096669534-git-send-email-hjemli@gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-09-06T17:49:44Z","receivedAt":"2007-09-06T17:49:44Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Lars Hjemli wrote:\n> This makes git-svn always issue the --first-parent option to git-log when\n> trying to establish the \"base\" subversion branch, so the --first-parent\n> option to git-svn is no longer needed. Instead a new option, --upstream\n> , is introduced. When this is specified the search for embedded\n> git-svn-id lines in commit messages starts at the specified revision, if\n> not specified the search starts at HEAD.\n> \n\nThis is a much better solution -- I can't personally imagine a scenario \nwhere I'd want anything other than the --first-parent behavior, so \nmaking it the default is much more convenient. Thanks.\n\n-Steve\n"},{"id":"52802","messageId":"20070906210155.GA20938@soma","threadId":"9782","inReplyTo":"1189096669534-git-send-email-hjemli@gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-06T21:01:55Z","receivedAt":"2007-09-06T21:01:55Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Lars Hjemli wrote:\n> This makes git-svn always issue the --first-parent option to git-log when\n> trying to establish the \"base\" subversion branch, so the --first-parent\n> option to git-svn is no longer needed. Instead a new option, --upstream\n> , is introduced. When this is specified the search for embedded\n> git-svn-id lines in commit messages starts at the specified revision, if\n> not specified the search starts at HEAD.\n> \n> Signed-off-by: Lars Hjemli \n\nLooks good to me.\n\nAcked-by: Eric Wong \n\n> ---\n> Documentation/git-svn.txt | 10 +++++-----\n> git-svn.perl | 18 +++++++++---------\n> 2 files changed, 14 insertions(+), 14 deletions(-)\n> \n> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\n> index 42d7b82..2903777 100644\n> --- a/Documentation/git-svn.txt\n> +++ b/Documentation/git-svn.txt\n> @@ -317,15 +317,15 @@ This is only used with the 'dcommit' command.\n> Print out the series of git arguments that would show\n> which diffs would be committed to SVN.\n> \n> ---first-parent::\n> +--upstream=::\n> \n> This is only used with the 'dcommit', 'rebase', 'log', 'find-rev' and\n> 'show-ignore' commands.\n> \n> -These commands tries to detect the upstream subversion branch by means of\n> -the embedded 'git-svn-id' line in commit messages. When --first-parent is\n> -specified, git-svn only follows the first parent of each commit, effectively\n> -ignoring commits brought into the current branch through merge-operations.\n> +These commands tries to detect the upstream subversion branch by traversing\n> +the first parent of each commit (starting at HEAD), looking for an embedded\n> +'git-svn-id' line in the commit messages. When --upstream is specified,\n> +git-svn starts the traversal at the specified commit instead of HEAD.\n> \n> --\n> \n> diff --git a/git-svn.perl b/git-svn.perl\n> index d21eb7f..947a944 100755\n> --- a/git-svn.perl\n> +++ b/git-svn.perl\n> @@ -59,7 +59,7 @@ my ($_stdin, $_help, $_edit,\n> \t$_template, $_shared,\n> \t$_version, $_fetch_all, $_no_rebase,\n> \t$_merge, $_strategy, $_dry_run, $_local,\n> -\t$_prefix, $_no_checkout, $_verbose, $_first_parent);\n> +\t$_prefix, $_no_checkout, $_verbose, $_upstream);\n> $Git::SVN::_follow_parent = 1;\n> my %remote_opts = ( 'username=s' => \\$Git::SVN::Prompt::_username,\n> 'config-dir=s' => \\$Git::SVN::Ra::config_dir,\n> @@ -119,14 +119,14 @@ my %cmd = (\n> \t\t\t 'dry-run|n' => \\$_dry_run,\n> \t\t\t 'fetch-all|all' => \\$_fetch_all,\n> \t\t\t 'no-rebase' => \\$_no_rebase,\n> -\t\t\t 'first-parent' => \\$_first_parent,\n> +\t\t\t 'upstream=s' => \\$_upstream,\n> \t\t\t%cmt_opts, %fc_opts } ],\n> \t'set-tree' => [ \\&cmd_set_tree,\n> \t \"Set an SVN repository to a git tree-ish\",\n> \t\t\t{ 'stdin|' => \\$_stdin, %cmt_opts, %fc_opts, } ],\n> \t'show-ignore' => [ \\&cmd_show_ignore, \"Show svn:ignore listings\",\n> \t\t\t{ 'revision|r=i' => \\$_revision,\n> -\t\t\t 'first-parent' => \\$_first_parent\n> +\t\t\t 'upstream=s' => \\$_upstream\n> \t\t\t} ],\n> \t'multi-fetch' => [ \\&cmd_multi_fetch,\n> \t \"Deprecated alias for $0 fetch --all\",\n> @@ -148,11 +148,11 @@ my %cmd = (\n> \t\t\t 'authors-file|A=s' => \\$_authors,\n> \t\t\t 'color' => \\$Git::SVN::Log::color,\n> \t\t\t 'pager=s' => \\$Git::SVN::Log::pager,\n> -\t\t\t 'first-parent' => \\$_first_parent\n> +\t\t\t 'upstream=s' => \\$_upstream\n> \t\t\t} ],\n> \t'find-rev' => [ \\&cmd_find_rev, \"Translate between SVN revision numbers and tree-ish\",\n> \t\t\t{\n> -\t\t\t 'first-parent' => \\$_first_parent\n> +\t\t\t 'upstream=s' => \\$_upstream\n> \t\t\t} ],\n> \t'rebase' => [ \\&cmd_rebase, \"Fetch and rebase your working directory\",\n> \t\t\t{ 'merge|m|M' => \\$_merge,\n> @@ -160,7 +160,7 @@ my %cmd = (\n> \t\t\t 'strategy|s=s' => \\$_strategy,\n> \t\t\t 'local|l' => \\$_local,\n> \t\t\t 'fetch-all|all' => \\$_fetch_all,\n> -\t\t\t 'first-parent' => \\$_first_parent,\n> +\t\t\t 'upstream=s' => \\$_upstream,\n> \t\t\t %fc_opts } ],\n> \t'commit-diff' => [ \\&cmd_commit_diff,\n> \t 'Commit a diff between two trees',\n> @@ -818,9 +818,9 @@ sub cmt_metadata {\n> \n> sub working_head_info {\n> \tmy ($head, $refs) = @_;\n> -\tmy @args = ('log', '--no-color');\n> -\tpush @args, '--first-parent' if $_first_parent;\n> -\tmy ($fh, $ctx) = command_output_pipe(@args, $head);\n> +\tmy @args = ('log', '--no-color', '--first-parent');\n> +\tpush @args, ($_upstream ? $_upstream : $head);\n> +\tmy ($fh, $ctx) = command_output_pipe(@args);\n> \tmy $hash;\n> \tmy %max;\n> \twhile (<$fh>) {\n> -- \n> 1.5.3.1.g0e33-dirty\n> \n\n-- \nEric Wong\n"},{"id":"52804","messageId":"20070906213556.GA21234@soma","threadId":"9782","inReplyTo":"20070906210155.GA20938@soma","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-06T21:35:56Z","receivedAt":"2007-09-06T21:35:56Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong wrote:\n> Lars Hjemli wrote:\n> > This makes git-svn always issue the --first-parent option to git-log when\n> > trying to establish the \"base\" subversion branch, so the --first-parent\n> > option to git-svn is no longer needed. Instead a new option, --upstream\n> > , is introduced. When this is specified the search for embedded\n> > git-svn-id lines in commit messages starts at the specified revision, if\n> > not specified the search starts at HEAD.\n> > \n> > Signed-off-by: Lars Hjemli \n> \n> Looks good to me.\n> \n> Acked-by: Eric Wong \n\nWait, actually. --upstream won't ever populate the refs array in\nworking_head_info for dcommit (but --first-parent should be great for\nthat).\n\nBut the rest of the commands is fine. I also just noticed cmd_find_rev\npasses the @refs argument to working_head_info() unnecessarily.\n\n-- \nEric Wong\n"},{"id":"52806","messageId":"8c5c35580709061514n1de6f141v5e596074cfa9fb42@mail.gmail.com","threadId":"9782","inReplyTo":"20070906213556.GA21234@soma","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-06T22:14:30Z","receivedAt":"2007-09-06T22:14:30Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/6/07, Eric Wong wrote:\n> Wait, actually. --upstream won't ever populate the refs array in\n> working_head_info for dcommit\n\nSorry, I didn't realize that working_head_info() collected commit-ids\nlater used by dcommit. But to implement --upstream we could maybe do\nsomething like this:\n\nsub working_head_info {\n my ($head, $refs) = @_;\n\n if (defined $_upstream) {\n working_head_info_traverse($head, \\$refs);\n return working_head_info_traverse($_upstream, undef);\n }\n\n return working_head_info_traverse($head, \\$refs);\n}\n\nsub working_head_info_traverse {\n my ($head, $refs) = @_;\n my ($fh, $ctx) = command_output_pipe('log', '--no-color',\n'--first-parent', $head);\n ...\n\n\n(This was written straight into firefox, late at night, by a perl\nilliterate. Please be gentle...)\n\n-- \nlarsh\n"},{"id":"52823","messageId":"20070906235516.GC4538@xp.machine.xx","threadId":"9782","inReplyTo":"8c5c35580709061514n1de6f141v5e596074cfa9fb42@mail.gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-09-06T23:55:16Z","receivedAt":"2007-09-06T23:55:16Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Fri, Sep 07, 2007 at 12:14:30AM +0200, Lars Hjemli wrote:\n> On 9/6/07, Eric Wong wrote:\n> > Wait, actually. --upstream won't ever populate the refs array in\n> > working_head_info for dcommit\n> \n> Sorry, I didn't realize that working_head_info() collected commit-ids\n> later used by dcommit. But to implement --upstream we could maybe do\n> something like this:\n> \n> sub working_head_info {\n> my ($head, $refs) = @_;\n> \n> if (defined $_upstream) {\n> working_head_info_traverse($head, \\$refs);\n> return working_head_info_traverse($_upstream, undef);\n> }\n> \n> return working_head_info_traverse($head, \\$refs);\n> }\n> \n> sub working_head_info_traverse {\n> my ($head, $refs) = @_;\n> my ($fh, $ctx) = command_output_pipe('log', '--no-color',\n> '--first-parent', $head);\n> ...\n> \n> \n> (This was written straight into firefox, late at night, by a perl\n> illiterate. Please be gentle...)\n> \n\nSorry, but isn't --upstream just the wrong way to do what you want?\nWhy should I specify a GIT commit to leat git-svn figure out on what\nupstream SVN branch I want to commit? To me, this seems a little\nbackwards. Wouldn't it be much more pleasant to say something like\n\n\tgit-svn dcommit --on the_branch\n\nwhereas 'the_branch' is the name of the upstream branch as specified\nin the fetch/branch section in the git config? If I do a dcommit I know\n*exactly* on which svn branch it should go, so why can't I specify it on\nthe cmdline? ... or did I miss something obvious?\n\n-Peter\n"},{"id":"52825","messageId":"8c5c35580709061723m7e01c9d4p1b1936dc1d590459@mail.gmail.com","threadId":"9782","inReplyTo":"20070906235516.GC4538@xp.machine.xx","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-07T00:23:58Z","receivedAt":"2007-09-07T00:23:58Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/7/07, Peter Baumann wrote:\n> Wouldn't it be much more pleasant to say something like\n>\n> git-svn dcommit --on the_branch\n>\n> whereas 'the_branch' is the name of the upstream branch as specified\n> in the fetch/branch section in the git config?\n\nWell, git-svn extracts the svn url, revision and repo uuid from the\ncommit message, while your proposal only specifies the url. But I'm\nstill not certain that there is a need for --upstream or anything\nsimilar if git-svn always uses 'git log --first-parent' (see\nhttp://article.gmane.org/gmane.comp.version-control.git/57951).\n\n--\nlarsh\n"},{"id":"52877","messageId":"20070907084352.GD4538@xp.machine.xx","threadId":"9782","inReplyTo":"8c5c35580709061723m7e01c9d4p1b1936dc1d590459@mail.gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-09-07T08:43:52Z","receivedAt":"2007-09-07T08:43:52Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Fri, Sep 07, 2007 at 02:23:58AM +0200, Lars Hjemli wrote:\n> On 9/7/07, Peter Baumann wrote:\n> > Wouldn't it be much more pleasant to say something like\n> >\n> > git-svn dcommit --on the_branch\n> >\n> > whereas 'the_branch' is the name of the upstream branch as specified\n> > in the fetch/branch section in the git config?\n> \n> Well, git-svn extracts the svn url, revision and repo uuid from the\n> commit message, while your proposal only specifies the url. But I'm\n> still not certain that there is a need for --upstream or anything\n> similar if git-svn always uses 'git log --first-parent' (see\n> http://article.gmane.org/gmane.comp.version-control.git/57951).\n> \n\nFirst parent is a heuristic (and a good one, me thinks).\n\nIf you did something like this:\n\n(1) Start state:\n\n a-b-c-d-e trunk\t(both trunk and branch1 are imported\n \\\t\t\t from SVN)\n\t \\-x-y branch1\n\n(2) Hm. My Branch 'branch1' should be ready to be merged to 'trunk', so\n lets do it (not yet dcommited)\n\n a-b-c-d-e- m trunk\n \\\t /\n\t \\ -x-y branch1\n\n(3) ARGH. I just discovered a serious bug in 'branch1' and can't just merge\n it into 'trunk', yet. But the merge was painfull enough so I don't want to\n redo it again, so lets reset 'trunk' to its state before the merge and\n 'branch1' to the merge commit, before fixing the bug in 'branch1'.\n\n a-b-c-d-e trunk\n \\\t \\\n\t \\ -x-y m branch1\n\nNotice that this DAG is identical to the one in (2), but just the branch\nlabels stick to different commits. And if you now want to commit the\nmerge 'm' to 'branch1' before fixing the bug you are screwed, because\n--first-parent will give you 'e' instead of 'y'.\n\nYes, I know that this example isn't something happening every day, but\nat least it shows that --first-parent could *only* be a heuristic and\nnot something you would rely 100% on. And if you imagine several people\nwho are sharing their git commits for codereview with pulling/pushing,\nit isn't obvious what branch got merged into the other, because it is\npossible that the other person did the merge.\n\nDon't get me wrong, --first-parent *is* an improvement over the current\nbehaviour, but I think it is simply not the *best* we can do.\n\n-Peter\n"},{"id":"52886","messageId":"8c5c35580709070313l4b815ddbg70be8fb0aef4eefd@mail.gmail.com","threadId":"9782","inReplyTo":"20070907084352.GD4538@xp.machine.xx","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-07T10:13:23Z","receivedAt":"2007-09-07T10:13:23Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/7/07, Peter Baumann wrote:\n> lets reset 'trunk' to its state before the merge and\n> 'branch1' to the merge commit, before fixing the bug in 'branch1'.\n>\n> a-b-c-d-e trunk\n> \\ \\\n> \\ -x-y m branch1\n\nYeah, this would certainly not be handled correctly by dcommit using\n--first-parent (but it could be handled by (a correct implementation\nof) --upstream).\n\nThanks for the example, I had a feeling something like this could\noccur. So I guess I'll have another go at --upstream this weekend.\n\n[btw: could you please stop messing with 'Mail-Followup-To:'? When\nreplying to your mail, I don't want everyone _except_ you in the 'To:'\nheader...]\n\n--\nlarsh\n"},{"id":"52900","messageId":"20070907115130.GA1547@xp.machine.xx","threadId":"9782","inReplyTo":"8c5c35580709070313l4b815ddbg70be8fb0aef4eefd@mail.gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-09-07T11:51:30Z","receivedAt":"2007-09-07T11:51:30Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Fri, Sep 07, 2007 at 12:13:23PM +0200, Lars Hjemli wrote:\n> On 9/7/07, Peter Baumann wrote:\n> > lets reset 'trunk' to its state before the merge and\n> > 'branch1' to the merge commit, before fixing the bug in 'branch1'.\n> >\n> > a-b-c-d-e trunk\n> > \\ \\\n> > \\ -x-y m branch1\n> \n> Yeah, this would certainly not be handled correctly by dcommit using\n> --first-parent (but it could be handled by (a correct implementation\n> of) --upstream).\n> \n> Thanks for the example, I had a feeling something like this could\n> occur. So I guess I'll have another go at --upstream this weekend.\n> \n> [btw: could you please stop messing with 'Mail-Followup-To:'? When\n> replying to your mail, I don't want everyone _except_ you in the 'To:'\n> header...]\n> \n\nSorry, I wasn't aware of that.\n\nI had a 'subscribe git@vger.kernel.org' in my muttrc and just pressed 'g'\nfor group reply. Reading the docs suggested to 'set followup_to=no' (as\nI did before sending this message). Per default it is set to 'yes'.\n\nCould anyone more experienced with mutt correct me if this was the wrong\nfix for this problem (or even point me to the right documentation)?\n\n-Peter\n"},{"id":"52903","messageId":"20070907120812.GA4405@ferdyx.org","threadId":"9782","inReplyTo":"20070907115130.GA1547@xp.machine.xx","subject":"Configure mutt to be used in git and lkml mailing lists (was: Re: [PATCH] git-svn: remove --first-parent, add --upstream)","fromName":"Fernando J. Pereda","fromEmail":"ferdy@gentoo.org","sentAt":"2007-09-07T12:08:12Z","receivedAt":"2007-09-07T12:08:12Z","isPatch":true,"sender":{"key":"ferdy@gentoo.org","avatar":null},"body":"On Fri, Sep 07, 2007 at 01:51:30PM +0200, Peter Baumann wrote:\n> > [btw: could you please stop messing with 'Mail-Followup-To:'? When\n> > replying to your mail, I don't want everyone _except_ you in the 'To:'\n> > header...]\n> > \n> \n> Sorry, I wasn't aware of that.\n> \n> I had a 'subscribe git@vger.kernel.org' in my muttrc and just pressed 'g'\n> for group reply. Reading the docs suggested to 'set followup_to=no' (as\n> I did before sending this message). Per default it is set to 'yes'.\n> \n> Could anyone more experienced with mutt correct me if this was the wrong\n> fix for this problem (or even point me to the right documentation)?\n> \n\n[I'm sending this to the list too so it ends up in the archives. I cut\nthe rest of the people from the To: list because this is not directly\nrelevant to them.]\n\nJust don't use 'subscribe list' and mutt won't mess up with\nmail-followup-to. Instead of using 'l' to reply-to-list keep using 'g'\nto reply to everyone involved in the subthread and everything should be\nfine :>\n\n- ferdy\n\n-- \nFernando J. Pereda Garcimartín\n20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4\n"},{"id":"52926","messageId":"20070907183700.GC24713@hand.yhbt.net","threadId":"9782","inReplyTo":"20070907115130.GA1547@xp.machine.xx","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-07T18:37:00Z","receivedAt":"2007-09-07T18:37:00Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Peter Baumann wrote:\n> On Fri, Sep 07, 2007 at 12:13:23PM +0200, Lars Hjemli wrote:\n> > [btw: could you please stop messing with 'Mail-Followup-To:'? When\n> > replying to your mail, I don't want everyone _except_ you in the 'To:'\n> > header...]\n> > \n> \n> Sorry, I wasn't aware of that.\n> \n> I had a 'subscribe git@vger.kernel.org' in my muttrc and just pressed 'g'\n> for group reply. Reading the docs suggested to 'set followup_to=no' (as\n> I did before sending this message). Per default it is set to 'yes'.\n\nI don't have any \"subscribe
\" lines in my muttrc nor do I\nhave any followup_to settings in it. It's just default, and 'g' has\nalways managed to work fine.\n\n> Could anyone more experienced with mutt correct me if this was the wrong\n> fix for this problem (or even point me to the right documentation)?\n\nman 5 muttrc\n\nHowever, whatever you did seems to have worked as replying to this\nemail didn't drop your name from this.\n\n-- \nEric Wong\n"},{"id":"53114","messageId":"8c5c35580709150708k5acdeabdh17fc7ef30ee3eb79@mail.gmail.com","threadId":"9782","inReplyTo":"8c5c35580709070313l4b815ddbg70be8fb0aef4eefd@mail.gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-15T14:08:31Z","receivedAt":"2007-09-15T14:08:31Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/7/07, Lars Hjemli wrote:\n> On 9/7/07, Peter Baumann wrote:\n> > lets reset 'trunk' to its state before the merge and\n> > 'branch1' to the merge commit, before fixing the bug in 'branch1'.\n> >\n> > a-b-c-d-e trunk\n> > \\ \\\n> > \\ -x-y m branch1\n>\n> Yeah, this would certainly not be handled correctly by dcommit using\n> --first-parent (but it could be handled by (a correct implementation\n> of) --upstream).\n\nActually, I don't think there's any way to handle this correctly. The\ncurrent git-svn will do the right thing except in cases like the one\nyou described, and in these cases it can be _forced_ to do the right\nthing by editing the grafts file, so I'll drop the whole --upstream\nidea.\n\n--\nlarsh\n"},{"id":"53122","messageId":"20070915143743.GB4957@xp.machine.xx","threadId":"9782","inReplyTo":"8c5c35580709150708k5acdeabdh17fc7ef30ee3eb79@mail.gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-09-15T14:37:43Z","receivedAt":"2007-09-15T14:37:43Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Sat, Sep 15, 2007 at 04:08:31PM +0200, Lars Hjemli wrote:\n> On 9/7/07, Lars Hjemli wrote:\n> > On 9/7/07, Peter Baumann wrote:\n> > > lets reset 'trunk' to its state before the merge and\n> > > 'branch1' to the merge commit, before fixing the bug in 'branch1'.\n> > >\n> > > a-b-c-d-e trunk\n> > > \\ \\\n> > > \\ -x-y m branch1\n> >\n> > Yeah, this would certainly not be handled correctly by dcommit using\n> > --first-parent (but it could be handled by (a correct implementation\n> > of) --upstream).\n> \n> Actually, I don't think there's any way to handle this correctly. The\n> current git-svn will do the right thing except in cases like the one\n> you described, and in these cases it can be _forced_ to do the right\n> thing by editing the grafts file, so I'll drop the whole --upstream\n> idea.\n> \n\nWhat do you mean by editing the graft file? Remove (the wrong) parent\nfrom the merge commit by a graft? This will help you commit on the right\nbranch, but 7b02b85a66fee6b357e02f9e70dd0baa0fd24308 removes the\npossibility to get the same graph back, because now git-svn really\nhonors the graft in its rebase phase.\n\nSo you would get something like this back:\n\n a-b - c - d - e trunk\n \\\n \\ -x'-y'- m branch1\n\nNotice that you've lost the merge information :-(\n\n-Peter\n"},{"id":"53125","messageId":"8c5c35580709150824l6eb4fa40l7ef77db03a48af4b@mail.gmail.com","threadId":"9782","inReplyTo":"20070915143743.GB4957@xp.machine.xx","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-15T15:24:02Z","receivedAt":"2007-09-15T15:24:02Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/15/07, Peter Baumann wrote:\n> On Sat, Sep 15, 2007 at 04:08:31PM +0200, Lars Hjemli wrote:\n> > On 9/7/07, Lars Hjemli wrote:\n> > > On 9/7/07, Peter Baumann wrote:\n> > > > lets reset 'trunk' to its state before the merge and\n> > > > 'branch1' to the merge commit, before fixing the bug in 'branch1'.\n> > > >\n> > > > a-b-c-d-e trunk\n> > > > \\ \\\n> > > > \\ -x-y m branch1\n> > >\n> > > Yeah, this would certainly not be handled correctly by dcommit using\n> > > --first-parent (but it could be handled by (a correct implementation\n> > > of) --upstream).\n> >\n> > Actually, I don't think there's any way to handle this correctly. The\n> > current git-svn will do the right thing except in cases like the one\n> > you described, and in these cases it can be _forced_ to do the right\n> > thing by editing the grafts file, so I'll drop the whole --upstream\n> > idea.\n> >\n>\n> What do you mean by editing the graft file? Remove (the wrong) parent\n> from the merge commit by a graft?\n\nI imagined just changing the order of the parents.\n\n-- \nlarsh\n"},{"id":"53129","messageId":"20070915154935.GC4957@xp.machine.xx","threadId":"9782","inReplyTo":"8c5c35580709150824l6eb4fa40l7ef77db03a48af4b@mail.gmail.com","subject":"Re: [PATCH] git-svn: remove --first-parent, add --upstream","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-09-15T15:49:35Z","receivedAt":"2007-09-15T15:49:35Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Sat, Sep 15, 2007 at 05:24:02PM +0200, Lars Hjemli wrote:\n> On 9/15/07, Peter Baumann wrote:\n> > On Sat, Sep 15, 2007 at 04:08:31PM +0200, Lars Hjemli wrote:\n> > > On 9/7/07, Lars Hjemli wrote:\n> > > > On 9/7/07, Peter Baumann wrote:\n> > > > > lets reset 'trunk' to its state before the merge and\n> > > > > 'branch1' to the merge commit, before fixing the bug in 'branch1'.\n> > > > >\n> > > > > a-b-c-d-e trunk\n> > > > > \\ \\\n> > > > > \\ -x-y m branch1\n> > > >\n> > > > Yeah, this would certainly not be handled correctly by dcommit using\n> > > > --first-parent (but it could be handled by (a correct implementation\n> > > > of) --upstream).\n> > >\n> > > Actually, I don't think there's any way to handle this correctly. The\n> > > current git-svn will do the right thing except in cases like the one\n> > > you described, and in these cases it can be _forced_ to do the right\n> > > thing by editing the grafts file, so I'll drop the whole --upstream\n> > > idea.\n> > >\n> >\n> > What do you mean by editing the graft file? Remove (the wrong) parent\n> > from the merge commit by a graft?\n> \n> I imagined just changing the order of the parents.\n> \n\nDoh. I missed the obvious.\n\n-Peter\n"}]}