{"thread":{"id":"9553","subject":"[PATCH] git-svn: update documentation with CAVEATS section","startedAt":"2007-08-16T08:56:45Z","lastAt":"2007-08-23T07:48:51Z","messageCount":7,"participants":["Eric Wong","Junio C Hamano","David Kastrup"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"50865","messageId":"20070816085645.GA3159@soma","threadId":"9553","inReplyTo":null,"subject":"[PATCH] git-svn: update documentation with CAVEATS section","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-08-16T08:56:45Z","receivedAt":"2007-08-16T08:56:45Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Signed-off-by: Eric Wong \n---\n\n I've been meaning to do this for a while, hopefully this cuts\n down on the redundant mailing list traffic about these subjects.\n\n Documentation/git-svn.txt | 32 ++++++++++++++++++++++++++++++++\n 1 files changed, 32 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex 816340b..fbc5887 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -479,6 +479,38 @@ the user on the git side. git-svn does however follow copy\n history of the directory that it is tracking, however (much like\n how 'svn log' works).\n \n+CAVEATS\n+-------\n+\n+For the sake of simplicity and interoperating with a less-capable system\n+(SVN), it is recommended that all git-svn users clone, fetch and dcommit\n+directly from the SVN server, and avoid all git-clone/pull/merge/push\n+operations between git repositories and branches. The recommended\n+method of exchanging code between git branches and users is\n+git-format-patch and git-am, or just dcommiting to the SVN repository.\n+\n+Running 'git-merge' or 'git-pull' is NOT recommended on a branch you\n+plan to dcommit from. Subversion does not represent merges in any\n+reasonable or useful fashion; so users using Subversion cannot see any\n+merges you've made. Furthermore, if you merge or pull from a git branch\n+that is a mirror of an SVN branch, dcommit may commit to the wrong\n+branch.\n+\n+'git-clone' does not clone branches under the refs/remotes/ hierarchy or\n+any git-svn metadata, or config. So repositories created and managed with\n+using git-svn should use rsync(1) for cloning, if cloning is to be done\n+at all.\n+\n+Since 'dcommit' uses rebase internally, any git branches you git-push to\n+before dcommit on will require forcing an overwrite of the existing ref\n+on the remote repository. This is generally considered bad practice,\n+see the git-push(1) documentation for details.\n+\n+Do not use the --amend option of git-commit(1) on a change you've\n+already dcommitted. It is considered bad practice to --amend commits\n+you've already pushed to a remote repository for other users, and\n+dcommit with SVN is analogous to that.\n+\n BUGS\n ----\n \n-- \nEric Wong\n"},{"id":"51303","messageId":"7v4piri44r.fsf@gitster.siamese.dyndns.org","threadId":"9553","inReplyTo":"20070816085645.GA3159@soma","subject":"Re: [PATCH] git-svn: update documentation with CAVEATS section","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-22T22:41:24Z","receivedAt":"2007-08-22T22:41:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> I've been meaning to do this for a while, hopefully this cuts\n> down on the redundant mailing list traffic about these subjects.\n> ...\n> +CAVEATS\n> +-------\n> +\n> +For the sake of simplicity and interoperating with a less-capable system\n> +(SVN), it is recommended that all git-svn users clone, fetch and dcommit\n> +directly from the SVN server, and avoid all git-clone/pull/merge/push\n> +operations between git repositories and branches. The recommended\n> +method of exchanging code between git branches and users is\n> +git-format-patch and git-am, or just dcommiting to the SVN repository.\n> +\n> +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you\n> +plan to dcommit from. Subversion does not represent merges in any\n> +reasonable or useful fashion; so users using Subversion cannot see any\n> +merges you've made.\n\nOk, my ruling before 1.5.3 is to take this patch, and encourage\ninterested parties to help Eric adding reliable support for the\nfeature after that, if such is possible.\n"},{"id":"51304","messageId":"853aybkwsc.fsf@lola.goethe.zz","threadId":"9553","inReplyTo":"7v4piri44r.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-svn: update documentation with CAVEATS section","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-22T22:51:47Z","receivedAt":"2007-08-22T22:51:47Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> Eric Wong writes:\n>\n>> I've been meaning to do this for a while, hopefully this cuts\n>> down on the redundant mailing list traffic about these subjects.\n>> ...\n>> +CAVEATS\n>> +-------\n>> +\n>> +For the sake of simplicity and interoperating with a less-capable system\n>> +(SVN), it is recommended that all git-svn users clone, fetch and dcommit\n>> +directly from the SVN server, and avoid all git-clone/pull/merge/push\n>> +operations between git repositories and branches. The recommended\n>> +method of exchanging code between git branches and users is\n>> +git-format-patch and git-am, or just dcommiting to the SVN repository.\n>> +\n>> +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you\n>> +plan to dcommit from. Subversion does not represent merges in any\n>> +reasonable or useful fashion; so users using Subversion cannot see any\n>> +merges you've made.\n>\n> Ok, my ruling before 1.5.3 is to take this patch, and encourage\n> interested parties to help Eric adding reliable support for the\n> feature after that, if such is possible.\n\nCouldn't we at least get a _documentation_ of the current behavior\nwhen actually using git for branch work? Knowing what will fail how\nand when is not as good as things just working as one would expect,\nbut it certainly beats obscure warnings.\n\nFor example, I consider it rather unacceptable that nowhere is\ndocumented just _how_ git-svn chooses one Subversion branch to commit\nto.\n\nIt also drastically misrepresents the consequences: the problem is\n_not_ that users using Subversion cannot see merges. That is\nsomething that one can readily accept. The problem is that git-svn\nwill dcommit to a seemingly random branch.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51324","messageId":"20070823053009.GC4978@muzzle","threadId":"9553","inReplyTo":"853aybkwsc.fsf@lola.goethe.zz","subject":"Re: [PATCH] git-svn: update documentation with CAVEATS section","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-08-23T05:30:09Z","receivedAt":"2007-08-23T05:30:09Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"David Kastrup wrote:\n> Junio C Hamano writes:\n> \n> > Eric Wong writes:\n> >\n> >> I've been meaning to do this for a while, hopefully this cuts\n> >> down on the redundant mailing list traffic about these subjects.\n> >> ...\n> >> +CAVEATS\n> >> +-------\n> >> +\n> >> +For the sake of simplicity and interoperating with a less-capable system\n> >> +(SVN), it is recommended that all git-svn users clone, fetch and dcommit\n> >> +directly from the SVN server, and avoid all git-clone/pull/merge/push\n> >> +operations between git repositories and branches. The recommended\n> >> +method of exchanging code between git branches and users is\n> >> +git-format-patch and git-am, or just dcommiting to the SVN repository.\n> >> +\n> >> +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you\n> >> +plan to dcommit from. Subversion does not represent merges in any\n> >> +reasonable or useful fashion; so users using Subversion cannot see any\n> >> +merges you've made.\n> >\n> > Ok, my ruling before 1.5.3 is to take this patch, and encourage\n> > interested parties to help Eric adding reliable support for the\n> > feature after that, if such is possible.\n> \n> Couldn't we at least get a _documentation_ of the current behavior\n> when actually using git for branch work? Knowing what will fail how\n> and when is not as good as things just working as one would expect,\n> but it certainly beats obscure warnings.\n> \n> For example, I consider it rather unacceptable that nowhere is\n> documented just _how_ git-svn chooses one Subversion branch to commit\n> to.\n\ndcommit always chooses the last SVN branch it branched off from.\n\n> It also drastically misrepresents the consequences: the problem is\n> _not_ that users using Subversion cannot see merges. That is\n> something that one can readily accept. The problem is that git-svn\n> will dcommit to a seemingly random branch.\n\nInteresting, I've never considered it a problem (probably because\nI know and trust the code I wrote :). Good idea though.\n\nJunio: could you please apply the following trivial patch? Thanks.\n\n>From a8ae91019a2ededd0e3d455fdd78655c086ea3b3 Mon Sep 17 00:00:00 2001\nFrom: Eric Wong \nDate: Wed, 22 Aug 2007 22:14:31 -0700\nSubject: [PATCH] git-svn: dcommit prints out the URL to be committed to\n\nThis will print out the URL that dcommit will operate on.\nIf used with --dry-run this will print out the URL without\nmaking changes to the repository.\n\nSigned-off-by: Eric Wong \n---\n git-svn.perl | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex d162114..7a8ffd5 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -370,6 +370,7 @@ sub cmd_dcommit {\n \t$head ||= 'HEAD';\n \tmy @refs;\n \tmy ($url, $rev, $uuid, $gs) = working_head_info($head, \\@refs);\n+\tprint \"Committing to $url ...\\n\";\n \tunless ($gs) {\n \t\tdie \"Unable to determine upstream SVN information from \",\n \t\t \"$head history\\n\";\n-- \nEric Wong\n"},{"id":"51327","messageId":"85r6luiydb.fsf@lola.goethe.zz","threadId":"9553","inReplyTo":"20070823053009.GC4978@muzzle","subject":"Re: [PATCH] git-svn: update documentation with CAVEATS section","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-23T06:00:32Z","receivedAt":"2007-08-23T06:00:32Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Eric Wong writes:\n\n> David Kastrup wrote:\n>> Junio C Hamano writes:\n>> \n>> > Eric Wong writes:\n>> >\n>> >> I've been meaning to do this for a while, hopefully this cuts\n>> >> down on the redundant mailing list traffic about these subjects.\n>> >> ...\n>> >> +CAVEATS\n>> >> +-------\n>> >> +\n>> >> +For the sake of simplicity and interoperating with a less-capable system\n>> >> +(SVN), it is recommended that all git-svn users clone, fetch and dcommit\n>> >> +directly from the SVN server, and avoid all git-clone/pull/merge/push\n>> >> +operations between git repositories and branches. The recommended\n>> >> +method of exchanging code between git branches and users is\n>> >> +git-format-patch and git-am, or just dcommiting to the SVN repository.\n>> >> +\n>> >> +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you\n>> >> +plan to dcommit from. Subversion does not represent merges in any\n>> >> +reasonable or useful fashion; so users using Subversion cannot see any\n>> >> +merges you've made.\n>> >\n>> > Ok, my ruling before 1.5.3 is to take this patch, and encourage\n>> > interested parties to help Eric adding reliable support for the\n>> > feature after that, if such is possible.\n>> \n>> Couldn't we at least get a _documentation_ of the current behavior\n>> when actually using git for branch work? Knowing what will fail how\n>> and when is not as good as things just working as one would expect,\n>> but it certainly beats obscure warnings.\n>> \n>> For example, I consider it rather unacceptable that nowhere is\n>> documented just _how_ git-svn chooses one Subversion branch to commit\n>> to.\n>\n> dcommit always chooses the last SVN branch it branched off from.\n\nNo, it doesn't. That's the problem. If I do\ngit-merge master\nin a side branch, and do git-svn dcommit afterwards, the commit\ngoes to the master branch.\n\nWhich is utterly unexpected.\n\n>> It also drastically misrepresents the consequences: the problem is\n>> _not_ that users using Subversion cannot see merges. That is\n>> something that one can readily accept. The problem is that git-svn\n>> will dcommit to a seemingly random branch.\n>\n> Interesting, I've never considered it a problem (probably because\n> I know and trust the code I wrote :). Good idea though.\n>\n> Junio: could you please apply the following trivial patch? Thanks.\n>\n> From a8ae91019a2ededd0e3d455fdd78655c086ea3b3 Mon Sep 17 00:00:00 2001\n> From: Eric Wong \n> Date: Wed, 22 Aug 2007 22:14:31 -0700\n> Subject: [PATCH] git-svn: dcommit prints out the URL to be committed to\n>\n> This will print out the URL that dcommit will operate on.\n> If used with --dry-run this will print out the URL without\n> making changes to the repository.\n>\n> Signed-off-by: Eric Wong \nAcked-by: David Kastrup\n\nThis is already a _large_ help for avoiding clobbering the central\nrepository. But I stress that it would be much better if git-svn\ndcommit/rebase stayed exclusively on the branch that is associated\nwith it/fetching in the \"svn\" config section, like git does in general\nwith remotes. No random branch jumping after merges or (to be\n_really_ avoided) rebases and certainly after cherry-picking within\ngit.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51332","messageId":"20070823062631.GD4417@hand.yhbt.net","threadId":"9553","inReplyTo":"85r6luiydb.fsf@lola.goethe.zz","subject":"Re: [PATCH] git-svn: update documentation with CAVEATS section","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-08-23T06:26:31Z","receivedAt":"2007-08-23T06:26:31Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"David Kastrup wrote:\n> Eric Wong writes:\n> > David Kastrup wrote:\n> >> Junio C Hamano writes:\n> >> > Eric Wong writes:\n> >> >\n> >> >> I've been meaning to do this for a while, hopefully this cuts\n> >> >> down on the redundant mailing list traffic about these subjects.\n> >> >> ...\n> >> >> +CAVEATS\n> >> >> +-------\n> >> >> +\n> >> >> +For the sake of simplicity and interoperating with a less-capable system\n> >> >> +(SVN), it is recommended that all git-svn users clone, fetch and dcommit\n> >> >> +directly from the SVN server, and avoid all git-clone/pull/merge/push\n> >> >> +operations between git repositories and branches. The recommended\n> >> >> +method of exchanging code between git branches and users is\n> >> >> +git-format-patch and git-am, or just dcommiting to the SVN repository.\n> >> >> +\n> >> >> +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you\n> >> >> +plan to dcommit from. Subversion does not represent merges in any\n> >> >> +reasonable or useful fashion; so users using Subversion cannot see any\n> >> >> +merges you've made.\n> >> >\n> >> > Ok, my ruling before 1.5.3 is to take this patch, and encourage\n> >> > interested parties to help Eric adding reliable support for the\n> >> > feature after that, if such is possible.\n> >> \n> >> Couldn't we at least get a _documentation_ of the current behavior\n> >> when actually using git for branch work? Knowing what will fail how\n> >> and when is not as good as things just working as one would expect,\n> >> but it certainly beats obscure warnings.\n> >> \n> >> For example, I consider it rather unacceptable that nowhere is\n> >> documented just _how_ git-svn chooses one Subversion branch to commit\n> >> to.\n> >\n> > dcommit always chooses the last SVN branch it branched off from.\n> \n> No, it doesn't. That's the problem. If I do\n> git-merge master\n> in a side branch, and do git-svn dcommit afterwards, the commit\n> goes to the master branch.\n> \n> Which is utterly unexpected.\n\nOops, sorry I only read your response and forgot about the original\ntopic. Yes, merging between SVN branches in git breaks dcommit badly,\nwhich is why I advise against using it. I'll try to fix it when I've\ngot more free time.\n\n> This is already a _large_ help for avoiding clobbering the central\n> repository. But I stress that it would be much better if git-svn\n> dcommit/rebase stayed exclusively on the branch that is associated\n> with it/fetching in the \"svn\" config section, like git does in general\n> with remotes. No random branch jumping after merges or (to be\n> _really_ avoided) rebases and certainly after cherry-picking within\n> git.\n\nI think I see where you're coming from, now. git-svn doesn't ever\nassociate remotes with local branches in the .git/config like regular\ngit-clone.\n\nI just cloned git.git from kernel.org again to see that .git/config\nassociates a local branch with a remote branch like this:\n\n----------------------------------------------------------------\n[branch \"master\"]\n remote = origin\n merge = refs/heads/master\n----------------------------------------------------------------\n\nI used git before this feature ever existed, and got used to git without\never needing it myself. I've always had a good idea of where I branched\noff from last, or I can ask with \"gitk --all\" otherwise.\n\nSo yes, I'll shamefully admit that I've never used this feature of git\nand in my very quick (and sleepy) evaluation of it, it seems quite\nlimiting...\n\n-- \nEric Wong\n"},{"id":"51338","messageId":"86odgybsik.fsf@lola.quinscape.zz","threadId":"9553","inReplyTo":"20070823062631.GD4417@hand.yhbt.net","subject":"Re: [PATCH] git-svn: update documentation with CAVEATS section","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-23T07:48:51Z","receivedAt":"2007-08-23T07:48:51Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Eric Wong writes:\n\n> David Kastrup wrote:\n>\n>> This is already a _large_ help for avoiding clobbering the central\n>> repository. But I stress that it would be much better if git-svn\n>> dcommit/rebase stayed exclusively on the branch that is associated\n>> with it/fetching in the \"svn\" config section, like git does in\n>> general with remotes. No random branch jumping after merges or (to\n>> be _really_ avoided) rebases and certainly after cherry-picking\n>> within git.\n>\n> I think I see where you're coming from, now. git-svn doesn't ever\n> associate remotes with local branches in the .git/config like\n> regular git-clone.\n>\n> I just cloned git.git from kernel.org again to see that .git/config\n> associates a local branch with a remote branch like this:\n>\n> ----------------------------------------------------------------\n> [branch \"master\"]\n> remote = origin\n> merge = refs/heads/master\n> ----------------------------------------------------------------\n>\n> I used git before this feature ever existed, and got used to git\n> without ever needing it myself. I've always had a good idea of\n> where I branched off from last, or I can ask with \"gitk --all\"\n> otherwise.\n\nBut with -t support, git-svn already has a good notion about what\nbranch belongs to what remote.\n\n> So yes, I'll shamefully admit that I've never used this feature of\n> git and in my very quick (and sleepy) evaluation of it, it seems\n> quite limiting...\n\nOh, I don't mind being limited from wreaking havoc on a central\nrepository.\n\n-- \nDavid Kastrup\n"}]}