{"thread":{"id":"3480","subject":"git-svn and huge data and modifying the git-svn-HEAD branch directly","startedAt":"2006-02-27T17:59:50Z","lastAt":"2006-03-19T19:43:48Z","messageCount":33,"participants":["Nicolas Vilz 'niv'","Eric Wong","Jan Harkes","Martin Langhoff","Linus Torvalds","Andreas Ericsson","Josef Weidendorfer","Shawn Pearce","Junio C Hamano","Johannes Schindelin","Carl Worth","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16838","messageId":"62502.84.163.87.135.1141063190.squirrel@mail.geht-ab-wie-schnitzel.de","threadId":"3480","inReplyTo":null,"subject":"git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Nicolas Vilz 'niv'","fromEmail":"niv@iaglans.de","sentAt":"2006-02-27T17:59:50Z","receivedAt":"2006-02-27T17:59:50Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"hi everyone,\n\nas i mentioned, i do experimental work with git and svn... and i\nexperienced some problems with git when pulling much data from svn.\n\nActually that happens after i commit a revision with many and big files.\nAfter that i cannot do a git-svn fetch anymore because git-svn\ncomplains...\n\nfatal: Ref refs/heads/svn-git-HEAD is at\n504721bf4b2702d3e56cef69950f42a43568e846 but expected\n504721bf4b2702d3e56cef69950f42a43568e846\n\nnow i am a little confused about that... oh, i actually modified the\nsvn-git directly instead of a private working branch... perhaps that was\nnot intended.\n\nnow i am still on rev 2 on this branch but i updated it to rev 5 on the\nsvn-side...\n\nany hints?\n\nSincerly\nNicolas\n"},{"id":"16843","messageId":"20060227184641.GA21684@hand.yhbt.net","threadId":"3480","inReplyTo":"62502.84.163.87.135.1141063190.squirrel@mail.geht-ab-wie-schnitzel.de","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-27T18:46:41Z","receivedAt":"2006-02-27T18:46:41Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Nicolas Vilz 'niv' wrote:\n> hi everyone,\n> \n> as i mentioned, i do experimental work with git and svn... and i\n> experienced some problems with git when pulling much data from svn.\n> \n> Actually that happens after i commit a revision with many and big files.\n> After that i cannot do a git-svn fetch anymore because git-svn\n> complains...\n> \n> fatal: Ref refs/heads/svn-git-HEAD is at\n> 504721bf4b2702d3e56cef69950f42a43568e846 but expected\n> 504721bf4b2702d3e56cef69950f42a43568e846\n\nThose messages are from git-update-ref. What were some of the messages\nfrom git-svn leading up to that point?\n\n> now i am a little confused about that... oh, i actually modified the\n> svn-git directly instead of a private working branch... perhaps that was\n> not intended.\n\nYou should never, ever modify the git-svn-HEAD branch yourself.\nInterface branches should never be modified. It's the golden rule of\ninterfacing between different SCM interfaces. Sorry, I've been doing\nthings like this this for a while now I guess I didn't make it\nabundantly clear in the documentation.\n\n> now i am still on rev 2 on this branch but i updated it to rev 5 on the\n> svn-side...\n> \n> any hints?\n\nSave your current work in git-svn-HEAD to a private branch\n\n\tgit branch -b private git-svn-HEAD\n\nthen reset git-svn-HEAD to the last revision where it was managed by\ngit-svn fetch:\n\n\tgit-checkout git-svn-HEAD\n\tgit-log (look for the last commit with 'git-svn-id:' in it)\n\tgit-reset --hard \n\nNow go to your private branch:\n\n\tgit checkout private\n\nAnd continue working on your private branch as usual.\n\n-- \nEric Wong\n"},{"id":"16844","messageId":"20060227185557.GA32142@delft.aura.cs.cmu.edu","threadId":"3480","inReplyTo":"20060227184641.GA21684@hand.yhbt.net","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-02-27T18:55:57Z","receivedAt":"2006-02-27T18:55:57Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:\n> > now i am a little confused about that... oh, i actually modified the\n> > svn-git directly instead of a private working branch... perhaps that was\n> > not intended.\n> \n> You should never, ever modify the git-svn-HEAD branch yourself.\n> Interface branches should never be modified. It's the golden rule of\n> interfacing between different SCM interfaces. Sorry, I've been doing\n> things like this this for a while now I guess I didn't make it\n> abundantly clear in the documentation.\n\nIf it is not supposed to be changed by the user, maybe it could be\nstored as a tag.\n\nOr maybe another type of reference can be introduced. refs/remote/, for\nbranches we are tracking, but which should not be modified locally.\n\nJan\n"},{"id":"16846","messageId":"20060227190402.GA14199@localdomain","threadId":"3480","inReplyTo":"20060227184641.GA21684@hand.yhbt.net","subject":"[PATCH] contrib/git-svn: tell the user to not modify git-svn-HEAD directly","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-27T19:04:02Z","receivedAt":"2006-02-27T19:04:02Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"As a rule, interface branches to different SCMs should never be modified\ndirectly by the user. They are used exclusively for talking to the\nforeign SCM.\n\nSigned-off-by: Eric Wong \n\n---\n\n contrib/git-svn/git-svn.txt | 9 ++++++++-\n 1 files changed, 8 insertions(+), 1 deletions(-)\n\n4676a850ad5a9e4a88fa5dfba1ac231a58bffda1\ndiff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt\nindex b4b7789..b588a2a 100644\n--- a/contrib/git-svn/git-svn.txt\n+++ b/contrib/git-svn/git-svn.txt\n@@ -43,6 +43,11 @@ fetch::\n \tFetch unfetched revisions from the SVN_URL we are tracking.\n \trefs/heads/git-svn-HEAD will be updated to the latest revision.\n \n+\tNote: You should never attempt to modify the git-svn-HEAD branch\n+\toutside of git-svn. Instead, create a branch from git-svn-HEAD\n+\tand work on that branch. Use the 'commit' command (see below)\n+\tto write git commits back to git-svn-HEAD.\n+\n commit::\n \tCommit specified commit or tree objects to SVN. This relies on\n \tyour imported fetch data being up-to-date. This makes\n@@ -179,7 +184,9 @@ SVN repositories via one git repository.\n environment variable to a name other other than \"git-svn\" (the default)\n and git-svn will ignore the contents of the $GIT_DIR/git-svn directory\n and instead do all of its work in $GIT_DIR/$GIT_SVN_ID for that\n-invocation.\n+invocation. The interface branch will be $GIT_SVN_ID-HEAD, instead of\n+git-svn-HEAD. Any $GIT_SVN_ID-HEAD branch should never be modified\n+by the user outside of git-svn commands.\n \n ADDITIONAL FETCH ARGUMENTS\n --------------------------\n-- \n1.2.3.gfc24dc-dirty\n"},{"id":"16847","messageId":"20060227192422.GB9518@hand.yhbt.net","threadId":"3480","inReplyTo":"20060227185557.GA32142@delft.aura.cs.cmu.edu","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-27T19:24:22Z","receivedAt":"2006-02-27T19:24:22Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jan Harkes wrote:\n> On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:\n> > > now i am a little confused about that... oh, i actually modified the\n> > > svn-git directly instead of a private working branch... perhaps that was\n> > > not intended.\n> > \n> > You should never, ever modify the git-svn-HEAD branch yourself.\n> > Interface branches should never be modified. It's the golden rule of\n> > interfacing between different SCM interfaces. Sorry, I've been doing\n> > things like this this for a while now I guess I didn't make it\n> > abundantly clear in the documentation.\n> \n> If it is not supposed to be changed by the user, maybe it could be\n> stored as a tag.\n> \n> Or maybe another type of reference can be introduced. refs/remote/, for\n> branches we are tracking, but which should not be modified locally.\n\nEither of those could work for me. Changing git-svn-HEAD to become a\ntag would probably be easier (not having to update other tools, such as\ngit-fetch), but refs/remote may make more sense.\n\n-- \nEric Wong\n"},{"id":"16848","messageId":"62354.84.163.87.135.1141068867.squirrel@mail.geht-ab-wie-schnitzel.de","threadId":"3480","inReplyTo":"20060227184641.GA21684@hand.yhbt.net","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Nicolas Vilz 'niv'","fromEmail":"niv@iaglans.de","sentAt":"2006-02-27T19:34:27Z","receivedAt":"2006-02-27T19:34:27Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"> Nicolas Vilz 'niv' wrote:\n>> hi everyone,\n>>\n>> as i mentioned, i do experimental work with git and svn... and i\n>> experienced some problems with git when pulling much data from svn.\n>>\n>> Actually that happens after i commit a revision with many and big files.\n>> After that i cannot do a git-svn fetch anymore because git-svn\n>> complains...\n>>\n>> fatal: Ref refs/heads/svn-git-HEAD is at\n>> 504721bf4b2702d3e56cef69950f42a43568e846 but expected\n>> 504721bf4b2702d3e56cef69950f42a43568e846\n>\n> Those messages are from git-update-ref. What were some of the messages\n> from git-svn leading up to that point?\n>\n>> now i am a little confused about that... oh, i actually modified the\n>> svn-git directly instead of a private working branch... perhaps that was\n>> not intended.\n>\n> You should never, ever modify the git-svn-HEAD branch yourself.\n> Interface branches should never be modified. It's the golden rule of\n> interfacing between different SCM interfaces. Sorry, I've been doing\n> things like this this for a while now I guess I didn't make it\n> abundantly clear in the documentation.\n\nok, i experienced that on little modifications on the git-svn-HEAD branch\neither... so its really about modifying and not about the huge data\nammount...\n\n\n>> now i am still on rev 2 on this branch but i updated it to rev 5 on the\n>> svn-side...\n>>\n>> any hints?\n>\n> Save your current work in git-svn-HEAD to a private branch\n>\n> \tgit branch -b private git-svn-HEAD\n>\n> then reset git-svn-HEAD to the last revision where it was managed by\n> git-svn fetch:\n>\n> \tgit-checkout git-svn-HEAD\n> \tgit-log (look for the last commit with 'git-svn-id:' in it)\n> \tgit-reset --hard \n>\n> Now go to your private branch:\n>\n> \tgit checkout private\n>\n> And continue working on your private branch as usual.\n\nI will keep that in mind for the future. Fortunatelly i am still testing\nand i saved the git repository before experimenting with git-svn.\n\nHave you any suggestions howto migrate a git-repository to svn and then\nwork with git-svn on both of it? I tried cg-merge -j to merge my git\nbranch with the private git svn branch, i am allowed to modify safely.\n\nthat does work actually... now i can start getting this automated.\n\nperhaps i will write a patch with that automated script, when it is\nfinished, just to contribute git.\n\n\nSincerly\nNicolas\n"},{"id":"16850","messageId":"20060227202713.GB21684@hand.yhbt.net","threadId":"3480","inReplyTo":"62354.84.163.87.135.1141068867.squirrel@mail.geht-ab-wie-schnitzel.de","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-27T20:27:13Z","receivedAt":"2006-02-27T20:27:13Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Nicolas Vilz 'niv' wrote:\n> ok, i experienced that on little modifications on the git-svn-HEAD branch\n> either... so its really about modifying and not about the huge data\n> ammount...\n \nHuge data should not have anything to do with it. Well, besides\nincreasing the chance of somebody committing a conflicting commit while\nyou're in the middle of your commit. But hey, that's the nature of\ncentralized SCMs.\n\n> >> now i am still on rev 2 on this branch but i updated it to rev 5 on the\n> >> svn-side...\n> >>\n> >> any hints?\n> >\n> > Save your current work in git-svn-HEAD to a private branch\n> >\n> > \tgit branch -b private git-svn-HEAD\n> >\n> > then reset git-svn-HEAD to the last revision where it was managed by\n> > git-svn fetch:\n> >\n> > \tgit-checkout git-svn-HEAD\n> > \tgit-log (look for the last commit with 'git-svn-id:' in it)\n> > \tgit-reset --hard \n> >\n> > Now go to your private branch:\n> >\n> > \tgit checkout private\n> >\n> > And continue working on your private branch as usual.\n> \n> I will keep that in mind for the future. Fortunatelly i am still testing\n> and i saved the git repository before experimenting with git-svn.\n\n:)\n\n> Have you any suggestions howto migrate a git-repository to svn and then\n> work with git-svn on both of it? I tried cg-merge -j to merge my git\n> branch with the private git svn branch, i am allowed to modify safely.\n> \n> that does work actually... now i can start getting this automated.\n> \n> perhaps i will write a patch with that automated script, when it is\n> finished, just to contribute git.\n\nCool. I don't know much about cg-*, but I think I did more or less the\nsame thing (joining branches, but did the join on git-svn-HEAD instead\nof a git-only branch) using = arguments[1] to git-svn\nfetch.\n\n[1] - See the 'Additional Fetch Arguments' section of the manpage for\nmore info on this. I'll freely admit that the UI for this was an\naccident, but it works fairly well for me.\n\n-- \nEric Wong\n"},{"id":"16852","messageId":"62402.84.163.87.135.1141073234.squirrel@mail.geht-ab-wie-schnitzel.de","threadId":"3480","inReplyTo":"20060227202713.GB21684@hand.yhbt.net","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Nicolas Vilz 'niv'","fromEmail":"niv@iaglans.de","sentAt":"2006-02-27T20:47:14Z","receivedAt":"2006-02-27T20:47:14Z","isPatch":false,"sender":{"key":"niv@iaglans.de","avatar":"https://gravatar.com/avatar/e4d43a32d721241212d4edb1d2210327e28423c913071b4bfeeaa0ce15296110?d=mp&s=160"},"body":"Eric Wong wrote:\n> [1] - See the 'Additional Fetch Arguments' section of the manpage for\n> more info on this. I'll freely admit that the UI for this was an\n> accident, but it works fairly well for me.\n\nbtw, i think you have a typo in your man-page:\n---\n# Commit only the git commits you want to SVN::\n git-svn commit [ ...]\n# Commit all the git commits from my-branch that don't exist in SVN::\n git commit git-svn-HEAD..my-branch\n---\ni think the second one is intended to be \"git-svn commit\ngit-svn-HEAD..my-branch\", because you want to sync the SVN tree again, not\nanother git-tree i think...\n\nNicolas\n"},{"id":"16853","messageId":"20060227205545.GA17373@localdomain","threadId":"3480","inReplyTo":"62402.84.163.87.135.1141073234.squirrel@mail.geht-ab-wie-schnitzel.de","subject":"[PATCH] contrib/git-svn: correct commit example in manpage","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-02-27T20:55:45Z","receivedAt":"2006-02-27T20:55:45Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Thanks to Nicolas Vilz for noticing this.\n\nSigned-off-by: Eric Wong \n\n---\n\n contrib/git-svn/git-svn.txt | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\n125c2e90f26d8980f415f8066dcc84d02d95f03a\ndiff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt\nindex b588a2a..b290739 100644\n--- a/contrib/git-svn/git-svn.txt\n+++ b/contrib/git-svn/git-svn.txt\n@@ -159,7 +159,7 @@ Tracking and contributing to an Subversi\n # Commit only the git commits you want to SVN::\n \tgit-svn commit [ ...]\n # Commit all the git commits from my-branch that don't exist in SVN::\n-\tgit commit git-svn-HEAD..my-branch\n+\tgit-svn commit git-svn-HEAD..my-branch\n # Something is committed to SVN, pull the latest into your branch::\n \tgit-svn fetch && git pull . git-svn-HEAD\n # Append svn:ignore settings to the default git exclude file:\n-- \n1.2.3.g4676\n"},{"id":"16866","messageId":"46a038f90602271625y6c7e9072u372b8dd3662e272c@mail.gmail.com","threadId":"3480","inReplyTo":"20060227192422.GB9518@hand.yhbt.net","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-02-28T00:25:31Z","receivedAt":"2006-02-28T00:25:31Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 2/28/06, Eric Wong wrote:\n> > If it is not supposed to be changed by the user, maybe it could be\n> > stored as a tag.\n> >\n> > Or maybe another type of reference can be introduced. refs/remote/, for\n> > branches we are tracking, but which should not be modified locally.\n>\n> Either of those could work for me. Changing git-svn-HEAD to become a\n> tag would probably be easier (not having to update other tools, such as\n> git-fetch), but refs/remote may make more sense.\n\ngit-svn-HEAD \"moves\" so it's really a bad idea to have it as a tag.\nNothing within core git prevents it from moving, but I think that\nporcelains will start breaking. Tags and heads are the same thing,\nexcept that heads are expected to change (specifically, to move\nforward), and tags are expected to stand still.\n\nSomething else is needed -- a convention to mark a head as 'readonly'\nso that git-commit/cg-commit refuse to commit to it. cg-commit already\ndoes that for any head matching the name of a branch.\n\ncheers,\n\n\nmartin\n"},{"id":"16867","messageId":"Pine.LNX.4.64.0602271634410.22647@g5.osdl.org","threadId":"3480","inReplyTo":"46a038f90602271625y6c7e9072u372b8dd3662e272c@mail.gmail.com","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-28T00:41:26Z","receivedAt":"2006-02-28T00:41:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Feb 2006, Martin Langhoff wrote:\n> \n> git-svn-HEAD \"moves\" so it's really a bad idea to have it as a tag.\n> Nothing within core git prevents it from moving, but I think that\n> porcelains will start breaking. Tags and heads are the same thing,\n> except that heads are expected to change (specifically, to move\n> forward), and tags are expected to stand still.\n\nWell, I wouldn't say that tags are expected to stand still. Some kinds of \ntags are expected to move: a \"this is the last tested version\" tag would \nbe expected to move with testing. \n\nThat said, the movement is _different_ from a branch. A branch is expected \nto move _with_ development, while a tag is expected to either stay the \nsame, or move _after_ development.\n\nHowever, in many ways git really doesn't care much. The \"refs/heads\" \ndirectory is the only one that is really special, in that \"git checkout\" \nrefuses to check out a moving branch in anything but that subdirectory. \nThe \"tags\" subdirectory is slightly special to some helpers (like \"git \npull\"), which have flags to pull everythying in that subdirectory. \n\nBut other than those two pretty trivial issues, any ref under \"refs/\" \nshould work perfectly fine. I would argue that a specialized tracking tool \nmight well be better off without using either \"refs/heads\" _or_ \n\"refs/tags\", since those have accepted meaning outside of tracking.\n\nUsing a \"refs/remotes\" subdirectory makes tons of sense for something like \nthis. Or something even more specific, like \"refs/svn-tracking/\". Git \nshouldn't care - all the tools _should_ work fine with any subdirectory \nstructure.\n\n\t\tLinus\n"},{"id":"16868","messageId":"46a038f90602271658h35623e58o7237a1703e6f4abd@mail.gmail.com","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0602271634410.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-02-28T00:58:18Z","receivedAt":"2006-02-28T00:58:18Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 2/28/06, Linus Torvalds wrote:\n> On Tue, 28 Feb 2006, Martin Langhoff wrote:\n> > git-svn-HEAD \"moves\" so it's really a bad idea to have it as a tag.\n> > Nothing within core git prevents it from moving, but I think that\n> > porcelains will start breaking. Tags and heads are the same thing,\n> > except that heads are expected to change (specifically, to move\n> > forward), and tags are expected to stand still.\n>\n> Well, I wouldn't say that tags are expected to stand still. Some kinds of\n> tags are expected to move: a \"this is the last tested version\" tag would\n> be expected to move with testing.\n\nAlrighty... in my git projects where things like these matter, my\n\"latest tested\" and \"current in production\" refs are actually in\nrefs/heads.\n\n> That said, the movement is _different_ from a branch. A branch is expected\n> to move _with_ development, while a tag is expected to either stay the\n> same, or move _after_ development.\n\nGrumble. I'd say a head is expected to reliably move _forward_...\n\"with\" development, yes, but definitely forward. In my book a tag\nwouldn't move, but if I take your word for it, then a tag can perhaps\nchange arbitrarily?\n\nI'm not sure how much support we have in porcelains for \"tracking\" a\ntag if it starts changing. Right now I think we'd find all sorts of\nproblems, we'd need to think carefully what moving tags means for\nporcelains.\n\n> Or something even more specific, like \"refs/svn-tracking/\". Git\n> shouldn't care - all the tools _should_ work fine with any subdirectory\n> structure.\n\nI think the moving-forward (therefore is trackable) vs stays reliably\nin place distinction *is* useful. \"Moves randomly\" may also be useful,\nbut it should get a different treatment, because it's not \"trackable\".\n\nNot that git and porcelains can't deal with all this stuff. But if\nthere is a clear convention then porcelains can be smart and refuse to\ncommit to the wrong place... it'd be a bit of a UI enhancement\nperhaps?\n\n\nmartin\n"},{"id":"16931","messageId":"20060301065138.GC21684@hand.yhbt.net","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0602271634410.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2006-03-01T06:51:38Z","receivedAt":"2006-03-01T06:51:38Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Linus Torvalds wrote:\n> \n> \n> On Tue, 28 Feb 2006, Martin Langhoff wrote:\n> > \n> > git-svn-HEAD \"moves\" so it's really a bad idea to have it as a tag.\n> > Nothing within core git prevents it from moving, but I think that\n> > porcelains will start breaking. Tags and heads are the same thing,\n> > except that heads are expected to change (specifically, to move\n> > forward), and tags are expected to stand still.\n> \n> Using a \"refs/remotes\" subdirectory makes tons of sense for something like \n> this. Or something even more specific, like \"refs/svn-tracking/\". Git \n> shouldn't care - all the tools _should_ work fine with any subdirectory \n> structure.\n\nGit tools only work as long as the 'refs/{remotes,svn-tracking,...}/'\nprefix is specified. git-svn-HEAD (or any $GIT_SVN_ID-HEAD) does get\nspecified from the command-line quite often:\n\t\n\tgit checkout -b mine git-svn-HEAD\n\tgit-log git-svn-HEAD..head\n\tgit-svn commit git-svn-HEAD..mine\n\tgit-log mine..git-svn-HEAD\n\nShould rev-parse be taught to be less strict and look for basenames\nthat can't be found in heads/ and tags/ in other directories?\n\n-- \nEric Wong\n"},{"id":"16936","messageId":"44056BF1.6000109@op5.se","threadId":"3480","inReplyTo":"20060301065138.GC21684@hand.yhbt.net","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-01T09:40:01Z","receivedAt":"2006-03-01T09:40:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Eric Wong wrote:\n> Linus Torvalds wrote:\n> \n>>\n>>On Tue, 28 Feb 2006, Martin Langhoff wrote:\n>>\n>>>git-svn-HEAD \"moves\" so it's really a bad idea to have it as a tag.\n>>>Nothing within core git prevents it from moving, but I think that\n>>>porcelains will start breaking. Tags and heads are the same thing,\n>>>except that heads are expected to change (specifically, to move\n>>>forward), and tags are expected to stand still.\n>>\n>>\n>>Using a \"refs/remotes\" subdirectory makes tons of sense for something like \n>>this. Or something even more specific, like \"refs/svn-tracking/\". Git \n>>shouldn't care - all the tools _should_ work fine with any subdirectory \n>>structure.\n> \n> \n> Git tools only work as long as the 'refs/{remotes,svn-tracking,...}/'\n> prefix is specified. git-svn-HEAD (or any $GIT_SVN_ID-HEAD) does get\n> specified from the command-line quite often:\n> \t\n> \tgit checkout -b mine git-svn-HEAD\n> \tgit-log git-svn-HEAD..head\n> \tgit-svn commit git-svn-HEAD..mine\n> \tgit-log mine..git-svn-HEAD\n> \n> Should rev-parse be taught to be less strict and look for basenames\n> that can't be found in heads/ and tags/ in other directories?\n> \n\nIt already does. The search order is this, for a ref named 'foo':\n\t$GIT_DIR/foo\n\t$GIT_DIR/refs/foo\n\t$GIT_DIR/refs/tags/foo\n\t$GIT_DIR/refs/heads/foo\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16950","messageId":"Pine.LNX.4.64.0603010745320.22647@g5.osdl.org","threadId":"3480","inReplyTo":"44056BF1.6000109@op5.se","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-01T15:53:31Z","receivedAt":"2006-03-01T15:53:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Mar 2006, Andreas Ericsson wrote:\n>\n> Eric Wong wrote:\n> > \n> > Should rev-parse be taught to be less strict and look for basenames\n> > that can't be found in heads/ and tags/ in other directories?\n> \n> It already does. The search order is this, for a ref named 'foo':\n> \t$GIT_DIR/foo\n> \t$GIT_DIR/refs/foo\n> \t$GIT_DIR/refs/tags/foo\n> \t$GIT_DIR/refs/heads/foo\n\nYes, but I think Eric wanted to avoid having to write the prefix part, \nwhich git won't let you do right now.\n\nIf you have a ref in .git/refs/svn-tracker/git-svn-HEAD, you would have to \nwrite out all of \"svn-tracker/git-svn-HEAD\", because unlike a \"real \nbranch\", get_sha1() won't look into the \"svn-tracker\" without it being \nexplicitly mentioned.\n\nNow, some tools will actually do \"for_each_ref()\" and check the ref-name \nagainst each of them (so if you pass in \"foo\", it will check them afainst \n_any_ ref-subdirectory that contains \"foo\"). But get_sha1() won't.\n\nWe could fix get_sha1(), but part of the logic was that other \nsubdirectories are special, and as such they _should_ be mentioned, so \nthat a file in such a special directory isn't ever confused with a real \nbranch.\n\nBut if you were to use for example .git/refs/git-svn/tracking as the \nsvn-tracking reference head, and then you'd be perfectly able to use\n\n\tgit log git-svn/tracking..\n\nto see what you've done since the last svn import?\n\n(or use HEAD, if you prefer that over \"tracking\")\n\n\t\tLinus\n"},{"id":"16952","messageId":"4405C6BE.2000706@op5.se","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0603010745320.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-01T16:07:26Z","receivedAt":"2006-03-01T16:07:26Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> \n> On Wed, 1 Mar 2006, Andreas Ericsson wrote:\n> \n>>Eric Wong wrote:\n>>\n>>>Should rev-parse be taught to be less strict and look for basenames\n>>>that can't be found in heads/ and tags/ in other directories?\n>>\n>>It already does. The search order is this, for a ref named 'foo':\n>>\t$GIT_DIR/foo\n>>\t$GIT_DIR/refs/foo\n>>\t$GIT_DIR/refs/tags/foo\n>>\t$GIT_DIR/refs/heads/foo\n> \n> \n> Yes, but I think Eric wanted to avoid having to write the prefix part, \n> which git won't let you do right now.\n> \n> If you have a ref in .git/refs/svn-tracker/git-svn-HEAD, you would have to \n> write out all of \"svn-tracker/git-svn-HEAD\", because unlike a \"real \n> branch\", get_sha1() won't look into the \"svn-tracker\" without it being \n> explicitly mentioned.\n> \n> Now, some tools will actually do \"for_each_ref()\" and check the ref-name \n> against each of them (so if you pass in \"foo\", it will check them afainst \n> _any_ ref-subdirectory that contains \"foo\"). But get_sha1() won't.\n> \n\nDidn't know that. The day is not a complete waste then.\n\n\n> We could fix get_sha1(), but part of the logic was that other \n> subdirectories are special, and as such they _should_ be mentioned, so \n> that a file in such a special directory isn't ever confused with a real \n> branch.\n> \n> But if you were to use for example .git/refs/git-svn/tracking as the \n> svn-tracking reference head, and then you'd be perfectly able to use\n> \n> \tgit log git-svn/tracking..\n> \n> to see what you've done since the last svn import?\n> \n\nPersonally I'm all for namespace separation. I'm assuming the script has \nthe tracker-branch hardcoded anyway, so I don't really understand why it \nwould be necessary to keep other refs in a separate directory and, if it \n*is* necessary, why that subdirectory can't be .git/refs/heads/svn.\n\nEric mentioned earlier that the tracking-branch can't be committed to \n(ever), so the user convenience for searching other directories should \nbe nearly non-existant.\n\nPerhaps I'm missing something obvious. Perhaps I'm just stupid. Perhaps \nthe pub just opened and I don't feel like reading it twice to make sure \nI understood. ;)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"16953","messageId":"Pine.LNX.4.64.0603010821590.22647@g5.osdl.org","threadId":"3480","inReplyTo":"4405C6BE.2000706@op5.se","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-01T16:24:56Z","receivedAt":"2006-03-01T16:24:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Mar 2006, Andreas Ericsson wrote:\n> \n> Personally I'm all for namespace separation. I'm assuming the script has the\n> tracker-branch hardcoded anyway, so I don't really understand why it would be\n> necessary to keep other refs in a separate directory and, if it *is*\n> necessary, why that subdirectory can't be .git/refs/heads/svn.\n> \n> Eric mentioned earlier that the tracking-branch can't be committed to (ever),\n> so the user convenience for searching other directories should be nearly\n> non-existant.\n\nThe thing about it being .git/refs/heads/svn/xyzzy is that then you can do\n\n\tgit checkout svn/xyzzy\n\nand start modifying it. Which is exactly against the point: the thing is \n_not_ a branch and you must _not_ commit to it.\n\nIt's much more like a tag: it's a pointer to the last point of an \nsvn-import.\n\nSo I think it should either _be_ a tag (although Dscho worries about some \nbroken porcelain being confused by tags changing) or it should be in a \nnamespace all it's own. Not under .git/refs/heads/ at any point, because \nit is _not_ a head of development.\n\n\t\tLinus\n"},{"id":"16957","messageId":"200603011814.43573.Josef.Weidendorfer@gmx.de","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0603010821590.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-03-01T17:14:43Z","receivedAt":"2006-03-01T17:14:43Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 01 March 2006 17:24, Linus Torvalds wrote:\n> The thing about it being .git/refs/heads/svn/xyzzy is that then you can do\n> \n> \tgit checkout svn/xyzzy\n> \n> and start modifying it. Which is exactly against the point: the thing is \n> _not_ a branch and you must _not_ commit to it.\n> \n> It's much more like a tag: it's a pointer to the last point of an \n> svn-import.\n\nIsn't it the same with tracked branches of a remote git repo?\nWith this reasoning, all heads that git-clone clones aside from the\nspecial \"master\" should not be under .git/refs/heads, but better\nunder .git/refs/remotes// ?\n\n is \"origin\" in the case of git-clone, so .git/remotes/origin\nwould contain\n URL: http://host/repo.git\n Pull: master:remotes/origin/master\n\nThen there would not be the need for the confusing special branch \"origin\"\nafter cloning, as namespaces are separate.\n\nJosef\n"},{"id":"16960","messageId":"20060301172816.GA4090@spearce.org","threadId":"3480","inReplyTo":"200603011814.43573.Josef.Weidendorfer@gmx.de","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-03-01T17:28:16Z","receivedAt":"2006-03-01T17:28:16Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Josef Weidendorfer wrote:\n> On Wednesday 01 March 2006 17:24, Linus Torvalds wrote:\n> > The thing about it being .git/refs/heads/svn/xyzzy is that then you can do\n> > \n> > \tgit checkout svn/xyzzy\n> > \n> > and start modifying it. Which is exactly against the point: the thing is \n> > _not_ a branch and you must _not_ commit to it.\n> > \n> > It's much more like a tag: it's a pointer to the last point of an \n> > svn-import.\n> \n> Isn't it the same with tracked branches of a remote git repo?\n> With this reasoning, all heads that git-clone clones aside from the\n> special \"master\" should not be under .git/refs/heads, but better\n> under .git/refs/remotes// ?\n> \n> is \"origin\" in the case of git-clone, so .git/remotes/origin\n> would contain\n> URL: http://host/repo.git\n> Pull: master:remotes/origin/master\n> \n> Then there would not be the need for the confusing special branch \"origin\"\n> after cloning, as namespaces are separate.\n\nThis is a really good idea. It certainly would prevent polluting the\nheads namespace. And its a lot easier to explain to someone than the\nmapping in the Pull line usually is.\n\n-- \nShawn.\n"},{"id":"16962","messageId":"Pine.LNX.4.64.0603010935201.22647@g5.osdl.org","threadId":"3480","inReplyTo":"200603011814.43573.Josef.Weidendorfer@gmx.de","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-01T17:40:56Z","receivedAt":"2006-03-01T17:40:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Mar 2006, Josef Weidendorfer wrote:\n>\n> On Wednesday 01 March 2006 17:24, Linus Torvalds wrote:\n> > The thing about it being .git/refs/heads/svn/xyzzy is that then you can do\n> > \n> > \tgit checkout svn/xyzzy\n> > \n> > and start modifying it. Which is exactly against the point: the thing is \n> > _not_ a branch and you must _not_ commit to it.\n> > \n> > It's much more like a tag: it's a pointer to the last point of an \n> > svn-import.\n> \n> Isn't it the same with tracked branches of a remote git repo?\n> With this reasoning, all heads that git-clone clones aside from the\n> special \"master\" should not be under .git/refs/heads, but better\n> under .git/refs/remotes// ?\n\nYes, I think that would make tons of sense.\n\n> is \"origin\" in the case of git-clone, so .git/remotes/origin\n> would contain\n> URL: http://host/repo.git\n> Pull: master:remotes/origin/master\n> \n> Then there would not be the need for the confusing special branch \"origin\"\n> after cloning, as namespaces are separate.\n\nI think that would make things a lot more flexible, and yes, it sounds \nlike a good idea.\n\nHOWEVER.\n\nI think it's not only very common, but quite useful, to do what we do now, \nie\n\n\tgit log origin..\n\nto see \"what is in origin but not in HEAD\".\n\nSo there's a big usability issue: I don't think it's good to have to say\n\n\tgit log remotes/origin/master..\n\nto do the same.\n\nSo from a usability standpoint, we'd have to teach \"get_sha1()\" about \nparsing .git/remotes/* files if it cannot find a branch or a tag with that \nname (which it wouldn't be able to, since even if it were to walk the \ndirectories udner .git/refs/ recursively, it would be named \"master\" \nthere).\n\nBut if somebody does the get_sha1() magic, and Junio agrees, then I think \nit would be a great thing to do.\n\n\t\t\tLinus\n"},{"id":"16966","messageId":"200603011906.33433.Josef.Weidendorfer@gmx.de","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0603010935201.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-03-01T18:06:33Z","receivedAt":"2006-03-01T18:06:33Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 01 March 2006 18:40, Linus Torvalds wrote:\n> But if somebody does the get_sha1() magic, and Junio agrees, then I think \n> it would be a great thing to do.\n\nYes.\n\n\tgit log origin/master..\n\nis really not that bad. And if somebody complains about typing, git-clone\ncould get an option \"--remote-name=o\" to allow for\n\n\tgit log o/master..\n\nJosef\n"},{"id":"16968","messageId":"Pine.LNX.4.64.0603011023080.22647@g5.osdl.org","threadId":"3480","inReplyTo":"200603011906.33433.Josef.Weidendorfer@gmx.de","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-01T18:25:21Z","receivedAt":"2006-03-01T18:25:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Mar 2006, Josef Weidendorfer wrote:\n>\n> On Wednesday 01 March 2006 18:40, Linus Torvalds wrote:\n> > But if somebody does the get_sha1() magic, and Junio agrees, then I think \n> > it would be a great thing to do.\n> \n> Yes.\n> \n> \tgit log origin/master..\n> \n> is really not that bad\n\nIt really is.\n\nThink like a user. If I pull from \"origin\", then the name of that thing is \n\"origin\", not \"origin/master\" or \"o/master\". A user doesn't care what the \nremote branch name is - the whole _point_ of the .git/remotes/xyzzy file \nis to give a short description that includes the names of the branches you \npull from.\n\nThe good news is that \"get_sha1()\" shouldn't be that hard to extend on. \nJust add a case at the end that says \"do we have a .git/remotes/%s file, \nand if so, parse it\".\n\n\t\t\t\tLinus\n"},{"id":"16970","messageId":"7virqyf094.fsf@assigned-by-dhcp.cox.net","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0603010935201.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-01T19:11:51Z","receivedAt":"2006-03-01T19:11:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> But if somebody does the get_sha1() magic, and Junio agrees, then I think \n> it would be a great thing to do.\n\nI am inclined to agree here.\n\nSome caveats upfront, though.\n\nSince I was bitten at least once by attempting get_sha1() to\ndeal with ambiguous names (the issue was between heads and tags\nbut I think there are similar issues here) I am really reluctant\nto have the function look at anywhere other than heads/ and\ntags/ without explicit prefix.\n\nCurrently get_sha1_basic() says:\n\n\t* look in $GIT_DIR with these prefixes in turn and take\n the first match: \"\", \"refs\", \"refs/tags\", \"refs/heads\".\n\nThe extended one _would_ in addition say one of these things:\n\n\t* if none of the above prefixes work, try other\n directories under refs/ as prefixes and take the first\n match.\n\n\tor\n\n\t* if none of the above prefixes work, try other\n directories under refs/ as prefixes and if there is a\n unique match take it. If there are more than one\n match, do not take either.\n\nIn the context of get_sha1(), get_sha1_basic() is used like\nthis:\n\n\t* if get_sha1_basic() finds an answer, use it.\n Otherwise see if it is an abbreviated object name.\n\nThe behaviour of a naive implementation of the former would\ndepend on readdir() and traversal order, which makes (from the\nend user's point of view) a hard to understand confusion that is\nnot reproducible. Another repository cloned from such would\neven give you different answers.\n\nThe latter at first sounds sane, but it has a subtle issue,\nwhich was what bitten me previously between heads/ and tags/.\nIn that broken version, if you have a head called \"dead\" and a\ntag with the same name, neither was taken (\"they are not unique,\nso do not take either!\") and we ended up finding an object whose\nSHA1 name began with those two bytes 0xDE 0xAD. I do not think\nthis has happened in the field, fortunately, but it would have\nbeen quite hard to diagnose.\n\nSo if we were to do it, I would say do the latter, but be very\ncareful to make sure you fail the whole get_sha1() when you bail\nout of the \"try possible prefixes\" codepath because of\nambiguity. There may be other issues involved, but I wouldn't\nknow -- I reverted the \"do not take either if they are\nambiguous between heads/ and tags/\" patch primarily because of\nthe reason from the above paragraph, but also did not want to\ndeal with any other potential issues to keep my sanity ;-).\n"},{"id":"16975","messageId":"200603012126.30797.Josef.Weidendorfer@gmx.de","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0603011023080.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-03-01T20:26:30Z","receivedAt":"2006-03-01T20:26:30Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 01 March 2006 19:25, Linus Torvalds wrote:\n> > \tgit log origin/master..\n> > \n> > is really not that bad\n> \n> It really is.\n> \n> Think like a user. If I pull from \"origin\", then the name of that thing is \n> \"origin\", not \"origin/master\" or \"o/master\". A user doesn't care what the \n> remote branch name is - the whole _point_ of the .git/remotes/xyzzy file \n> is to give a short description that includes the names of the branches you \n> pull from.\n\nSo the get_sha1() magic should map \"origin\" to \"remote/origin/master\" (or instead\nhardcoded master the remote branch from the first \"Pull:\" line) ?\nThe ambiguity here would be that shortcut names of remote repositories should not be\nused as tag or head names...\n\nI think a big plus of this would be that gitk can show branches tracking remote ones\nwith another color.\n \n> The good news is that \"get_sha1()\" shouldn't be thse at hard to extend on. \n> Just add a case at the end that says \"do we have a .git/remotes/%s file, \n> and if so, parse it\".\n\nTo be able to say \"git log origin..\" you need the above magic, too.\n\nJosef\n"},{"id":"16976","messageId":"200603012154.16509.Josef.Weidendorfer@gmx.de","threadId":"3480","inReplyTo":"7virqyf094.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-03-01T20:54:16Z","receivedAt":"2006-03-01T20:54:16Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 01 March 2006 20:11, Junio C Hamano wrote:\n> The latter at first sounds sane, but it has a subtle issue,\n> which was what bitten me previously between heads/ and tags/.\n> In that broken version, if you have a head called \"dead\" and a\n> tag with the same name, neither was taken (\"they are not unique,\n> so do not take either!\") and we ended up finding an object whose\n> SHA1 name began with those two bytes 0xDE 0xAD. I do not think\n> this has happened in the field, fortunately, but it would have\n> been quite hard to diagnose.\n> \n> So if we were to do it, I would say do the latter, but be very\n> careful to make sure you fail the whole get_sha1() when you bail\n> out of the \"try possible prefixes\" codepath because of\n> ambiguity.\n\nYes.\nAny ambiguity is a source of confusion and user error. Better\nbail out. If it is not a performance problem, it would be better\nto integrate the check for abbreviated object name into the\nambiguity analysis, and not have 2 stages of searching.\nIt probably would be a good idea to print out the ambigous names\nwith the error message, so that you can copy&paste the correct\nfull name afterwards.\n\nIf we go for the .git/refs/remotes/... and have an ambiguity becaues\nof remote shortcut names, a error message pointing at a \"git-rename-remote\"\ncommand would be handy, allowing the user to cleanup the namespace.\n\n> There may be other issues involved, but I wouldn't \n> know -- I reverted the \"do not take either if they are\n> ambiguous between heads/ and tags/\" patch primarily because of\n> the reason from the above paragraph, but also did not want to\n> deal with any other potential issues to keep my sanity ;-).\n\nI think the real problem here is that names like \"dead\" can be interpreted\nas abbreviated object name. When you introduce such a name as head or tag,\nyou have a potential ambiguity which can get real at any time.\nPerhaps it would be good to print out a warning when the user is about to\ncreate a head or tag name which can be interpreted as abbreviated object name?\n\nJosef\n"},{"id":"16977","messageId":"Pine.LNX.4.63.0603012202250.9893@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3480","inReplyTo":"Pine.LNX.4.64.0603010821590.22647@g5.osdl.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-01T21:07:17Z","receivedAt":"2006-03-01T21:07:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 1 Mar 2006, Linus Torvalds wrote:\n\n> On Wed, 1 Mar 2006, Andreas Ericsson wrote:\n> > \n> > Personally I'm all for namespace separation. I'm assuming the script \n> > has the tracker-branch hardcoded anyway, so I don't really understand \n> > why it would be necessary to keep other refs in a separate directory \n> > and, if it *is* necessary, why that subdirectory can't be \n> > .git/refs/heads/svn.\n> > \n> > Eric mentioned earlier that the tracking-branch can't be committed to \n> > (ever), so the user convenience for searching other directories should \n> > be nearly non-existant.\n> \n> The thing about it being .git/refs/heads/svn/xyzzy is that then you can \n> do\n> \n> \tgit checkout svn/xyzzy\n> \n> _not_ a branch and you must _not_ commit to it.\n> \n> It's much more like a tag: it's a pointer to the last point of an \n> svn-import.\n> \n> So I think it should either _be_ a tag (although Dscho worries about some \n> broken porcelain being confused by tags changing) or it should be in a \n> namespace all it's own. Not under .git/refs/heads/ at any point, because \n> it is _not_ a head of development.\n\nI almost missed that you reference me in the email (often, I just delete \nthe email if the Subject is of no interest to me).\n\nI did not worry about broken porcelain. I saw broken porcelain. But that \nis more a broken concept than broken porcelain: in a distributed \nenvironment, there is no way to have a reliable tag. Think about it: \nwhenever you have two different versions of a tag, you cannot know which \none is the correct one.\n\nBut my worries do not matter at all for local tags.\n\nConceptually, however, the last point of a svnimport should *never* be a \ntag, but *always* a head.\n\nCiao,\nDscho\n"},{"id":"16981","messageId":"Pine.LNX.4.64.0603011325120.22647@g5.osdl.org","threadId":"3480","inReplyTo":"200603012126.30797.Josef.Weidendorfer@gmx.de","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-01T21:28:25Z","receivedAt":"2006-03-01T21:28:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Mar 2006, Josef Weidendorfer wrote:\n> \n> So the get_sha1() magic should map \"origin\" to \"remote/origin/master\" (or instead\n> hardcoded master the remote branch from the first \"Pull:\" line) ?\n\nRight.\n\n> The ambiguity here would be that shortcut names of remote repositories should not be\n> used as tag or head names...\n\nWell, it's not so much an ambiguity, since we'd always try tags and heads \nfirst. So it's just a fallback, the same way the short SHA1 hash is a \nfallback.\n\n> I think a big plus of this would be that gitk can show branches tracking remote ones\n> with another color.\n\nYes. And with a meaningful name.\n\n> To be able to say \"git log origin..\" you need the above magic, too.\n\nIt would all come automagically from just extending get_sha1().\n\n(Actually, technically you'd put it at the end of \"get_sha1_basic()\")\n\n\t\tLinus\n"},{"id":"16982","messageId":"46a038f90603011340k23327f11s6e3d9d69585a5188@mail.gmail.com","threadId":"3480","inReplyTo":"7virqyf094.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-03-01T21:40:41Z","receivedAt":"2006-03-01T21:40:41Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/2/06, Junio C Hamano wrote:\n> Linus Torvalds writes:\n>\n> > But if somebody does the get_sha1() magic, and Junio agrees, then I think\n> > it would be a great thing to do.\n>\n> I am inclined to agree here.\n\nAren't we doing a lot of work (changes in core git, and corresponding\nchanges in the porcelain) when simple changes in porcelain would\nsuffice? Let's imagine that\n\n - git-commit refuses to commit to a head that has a corresponding\nremote (cg-commit does this already with heads that match something in\n'branches')\n - git-$SCMimport scripts generate a semi-bogus remotes/headname entry\n - git-pull/push can spot and ignore the semi-bogus remotes/headname entry\n - this means that `touch remotes/foo` is now a cheap way of making\nthe head readonly\n - depending on the git-$SCMimport script, the remotes/headname file\ncan perhaps contain useful configuration data for the import, so\ngit-$SCMimport headname does the right thing.\n\ncheers,\n\n\nmartin\n"},{"id":"16993","messageId":"87zmk9zr42.wl%cworth@cworth.org","threadId":"3480","inReplyTo":"46a038f90603011340k23327f11s6e3d9d69585a5188@mail.gmail.com","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-03-01T23:23:41Z","receivedAt":"2006-03-01T23:23:41Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 2 Mar 2006 10:40:41 +1300, \"Martin Langhoff\" wrote:\n> \n> Aren't we doing a lot of work (changes in core git, and corresponding\n> changes in the porcelain) when simple changes in porcelain would\n> suffice? Let's imagine that\n\nThere might be a simpler change to solve the git-svn-HEAD issue. But I\nwas about to independently bring up the issue that I wanted to hide\naway the \"remote-tracking\" branches.\n\nI currently get a lot of noise in \"git branch\" output that are\nremote-tracking branches that I will never commit to. (I use a -origin\nsuffix to help me filter them out, but I'd prefer not to see them at\nall here.)\n\nMeanwhile, as I've been teaching new git users, I've had to carefully\nteach:\n\n1) Never commit to a branch name that appears on the right side of ':'\n in a Pull: refspec.\n\n2) BTW, that ':' might be only implicit. A refspec of \"branch\" is\n equivalent to \"branch:branch\" so don't commit to those either.\n\nThat's pretty painful, so I really think these remote-tracking refs\nbelong outside of refs/heads.\n\n-Carl\n"},{"id":"16996","messageId":"Pine.LNX.4.64.0603011538580.22647@g5.osdl.org","threadId":"3480","inReplyTo":"87zmk9zr42.wl%cworth@cworth.org","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-01T23:43:37Z","receivedAt":"2006-03-01T23:43:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 1 Mar 2006, Carl Worth wrote:\n\n> Meanwhile, as I've been teaching new git users, I've had to carefully\n> teach:\n> \n> 1) Never commit to a branch name that appears on the right side of ':'\n> in a Pull: refspec.\n> \n> 2) BTW, that ':' might be only implicit. A refspec of \"branch\" is\n> equivalent to \"branch:branch\" so don't commit to those either.\n> \n> That's pretty painful, so I really think these remote-tracking refs\n> belong outside of refs/heads.\n\nIn the same vein, I think the refs/remotes// \nnaming will make it possible for people who track multiple remotes to \nsanely work with the fact that they might track 10 separate branches from \nJeff, one branch from me, and a couple of branches from Greg in the same \ntree, without just going crazy.\n\nI agree that we could solve the \"don't touch that branch\" issue another \nway, by just making them read-only. But the reason I like the separate \nnamespace is that it just seems to organize the branches really well, and \nin an unambiguous - and logical - manner.\n\nI too find myself looking at \"git branch\" output, and a lot of it is stuff \nI don't really care about - much of it is just the branches I got for just \ntracking Junio's git repo.\n\n\t\tLinus\n"},{"id":"17670","messageId":"20060319191243.GB18185@pasky.or.cz","threadId":"3480","inReplyTo":"44056BF1.6000109@op5.se","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-19T19:12:44Z","receivedAt":"2006-03-19T19:12:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a letter\nwhere Andreas Ericsson said that...\n> It already does. The search order is this, for a ref named 'foo':\n> \t$GIT_DIR/foo\n> \t$GIT_DIR/refs/foo\n> \t$GIT_DIR/refs/tags/foo\n> \t$GIT_DIR/refs/heads/foo\n\nActually, I've hit this recently when supporting an unhappy user on\n#git, and I didn't manage to find anything in the archives (but perhaps\nI missed it). Is there a particular reason why tags are checked first\nthan branches?\n\nWhy not:\n\n(i) I _think_ that it would be less of a surprise if a branch would be\nchecked first.\n\n(ii) E.g. Cogito output (cg-status -g) is very confusing when you have a\nnaming clash - cg-object-id foo will show tag commit ID, but cg-status -g\nwill say that the \"foo\" branch has a different commit ID (and it is\n_right_).\n\n(iii) Many operations will stop making sense (cg-merge foo, and even\ncg-fetch foo will be confused), while in case of the opposite way I can't\nthink of any command still not making sense.\n\n(iv) A security hole when you auto-fetch tags from remote repositories\n- you could then be misled to merge something totally different when the\nattacker will introduce a naming clash to your refs hierarchy.\n\nActually, I'm almost inclined to suggest making Git fail violently in\ncase of an ambiguous name.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time. I think\nI have forgotten this before.\n"},{"id":"17671","messageId":"Pine.LNX.4.64.0603191134530.3826@g5.osdl.org","threadId":"3480","inReplyTo":"20060319191243.GB18185@pasky.or.cz","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-19T19:35:28Z","receivedAt":"2006-03-19T19:35:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 19 Mar 2006, Petr Baudis wrote:\n> \n> (i) I _think_ that it would be less of a surprise if a branch would be\n> checked first.\n\nYeah, I guess that's true.\n\n> Actually, I'm almost inclined to suggest making Git fail violently in\n> case of an ambiguous name.\n\nMaybe not fail, but at least warn very loudly.\n\n\t\tLinus\n"},{"id":"17673","messageId":"7vbqw2qky3.fsf@assigned-by-dhcp.cox.net","threadId":"3480","inReplyTo":"20060319191243.GB18185@pasky.or.cz","subject":"Re: git-svn and huge data and modifying the git-svn-HEAD branch directly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-19T19:43:48Z","receivedAt":"2006-03-19T19:43:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Actually, I'm almost inclined to suggest making Git fail violently in\n> case of an ambiguous name.\n\nI am also inclined to suggest that or alternatively making it\nwarn, but having been almost burned by a bug or two coming from\nthe complexity of implementing it, I am not so enthused to start\nhacking away again on this right now myself.\n"}]}