{"thread":{"id":"30541","subject":"[PATCH v4] git-svn: clarify the referent of dcommit's optional argument","startedAt":"2012-05-16T20:42:35Z","lastAt":"2012-05-17T02:27:41Z","messageCount":5,"participants":["Jon Seymour","Junio C Hamano","Eric Wong"],"isPatch":true,"patchVersion":4,"patchTotal":null},"messages":[{"id":"191609","messageId":"1337200956-9260-1-git-send-email-jon.seymour@gmail.com","threadId":"30541","inReplyTo":null,"subject":"[PATCH v4] git-svn: clarify the referent of dcommit's optional argument","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-05-16T20:42:35Z","receivedAt":"2012-05-16T20:42:35Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"The documentation of the dcommit subcommand is reworded to clarify that\nthe optional argument refers to a git branch, not an SVN branch.\n\nThe discussion of the optional argument is put into its own paragraph\nas is the guidance about using 'dcommit' in preference to 'set-tree'.\n\nThe section on REBASE vs. PULL/MERGE is reworded to incorporate the\nadvice to prefer 'git rebase' previously in the description of 'dcommit'.\n\nSigned-off-by: Jon Seymour <jon.seymour@gmail.com>\n---\n Documentation/git-svn.txt | 40 +++++++++++++++++++---------------------\n 1 file changed, 19 insertions(+), 21 deletions(-)\n\nRestore original meaning that pull/merge causes issues specifically \nwith set-tree A..B (not with set-tree A, in general).\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex 34ee785..4384ed9 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -189,18 +189,16 @@ and have no uncommitted changes.\n \tlast fetched commit from the upstream SVN.\n \n 'dcommit'::\n-\tCommit each diff from a specified head directly to the SVN\n+\tCommit each diff from the current branch directly to the SVN\n \trepository, and then rebase or reset (depending on whether or\n \tnot there is a diff between SVN and head).  This will create\n \ta revision in SVN for each commit in git.\n-\tIt is recommended that you run 'git svn' fetch and rebase (not\n-\tpull or merge) your commits against the latest changes in the\n-\tSVN repository.\n-\tAn optional revision or branch argument may be specified, and\n-\tcauses 'git svn' to do all work on that revision/branch\n-\tinstead of HEAD.\n-\tThis is advantageous over 'set-tree' (below) because it produces\n-\tcleaner, more linear history.\n++\n+When an optional git branch name (or a git commit object name)\n+is specified as an argument, the subcommand works on the specified\n+branch, not on the current branch.\n++\n+Use of 'dcommit' is preferred to 'set-tree' (below).\n +\n --no-rebase;;\n \tAfter committing, do not rebase or reset.\n@@ -800,18 +798,18 @@ have each person clone that repository with 'git clone':\n \n REBASE VS. PULL/MERGE\n ---------------------\n-\n-Originally, 'git svn' recommended that the 'remotes/git-svn' branch be\n-pulled or merged from.  This is because the author favored\n-`git svn set-tree B` to commit a single head rather than the\n-`git svn set-tree A..B` notation to commit multiple commits.\n-\n-If you use `git svn set-tree A..B` to commit several diffs and you do\n-not have the latest remotes/git-svn merged into my-branch, you should\n-use `git svn rebase` to update your work branch instead of `git pull` or\n-`git merge`.  `pull`/`merge` can cause non-linear history to be flattened\n-when committing into SVN, which can lead to merge commits reversing\n-previous commits in SVN.\n+Prefer to use 'git svn rebase' or 'git rebase', rather than\n+'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn'\n+branch. Doing so will keep the history of unintegrated commits linear with\n+respect to the upstream SVN repository and allow the use of the preferred\n+'git svn dcommit' subcommand to push unintegrated commits back into SVN.\n+\n+Originally, 'git svn' recommended that developers pulled or merged from\n+the 'git svn' branch.  This was because the author favored `git svn set-tree B`\n+to commit a single head rather than the `git svn set-tree A..B` notation to\n+commit multiple commits. Use of 'git pull' or 'git merge' with `git svn set-tree A...B` \n+will cause non-linear history will be flattened when committing into SVN and \n+this can lead to merge commits unexpectedly reversing previous commits in SVN.\n \n MERGE TRACKING\n --------------\n-- \n1.7.10.1.514.ge33c7ea\n"},{"id":"191610","messageId":"CAH3AnrqQDfx7s1fXBgKJmFtMA33CW9qx2tWSoenqSR0pVc63WQ@mail.gmail.com","threadId":"30541","inReplyTo":"1337200956-9260-1-git-send-email-jon.seymour@gmail.com","subject":"Re: [PATCH v4] git-svn: clarify the referent of dcommit's optional argument","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-05-16T20:45:39Z","receivedAt":"2012-05-16T20:45:39Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, May 17, 2012 at 6:42 AM, Jon Seymour <jon.seymour@gmail.com> wrote:\n> The documentation of the dcommit subcommand is reworded to clarify that\n> the optional argument refers to a git branch, not an SVN branch.\n>\n> The discussion of the optional argument is put into its own paragraph\n> as is the guidance about using 'dcommit' in preference to 'set-tree'.\n>\n> The section on REBASE vs. PULL/MERGE is reworded to incorporate the\n> advice to prefer 'git rebase' previously in the description of 'dcommit'.\n>\n> Signed-off-by: Jon Seymour <jon.seymour@gmail.com>\n> ---\n>  Documentation/git-svn.txt | 40 +++++++++++++++++++---------------------\n>  1 file changed, 19 insertions(+), 21 deletions(-)\n>\n> Restore original meaning that pull/merge causes issues specifically\n> with set-tree A..B (not with set-tree A, in general).\n>\n> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\n> index 34ee785..4384ed9 100644\n> --- a/Documentation/git-svn.txt\n> +++ b/Documentation/git-svn.txt\n> @@ -189,18 +189,16 @@ and have no uncommitted changes.\n>        last fetched commit from the upstream SVN.\n>\n>  'dcommit'::\n> -       Commit each diff from a specified head directly to the SVN\n> +       Commit each diff from the current branch directly to the SVN\n>        repository, and then rebase or reset (depending on whether or\n>        not there is a diff between SVN and head).  This will create\n>        a revision in SVN for each commit in git.\n> -       It is recommended that you run 'git svn' fetch and rebase (not\n> -       pull or merge) your commits against the latest changes in the\n> -       SVN repository.\n> -       An optional revision or branch argument may be specified, and\n> -       causes 'git svn' to do all work on that revision/branch\n> -       instead of HEAD.\n> -       This is advantageous over 'set-tree' (below) because it produces\n> -       cleaner, more linear history.\n> ++\n> +When an optional git branch name (or a git commit object name)\n> +is specified as an argument, the subcommand works on the specified\n> +branch, not on the current branch.\n> ++\n> +Use of 'dcommit' is preferred to 'set-tree' (below).\n>  +\n>  --no-rebase;;\n>        After committing, do not rebase or reset.\n> @@ -800,18 +798,18 @@ have each person clone that repository with 'git clone':\n>\n>  REBASE VS. PULL/MERGE\n>  ---------------------\n> -\n> -Originally, 'git svn' recommended that the 'remotes/git-svn' branch be\n> -pulled or merged from.  This is because the author favored\n> -`git svn set-tree B` to commit a single head rather than the\n> -`git svn set-tree A..B` notation to commit multiple commits.\n> -\n> -If you use `git svn set-tree A..B` to commit several diffs and you do\n> -not have the latest remotes/git-svn merged into my-branch, you should\n> -use `git svn rebase` to update your work branch instead of `git pull` or\n> -`git merge`.  `pull`/`merge` can cause non-linear history to be flattened\n> -when committing into SVN, which can lead to merge commits reversing\n> -previous commits in SVN.\n> +Prefer to use 'git svn rebase' or 'git rebase', rather than\n> +'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn'\n> +branch. Doing so will keep the history of unintegrated commits linear with\n> +respect to the upstream SVN repository and allow the use of the preferred\n> +'git svn dcommit' subcommand to push unintegrated commits back into SVN.\n> +\n> +Originally, 'git svn' recommended that developers pulled or merged from\n> +the 'git svn' branch.  This was because the author favored `git svn set-tree B`\n> +to commit a single head rather than the `git svn set-tree A..B` notation to\n> +commit multiple commits. Use of 'git pull' or 'git merge' with `git svn set-tree A...B`\n\nA...B -> A..B\n\nWill fix in next iteration, assuming Junio and Eric are otherwise\nhappy with the update.\n\njon.\n"},{"id":"191613","messageId":"7vzk97bv2j.fsf@alter.siamese.dyndns.org","threadId":"30541","inReplyTo":"CAH3AnrqQDfx7s1fXBgKJmFtMA33CW9qx2tWSoenqSR0pVc63WQ@mail.gmail.com","subject":"Re: [PATCH v4] git-svn: clarify the referent of dcommit's optional argument","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-16T22:49:24Z","receivedAt":"2012-05-16T22:49:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour <jon.seymour@gmail.com> writes:\n\n>> +Originally, 'git svn' recommended that developers pulled or merged from\n>> +the 'git svn' branch.  This was because the author favored `git svn set-tree B`\n>> +to commit a single head rather than the `git svn set-tree A..B` notation to\n>> +commit multiple commits. Use of 'git pull' or 'git merge' with `git svn set-tree A...B`\n>\n> A...B -> A..B\n>\n> Will fix in next iteration, assuming Junio and Eric are otherwise\n> happy with the update.\n\nI don't have an opinion on the latter half of the patch that is primarily\nabout the rationale given by \"the author\", i.e. Eric ;-), but the\ndescription of dcommit subcommand itself certainly looks simpler and more\nreadble to me.\n\nThanks.\n"},{"id":"191617","messageId":"CAH3AnrpCJZt0acr7f5C5kwCF+KxgzD3dbeT+g7Ko5uCMxNqU0Q@mail.gmail.com","threadId":"30541","inReplyTo":"7vzk97bv2j.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v4] git-svn: clarify the referent of dcommit's optional argument","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2012-05-17T01:46:56Z","receivedAt":"2012-05-17T01:46:56Z","isPatch":true,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, May 17, 2012 at 8:49 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jon Seymour <jon.seymour@gmail.com> writes:\n>\n>>> +Originally, 'git svn' recommended that developers pulled or merged from\n>>> +the 'git svn' branch.  This was because the author favored `git svn set-tree B`\n>>> +to commit a single head rather than the `git svn set-tree A..B` notation to\n>>> +commit multiple commits. Use of 'git pull' or 'git merge' with `git svn set-tree A...B`\n>>\n>> A...B -> A..B\n>>\n>> Will fix in next iteration, assuming Junio and Eric are otherwise\n>> happy with the update.\n>\n> I don't have an opinion on the latter half of the patch that is primarily\n> about the rationale given by \"the author\", i.e. Eric ;-), but the\n> description of dcommit subcommand itself certainly looks simpler and more\n> readble to me.\n>\n> Thanks.\n>\n>\n\nOk, I'll fix the ... issue mentioned above and (also some trailing\nwhitespace) once Eric has given his feedback or acknowledgement.\n\njon.\n"},{"id":"191619","messageId":"20120517022741.GA4093@dcvr.yhbt.net","threadId":"30541","inReplyTo":"CAH3AnrpCJZt0acr7f5C5kwCF+KxgzD3dbeT+g7Ko5uCMxNqU0Q@mail.gmail.com","subject":"Re: [PATCH v4] git-svn: clarify the referent of dcommit's optional argument","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2012-05-17T02:27:41Z","receivedAt":"2012-05-17T02:27:41Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jon Seymour <jon.seymour@gmail.com> wrote:\n> Ok, I'll fix the ... issue mentioned above and (also some trailing\n> whitespace) once Eric has given his feedback or acknowledgement.\n\nLooks good to me.  Can you be sure to wrap changes at <80 chars\n(I like big fonts :D)\n"}]}