{"thread":{"id":"13019","subject":"Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags","startedAt":"2008-04-08T15:48:03Z","lastAt":"2008-04-09T11:28:56Z","messageCount":6,"participants":["Thomas Leonard","Björn Steinbrink"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"73852","messageId":"cd53a0140804080848r54bb1e6dq54b5cce62339d6d1@mail.gmail.com","threadId":"13019","inReplyTo":"20080407195610.13681.39351.malone@potassium.ubuntu.com","subject":"Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags","fromName":"Thomas Leonard","fromEmail":"talex5@gmail.com","sentAt":"2008-04-08T15:48:03Z","receivedAt":"2008-04-08T15:48:03Z","isPatch":false,"sender":{"key":"talex5@gmail.com","avatar":"https://gravatar.com/avatar/1c382c32e006b740b5b7e08a01e3276f4db2b615655a2a4e496a00f83ccb9f24?d=mp&s=160"},"body":"Hi.\n\nThe git-svn Ubuntu packager asked me to forward this here.\n\nSummary:\n\nWhen converting a subversion repository to GIT using git-svn, the tags\ndo not have the right parent. Each tag should be identical to a trunk\nrevision (which it was copied from), but because git-svn uses an\nearlier revision as the parent it appears that the same work was\nduplicated on two branches.\n\nExample:\n\ngit-svn clone https://zero-install.svn.sourceforge.net/svnroot/zero-install\n-T trunk/0publish -r1890:2072 -b releases/0publish\n\nThe git branch comes from r1894, yet the svn log shows that in\nincludes files from r2070:\n\n$ svn log https://zero-install.svn.sourceforge.net/svnroot/zero-install\n-r2071 -v\nr2071 | tal197 | 2007-11-10 19:40:45 +0000 (Sat, 10 Nov 2007) | 1 line\nChanged paths:\n   A /releases/0publish/0publish-0.12 (from /trunk/0publish:1968)\n   R /releases/0publish/0publish-0.12/0publish (from\n/trunk/0publish/0publish:2070)\n   R /releases/0publish/0publish-0.12/0publish.xml (from\n/trunk/0publish/0publish.xml:2070)\n   R /releases/0publish/0publish-0.12/release.py (from\n/trunk/0publish/release.py:2069)\n\nReleased 0.12\n\nhttps://bugs.launchpad.net/ubuntu/+source/git-core/+bug/163341\n\nThanks,\n\n\n---------- Forwarded message ----------\nFrom: Emil Sit <sit@amsterdam.lcs.mit.edu>\nDate: 7 Apr 2008 20:56\nSubject: [Bug 163341] Re: git-svn gets wrong parent revision for tags\n\n\nI know that git-svn may rely on various conventions for the use of git\n and use of svn but since I'm not really familiar with either, it sounds\n like this should best be handled by the upstream developers.  Git does\n not use a dedicated bug tracker but handles issues on the mailing list\n git@vger.kernel.org.  If you submit your patch there, you should get a\n pretty fast response and you can follow up with this bug.  In any event,\n if the bug is fixed upstream, the next version of Ubuntu will probably\n include the fix automatically.\n\n Can you handle the follow-up with the official git developers?  Thanks!\n\n\n --\n git-svn gets wrong parent revision for tags\n https://bugs.launchpad.net/bugs/163341\n You received this bug notification because you are a direct subscriber\n of the bug.\n\n\n-- \nDr Thomas Leonard\t\thttp://rox.sourceforge.net\nGPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1\n"},{"id":"73858","messageId":"20080408171502.GA6163@atjola.homenet","threadId":"13019","inReplyTo":"cd53a0140804080848r54bb1e6dq54b5cce62339d6d1@mail.gmail.com","subject":"Re: Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-04-08T17:15:02Z","receivedAt":"2008-04-08T17:15:02Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.04.08 16:48:03 +0100, Thomas Leonard wrote:\n> Hi.\n> \n> The git-svn Ubuntu packager asked me to forward this here.\n> \n> Summary:\n> \n> When converting a subversion repository to GIT using git-svn, the tags\n> do not have the right parent. Each tag should be identical to a trunk\n> revision (which it was copied from), but because git-svn uses an\n> earlier revision as the parent it appears that the same work was\n> duplicated on two branches.\n> \n> Example:\n> \n> git-svn clone https://zero-install.svn.sourceforge.net/svnroot/zero-install\n> -T trunk/0publish -r1890:2072 -b releases/0publish\n> \n> The git branch comes from r1894, yet the svn log shows that in\n> includes files from r2070:\n> \n> $ svn log https://zero-install.svn.sourceforge.net/svnroot/zero-install\n> -r2071 -v\n> r2071 | tal197 | 2007-11-10 19:40:45 +0000 (Sat, 10 Nov 2007) | 1 line\n> Changed paths:\n>    A /releases/0publish/0publish-0.12 (from /trunk/0publish:1968)\n>    R /releases/0publish/0publish-0.12/0publish (from\n> /trunk/0publish/0publish:2070)\n>    R /releases/0publish/0publish-0.12/0publish.xml (from\n> /trunk/0publish/0publish.xml:2070)\n>    R /releases/0publish/0publish-0.12/release.py (from\n> /trunk/0publish/release.py:2069)\n\nWell, SVN recorded useless, broken metadata.\n\nSVN itself believes that the branch was created from revision 1968. As\nthat revision didn't introduce any changes to trunk/0publish, there's no\ncommit for that revision in the git branch, so git-svn took the most\nrecent one instead (1894).\n\nFor the other three files, SVN reports that the files were replaced by\nversions from another branch. There's no immediate way to tell whether\nthose replacements make the branch equal to the more recent version of\ntrunk. So git-svn does it the safe way and reproduces what SVN told it\nto reproduce: A commit that creates a branch and changes some files.\n\nI guess sth. like this happened on the svn end:\nsvn cp trunk/0publish releases/0publish (at rev. 1968)\nsvn cp trunk/0publish/release.py releases/0publish (at rev. 2069)\n...\nsvn commit (whenever)\n\nSo the branch was \"incrementally\" created locally and SVN decided to\nrecord the \"Uh, I copied this from here to there\" metacrap^H^H^H^Hdata,\nof which git-svn made use. Hooray for rename/copy tracking.\n\nYou could maybe ask for an enhancement so that git-svn tries to figure\nout if the provided metadata is broken and looks up a matching revision\nin such a case. But I guess it's not worth the trouble and could lead to\nother breakage along the way...\n\nBjörn\n"},{"id":"73877","messageId":"cd53a0140804081343l4b791dc3x5fa3fb294af71621@mail.gmail.com","threadId":"13019","inReplyTo":"20080408171502.GA6163@atjola.homenet","subject":"Re: Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags","fromName":"Thomas Leonard","fromEmail":"talex5@gmail.com","sentAt":"2008-04-08T20:43:03Z","receivedAt":"2008-04-08T20:43:03Z","isPatch":false,"sender":{"key":"talex5@gmail.com","avatar":"https://gravatar.com/avatar/1c382c32e006b740b5b7e08a01e3276f4db2b615655a2a4e496a00f83ccb9f24?d=mp&s=160"},"body":"On 08/04/2008, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:\n> On 2008.04.08 16:48:03 +0100, Thomas Leonard wrote:\n[...]\n>  > When converting a subversion repository to GIT using git-svn, the tags\n>  > do not have the right parent. Each tag should be identical to a trunk\n>  > revision (which it was copied from), but because git-svn uses an\n>  > earlier revision as the parent it appears that the same work was\n>  > duplicated on two branches.\n[...]\n>  > git-svn clone https://zero-install.svn.sourceforge.net/svnroot/zero-install\n>  > -T trunk/0publish -r1890:2072 -b releases/0publish\n>  >\n>  > The git branch comes from r1894, yet the svn log shows that in\n>  > includes files from r2070:\n>  >\n>  > $ svn log https://zero-install.svn.sourceforge.net/svnroot/zero-install\n>  > -r2071 -v\n>  > r2071 | tal197 | 2007-11-10 19:40:45 +0000 (Sat, 10 Nov 2007) | 1 line\n>  > Changed paths:\n>  >    A /releases/0publish/0publish-0.12 (from /trunk/0publish:1968)\n>  >    R /releases/0publish/0publish-0.12/0publish (from\n>  > /trunk/0publish/0publish:2070)\n>  >    R /releases/0publish/0publish-0.12/0publish.xml (from\n>  > /trunk/0publish/0publish.xml:2070)\n>  >    R /releases/0publish/0publish-0.12/release.py (from\n>  > /trunk/0publish/release.py:2069)\n>\n> Well, SVN recorded useless, broken metadata.\n\nThis is certainly true ;-)\n\n>  SVN itself believes that the branch was created from revision 1968. As\n>  that revision didn't introduce any changes to trunk/0publish, there's no\n>  commit for that revision in the git branch, so git-svn took the most\n>  recent one instead (1894).\n\n>  For the other three files, SVN reports that the files were replaced by\n>  versions from another branch. There's no immediate way to tell whether\n>  those replacements make the branch equal to the more recent version of\n>  trunk. So git-svn does it the safe way and reproduces what SVN told it\n>  to reproduce: A commit that creates a branch and changes some files.\n>\n>  I guess sth. like this happened on the svn end:\n>  svn cp trunk/0publish releases/0publish (at rev. 1968)\n>  svn cp trunk/0publish/release.py releases/0publish (at rev. 2069)\n>  ...\n>  svn commit (whenever)\n\nThe script that made the releases simply did this (\".\" is the working copy):\n\nsvn cp -m \"Released $VERSION\" . http://...\n\nSince each file in an svn working copy has its own revision (the last\ntime it was changed), the branch ends up with multiple source\nrevisions, even if the working copy is fully up-to-date and has no\nlocal changes.\n\nExample:\n\ncd /tmp\nsvnadmin create test-repo\nsvn mkdir file:///tmp/test-repo/trunk -m 'Setup'\nsvn co file:///tmp/test-repo/trunk\ncd trunk\ntouch foo bar\nsvn add foo bar\nsvn ci -m 'Start'\necho hi > bar\nsvn ci -m 'Update'\nsvn cp . file:///tmp/test-repo/release -m 'Release'\nsvn log -v file:///tmp/test-repo\n\nThe log shows:\n\n------------------------------------------------------------------------\nr4 | talex | 2008-04-08 21:35:44 +0100 (Tue, 08 Apr 2008) | 1 line\nChanged paths:\n   A /release (from /trunk:1)\n   A /release/bar (from /trunk/bar:3)\n   A /release/foo (from /trunk/foo:2)\n\nRelease\n\nSo, I don't think the metadata is broken in this case. Maybe other\npeople don't create branches like this, but it seemed like the obvious\nway to do it at the time. Given this behaviour of svn, perhaps it\nwould be better to take the highest version number as the branch\npoint?\n\n\n-- \nDr Thomas Leonard\t\thttp://rox.sourceforge.net\nGPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1\n"},{"id":"73933","messageId":"20080409080333.GA13892@atjola.homenet","threadId":"13019","inReplyTo":"cd53a0140804081343l4b791dc3x5fa3fb294af71621@mail.gmail.com","subject":"Re: Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-04-09T08:03:33Z","receivedAt":"2008-04-09T08:03:33Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"[Grmpf, the next time you drop from me Cc:, I'll not bother to\nanswer...]\n\nOn 2008.04.08 21:43:03 +0100, Thomas Leonard wrote:\n> On 08/04/2008, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:\n> > On 2008.04.08 16:48:03 +0100, Thomas Leonard wrote:\n> [...]\n> >  > When converting a subversion repository to GIT using git-svn, the tags\n> >  > do not have the right parent. Each tag should be identical to a trunk\n> >  > revision (which it was copied from), but because git-svn uses an\n> >  > earlier revision as the parent it appears that the same work was\n> >  > duplicated on two branches.\n> [...]\n> >  > git-svn clone https://zero-install.svn.sourceforge.net/svnroot/zero-install\n> >  > -T trunk/0publish -r1890:2072 -b releases/0publish\n> >  >\n> >  > The git branch comes from r1894, yet the svn log shows that in\n> >  > includes files from r2070:\n> >  >\n> >  > $ svn log https://zero-install.svn.sourceforge.net/svnroot/zero-install\n> >  > -r2071 -v\n> >  > r2071 | tal197 | 2007-11-10 19:40:45 +0000 (Sat, 10 Nov 2007) | 1 line\n> >  > Changed paths:\n> >  >    A /releases/0publish/0publish-0.12 (from /trunk/0publish:1968)\n> >  >    R /releases/0publish/0publish-0.12/0publish (from\n> >  > /trunk/0publish/0publish:2070)\n> >  >    R /releases/0publish/0publish-0.12/0publish.xml (from\n> >  > /trunk/0publish/0publish.xml:2070)\n> >  >    R /releases/0publish/0publish-0.12/release.py (from\n> >  > /trunk/0publish/release.py:2069)\n> >\n> > Well, SVN recorded useless, broken metadata.\n> \n> This is certainly true ;-)\n> \n> >  SVN itself believes that the branch was created from revision 1968. As\n> >  that revision didn't introduce any changes to trunk/0publish, there's no\n> >  commit for that revision in the git branch, so git-svn took the most\n> >  recent one instead (1894).\n> \n> >  For the other three files, SVN reports that the files were replaced by\n> >  versions from another branch. There's no immediate way to tell whether\n> >  those replacements make the branch equal to the more recent version of\n> >  trunk. So git-svn does it the safe way and reproduces what SVN told it\n> >  to reproduce: A commit that creates a branch and changes some files.\n> >\n> >  I guess sth. like this happened on the svn end:\n> >  svn cp trunk/0publish releases/0publish (at rev. 1968)\n> >  svn cp trunk/0publish/release.py releases/0publish (at rev. 2069)\n> >  ...\n> >  svn commit (whenever)\n> \n> The script that made the releases simply did this (\".\" is the working copy):\n> \n> svn cp -m \"Released $VERSION\" . http://...\n> \n> Since each file in an svn working copy has its own revision (the last\n> time it was changed), the branch ends up with multiple source\n> revisions, even if the working copy is fully up-to-date and has no\n> local changes.\n> \n> Example:\n> \n> cd /tmp\n> svnadmin create test-repo\n> svn mkdir file:///tmp/test-repo/trunk -m 'Setup'\n> svn co file:///tmp/test-repo/trunk\n> cd trunk\n> touch foo bar\n> svn add foo bar\n> svn ci -m 'Start'\n> echo hi > bar\n> svn ci -m 'Update'\n> svn cp . file:///tmp/test-repo/release -m 'Release'\n> svn log -v file:///tmp/test-repo\n> \n> The log shows:\n> \n> ------------------------------------------------------------------------\n> r4 | talex | 2008-04-08 21:35:44 +0100 (Tue, 08 Apr 2008) | 1 line\n> Changed paths:\n>    A /release (from /trunk:1)\n>    A /release/bar (from /trunk/bar:3)\n>    A /release/foo (from /trunk/foo:2)\n> \n> Release\n\nChange the \".\" to \"file:///tmp/test-repo/trunk\" in the svn cp command\nand you get:\nChanged paths:\n   A /release (from /trunk:3)\n\nSeems more useful. No idea why SVN decides to record crap when you use\n\".\", even when your working copy is clean.\n\n> So, I don't think the metadata is broken in this case. Maybe other\n> people don't create branches like this, but it seemed like the obvious\n> way to do it at the time. Given this behaviour of svn, perhaps it\n> would be better to take the highest version number as the branch\n> point?\n\nUhm, and what happens then, when you actually _did_ just copy over a\nfew files, but not all of them? Right, you get a branch to start at a\nlater revision and see a bunch of reverts. Equally broken.\n\nBjörn\n"},{"id":"73947","messageId":"cd53a0140804090339h472bc672ucd84b0ff13e2eeee@mail.gmail.com","threadId":"13019","inReplyTo":"20080409080333.GA13892@atjola.homenet","subject":"Re: Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags","fromName":"Thomas Leonard","fromEmail":"talex5@gmail.com","sentAt":"2008-04-09T10:39:17Z","receivedAt":"2008-04-09T10:39:17Z","isPatch":false,"sender":{"key":"talex5@gmail.com","avatar":"https://gravatar.com/avatar/1c382c32e006b740b5b7e08a01e3276f4db2b615655a2a4e496a00f83ccb9f24?d=mp&s=160"},"body":"On 09/04/2008, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:\n> [Grmpf, the next time you drop from me Cc:, I'll not bother to\n>  answer...]\n\nFixed; sorry.\n\n>  On 2008.04.08 21:43:03 +0100, Thomas Leonard wrote:\n[...]\n>  > The script that made the releases simply did this (\".\" is the working copy):\n>  >\n>  > svn cp -m \"Released $VERSION\" . http://...\n>  >\n>  > Since each file in an svn working copy has its own revision (the last\n>  > time it was changed), the branch ends up with multiple source\n>  > revisions, even if the working copy is fully up-to-date and has no\n>  > local changes.\n>  >\n>  > Example:\n>  >\n>  > cd /tmp\n>  > svnadmin create test-repo\n>  > svn mkdir file:///tmp/test-repo/trunk -m 'Setup'\n>  > svn co file:///tmp/test-repo/trunk\n>  > cd trunk\n>  > touch foo bar\n>  > svn add foo bar\n>  > svn ci -m 'Start'\n>  > echo hi > bar\n>  > svn ci -m 'Update'\n>  > svn cp . file:///tmp/test-repo/release -m 'Release'\n>  > svn log -v file:///tmp/test-repo\n>  >\n>  > The log shows:\n>  >\n>  > ------------------------------------------------------------------------\n>  > r4 | talex | 2008-04-08 21:35:44 +0100 (Tue, 08 Apr 2008) | 1 line\n>  > Changed paths:\n>  >    A /release (from /trunk:1)\n>  >    A /release/bar (from /trunk/bar:3)\n>  >    A /release/foo (from /trunk/foo:2)\n>  >\n>  > Release\n>\n> Change the \".\" to \"file:///tmp/test-repo/trunk\" in the svn cp command\n>  and you get:\n>  Changed paths:\n>    A /release (from /trunk:3)\n>\n>  Seems more useful. No idea why SVN decides to record crap when you use\n>  \".\", even when your working copy is clean.\n\nThat's good advice, but I'm wondering how to convert my existing svn\nrepositories to GIT.\n\n>  > So, I don't think the metadata is broken in this case. Maybe other\n>  > people don't create branches like this, but it seemed like the obvious\n>  > way to do it at the time. Given this behaviour of svn, perhaps it\n>  > would be better to take the highest version number as the branch\n>  > point?\n>\n> Uhm, and what happens then, when you actually _did_ just copy over a\n>  few files, but not all of them? Right, you get a branch to start at a\n>  later revision and see a bunch of reverts. Equally broken.\n\nSure, if you create a situation that GIT can't represent then there's\nnothing much git-svn can do.\n\nHowever, when there are different source revisions:\n\n- Taking the highest revision will give correct results in the common\ncase, and \"equally broken\" results in the uncommon case.\n\n- Taking any other revision (the current behaviour) is guaranteed to\ngive the wrong result. There's no way a branch that was created with a\nfile from revision 6 can possibly be a branch of revision 5, for\nexample.\n\nAlso, the current behaviour can be wildly out (e.g. revision 1894 when\nit should have been 2070, in the previous real example). The highest\nrevision is unlikely to be far off.\n\n\n-- \nDr Thomas Leonard\t\thttp://rox.sourceforge.net\nGPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1\n"},{"id":"73952","messageId":"20080409112856.GB16607@atjola.homenet","threadId":"13019","inReplyTo":"cd53a0140804090339h472bc672ucd84b0ff13e2eeee@mail.gmail.com","subject":"Re: Fwd: [Bug 163341] Re: git-svn gets wrong parent revision for tags","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-04-09T11:28:56Z","receivedAt":"2008-04-09T11:28:56Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.04.09 11:39:17 +0100, Thomas Leonard wrote:\n> On 09/04/2008, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:\n> >  On 2008.04.08 21:43:03 +0100, Thomas Leonard wrote:\n> >  > The log shows:\n> >  >\n> >  > ------------------------------------------------------------------------\n> >  > r4 | talex | 2008-04-08 21:35:44 +0100 (Tue, 08 Apr 2008) | 1 line\n> >  > Changed paths:\n> >  >    A /release (from /trunk:1)\n> >  >    A /release/bar (from /trunk/bar:3)\n> >  >    A /release/foo (from /trunk/foo:2)\n> >  >\n> >  > Release\n> >\n> > Change the \".\" to \"file:///tmp/test-repo/trunk\" in the svn cp command\n> >  and you get:\n> >  Changed paths:\n> >    A /release (from /trunk:3)\n> >\n> >  Seems more useful. No idea why SVN decides to record crap when you use\n> >  \".\", even when your working copy is clean.\n> \n> That's good advice, but I'm wondering how to convert my existing svn\n> repositories to GIT.\n\nI'd probably patch git-svn locally once and revert it after the import,\nif your suggested change really makes sense for your repo. Another\noption would be to adjust the branches afterwards, but that's probably\nawkward in your case. Maybe a patch that allows to toggle the branch\ncreation logic would be accepted as well, dunno.\n\n> >  > So, I don't think the metadata is broken in this case. Maybe other\n> >  > people don't create branches like this, but it seemed like the obvious\n> >  > way to do it at the time. Given this behaviour of svn, perhaps it\n> >  > would be better to take the highest version number as the branch\n> >  > point?\n> >\n> > Uhm, and what happens then, when you actually _did_ just copy over a\n> >  few files, but not all of them? Right, you get a branch to start at a\n> >  later revision and see a bunch of reverts. Equally broken.\n> \n> Sure, if you create a situation that GIT can't represent then there's\n> nothing much git-svn can do.\n> \n> However, when there are different source revisions:\n> \n> - Taking the highest revision will give correct results in the common\n> case, and \"equally broken\" results in the uncommon case.\n> \n> - Taking any other revision (the current behaviour) is guaranteed to\n> give the wrong result. There's no way a branch that was created with a\n> file from revision 6 can possibly be a branch of revision 5, for\n> example.\n\nSure it can be.\n\nsvn co $repo full-repo-here\ncd full-repo-here\nsvn cp trunk branches/b1 (at rev 5)\necho 123 > trunk/foo # (new file)\necho 456 > trunk/bar\n# 431 other files changed (exaggeration ;-))\nsvn commit trunk -m \"Committing trunk only, with 433 files changed\"\nsvn cp trunk/foo branches/b1\nsvn commit branches/b1 -m \"Committing b1.\"\n\nb1 branched at rev 5, but has a single file from rev 6.\n\nCurrently, git-svn would create the branch starting at rev5, with\nthe addition of \"foo\" on top.\n\nYour suggested change would make it branch at rev6 and revert 432 files.\n\nThe fact that svn just has directory copies as branches makes all kinds\nof junk possible ;-)\n\n> Also, the current behaviour can be wildly out (e.g. revision 1894 when\n> it should have been 2070, in the previous real example). The highest\n> revision is unlikely to be far off.\n\nHow many \"interesting\" revisions was it off by? 3? As the revision\nnumbers in svn are shared throughout the whole repo, your example sounds\nfar worse than it really is.\n\nAnd for locally prepared branches (I've actually heard of people doing\nthat, like in my example above), it can happen for your way to be way\nmore off than the current way.\n\nBjörn\n"}]}