{"thread":{"id":"8533","subject":"Is this an acceptable workflow in git-svn, or a user error?","startedAt":"2007-06-09T19:10:37Z","lastAt":"2007-06-10T07:49:14Z","messageCount":4,"participants":["Junio C Hamano","Eric Wong","Sam Vilain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44479","messageId":"7vy7itdjv6.fsf@assigned-by-dhcp.cox.net","threadId":"8533","inReplyTo":null,"subject":"Is this an acceptable workflow in git-svn, or a user error?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-09T19:10:37Z","receivedAt":"2007-06-09T19:10:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Suppose you are interacting with svn://some.where/ and you want\nto have a public git://my.svn/mirror.git maintained with your\neffort for others to consume.  I am wondering if the following\nworkflow, especially the push part, is kosher.\n\n----------------------------------------------------------------\n0. Priming the process\n\n$ (mkdir mirror.git && cd mirror.git && git init)\n\n$ mkdir private.git && cd private.git && git init\n$ git svn init svn://some.where/\n$ git push ../mirror.git/ refs/heads/master:refs/heads/master\n\nAfter this step, mirror.git would be in-sync with the SVN; we\nhaven't done any of our own development yet.\n\n1. Hack away\n\n$ edit/git-add/etc.\n$ git commit\n\n2. Publish the result\n\ngit push ../mirror.git/\n\n3. Re-sync with SVN\n\n$ git svn dcommit\n----------------------------------------------------------------\n\nI suspect that the above sequence is a user error, in that\nre-syncing with SVN using git-svn (either dcommit or rebase)\nwould need to redo the commits to embed SVN metadata, but the\npublic mirror now has commits made with git without such\nrewriting.  In other words, I suspect that \"git push\" should\nnever be done if you made changes on the git side since you\nsync'ed with the SVN.\n\nThe reason I am asking is that somebody on #git got in a very\nconfusing situation.  After the Re-sync, \"git push\" to the\nmirror would refuse because it is not a fast forward.  \"git\nfetch\" from the mirror reveals that what after 3. is done, we\nsee two identically-looking commits, one that was pushed (before\nre-sync with SVN) and the other (replaced because of re-sync)\nare different.\n\nIf that is the case, then I presume that the correct workflow\nwould be:\n\n1. Hack away\n2. Re-sync with SVN\n3. Publish the result; do not do anything between 2. and 3.\n\nIs my understanding correct?\n"},{"id":"44480","messageId":"20070609193835.GB32225@muzzle","threadId":"8533","inReplyTo":"7vy7itdjv6.fsf@assigned-by-dhcp.cox.net","subject":"Re: Is this an acceptable workflow in git-svn, or a user error?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-09T19:38:36Z","receivedAt":"2007-06-09T19:38:36Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> Suppose you are interacting with svn://some.where/ and you want\n> to have a public git://my.svn/mirror.git maintained with your\n> effort for others to consume.  I am wondering if the following\n> workflow, especially the push part, is kosher.\n> \n> ----------------------------------------------------------------\n> 0. Priming the process\n> \n> $ (mkdir mirror.git && cd mirror.git && git init)\n> \n> $ mkdir private.git && cd private.git && git init\n> $ git svn init svn://some.where/\n> $ git push ../mirror.git/ refs/heads/master:refs/heads/master\n> \n> After this step, mirror.git would be in-sync with the SVN; we\n> haven't done any of our own development yet.\n> \n> 1. Hack away\n> \n> $ edit/git-add/etc.\n> $ git commit\n> \n> 2. Publish the result\n> \n> git push ../mirror.git/\n> \n> 3. Re-sync with SVN\n> \n> $ git svn dcommit\n> ----------------------------------------------------------------\n> \n> I suspect that the above sequence is a user error, in that\n> re-syncing with SVN using git-svn (either dcommit or rebase)\n> would need to redo the commits to embed SVN metadata, but the\n> public mirror now has commits made with git without such\n> rewriting.  In other words, I suspect that \"git push\" should\n> never be done if you made changes on the git side since you\n> sync'ed with the SVN.\n\nYes.  This is an unfortunate sore point for git-svn users unfamiliar\nwith what rebase does (inside dcommit).  Users using the the old\n'set-tree' workflow are immune to this, but they have their own set of\ncomplications...\n\nUsing \"git push --force\" would work after dcommit, however that\nmakes extra work for people tracking the git mirror\n\n> The reason I am asking is that somebody on #git got in a very\n> confusing situation.  After the Re-sync, \"git push\" to the\n> mirror would refuse because it is not a fast forward.  \"git\n> fetch\" from the mirror reveals that what after 3. is done, we\n> see two identically-looking commits, one that was pushed (before\n> re-sync with SVN) and the other (replaced because of re-sync)\n> are different.\n> \n> If that is the case, then I presume that the correct workflow\n> would be:\n> \n> 1. Hack away\n> 2. Re-sync with SVN\n> 3. Publish the result; do not do anything between 2. and 3.\n> \n> Is my understanding correct?\n\nYes.  Since dcommit uses rebase, it'll rewrite history.\n\nThe \"git svn dcommit\" workflow is analogous to me making commits and\nmailing patches to you to apply to the mainline git.git.  When you apply\nthem to git.git, they'll be different than the commits I've made even\nthough they're only metadata changes.\n\n-- \nEric Wong\n"},{"id":"44537","messageId":"466BABFB.8080208@vilain.net","threadId":"8533","inReplyTo":"20070609193835.GB32225@muzzle","subject":"Re: Is this an acceptable workflow in git-svn, or a user error?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-06-10T07:44:59Z","receivedAt":"2007-06-10T07:44:59Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Eric Wong wrote:\n>> Is my understanding correct?\n>>     \n>\n> Yes.  Since dcommit uses rebase, it'll rewrite history.\n>   \n\nMaybe these new lightweight annotations could be a way around that?\n\nSam.\n"},{"id":"44539","messageId":"466BACFA.1000704@vilain.net","threadId":"8533","inReplyTo":"466BABFB.8080208@vilain.net","subject":"Re: Is this an acceptable workflow in git-svn, or a user error?","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-06-10T07:49:14Z","receivedAt":"2007-06-10T07:49:14Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Sam Vilain wrote:\n> Eric Wong wrote:\n>   \n>>> Is my understanding correct?\n>>>       \n>> Yes.  Since dcommit uses rebase, it'll rewrite history.  \n>>     \n> Maybe these new lightweight annotations could be a way around that?\n>   \n\nActually I don't think that will work either unless you start\nencapsulating extra git information (author/committer email/timestamps)\nin the svn commit somewhere, so that someone else fetching the commits\nfrom svn directly will end up with the same git commitid. And then\nthere's still the issue of merges.\n\nSam.\n"}]}