{"thread":{"id":"9820","subject":"git-svn: Branching clarifications","startedAt":"2007-09-07T16:47:17Z","lastAt":"2007-09-08T07:58:53Z","messageCount":5,"participants":["Russ Brown","Eric Wong","David Kastrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"52921","messageId":"46E18095.60501@gmail.com","threadId":"9820","inReplyTo":null,"subject":"git-svn: Branching clarifications","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-07T16:47:17Z","receivedAt":"2007-09-07T16:47:17Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"I have a few questions about how/when to use git branches when using\ngit-svn (I'm a tad confused...)\n\nSay I've initialised and fetched a git repo involving trunk and one\nbranch (say branch1) from an svn repository.\n\nIf I do git branch -a, I see similar to the following:\n\n* master\n branch1\n trunk\n\n(branch1 and trunk are in red for me, which I figure means they're\nremotely tracked or something like that?)\n\nOK, so that's telling me that I currently have master checked out into\nmy working copy. My question is: where did master come from? Is it a\nlocal branch of trunk?\n\nMoving on, say I want to work on branch1. Can I simply issue git\ncheckout branch1? If I do so I get this:\n\n$ git branch -a\n* (no branch)\n master\n branch1\n trunk\n\nWhich is a bit scary. It seems my working copy is orphaned...\n\nOK, so let's assume I'm supposed to create a local branch of each remote\nbranch I want to work on. So:\n\n$ git branch local/branch1 branch1\n$ git checkout local/branch1\n\n$ git-branch -a\n* local/branch1\n master\n branch1\n trunk\n\nAm I supposed to have used --track when creating this branch? What are\nthe implications for specifying or not specifying that flag when using\ngit-svn?\n\nSo I do some editing on this branch, commit and dcommit. The changes\nappear as expected in the repo.\n\nAt this point if I checkout master, the contents look like\nlocal/branch1, which isn't what I'd suspected (that it would be a branch\nof trunk). What does master represent?\n\nSo I checkout local/trunk, and create a new file, commit and dcommit.\nUmm, it's been committed to branch1 on the repo: not trunk,\n\nSo I figure I'm quite obviously doing something wrong here. Could\nsomeone give me a hand and tell me what it is I'm getting wrong?\n\nThanks!\n\n-- \n\nRuss\n"},{"id":"52972","messageId":"20070908052126.GB28855@soma","threadId":"9820","inReplyTo":"46E18095.60501@gmail.com","subject":"Re: git-svn: Branching clarifications","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-08T05:21:26Z","receivedAt":"2007-09-08T05:21:26Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Russ Brown wrote:\n> I have a few questions about how/when to use git branches when using\n> git-svn (I'm a tad confused...)\n> \n> Say I've initialised and fetched a git repo involving trunk and one\n> branch (say branch1) from an svn repository.\n> \n> If I do git branch -a, I see similar to the following:\n> \n> * master\n> branch1\n> trunk\n> \n> (branch1 and trunk are in red for me, which I figure means they're\n> remotely tracked or something like that?)\n\nYes, that seems to be the case (I just enabled color.branch=auto in\n.git/config for the first time).\n\n> OK, so that's telling me that I currently have master checked out into\n> my working copy. My question is: where did master come from? Is it a\n> local branch of trunk?\n\ngit-svn sets \"master\" to the most recently committed-to branch\nin SVN the first time it fetches. \"git-log master\" will tell\nyou (look at the git-svn-id: lines).\n\nAfter you do your initial fetch/clone, it should say something like:\n\n ----------------------------------------------------------------------\n Checked out HEAD:\n svn://my-repository-here/branches/foo r12345\n ----------------------------------------------------------------------\n\n> Moving on, say I want to work on branch1. Can I simply issue git\n> checkout branch1? If I do so I get this:\n> \n> $ git branch -a\n> * (no branch)\n> master\n> branch1\n> trunk\n> \n> Which is a bit scary. It seems my working copy is orphaned...\n\nYes it is. Branches under the refs/remotes/ hierarchy were created\nback in the day to tell the local user they should not commit to\nthem directly.\n\n> OK, so let's assume I'm supposed to create a local branch of each remote\n> branch I want to work on. So:\n> \n> $ git branch local/branch1 branch1\n> $ git checkout local/branch1\n> \n> $ git-branch -a\n> * local/branch1\n> master\n> branch1\n> trunk\n\nThat's correct. You can also use \"git checkout -b local/branch1 branch1\"\ninstead of those two commands.\n\n> Am I supposed to have used --track when creating this branch? What are\n> the implications for specifying or not specifying that flag when using\n> git-svn?\n\n--track has no effect with git-svn. dcommit will automatically figure\nout which branch it should commit to[1]. Running \"git-svn dcommit -n\"\nwith 1.5.3 will tell you which URL you'll commit to.\n\n> So I do some editing on this branch, commit and dcommit. The changes\n> appear as expected in the repo.\n> \n> At this point if I checkout master, the contents look like\n> local/branch1, which isn't what I'd suspected (that it would be a branch\n> of trunk). What does master represent?\n\n(see above)\n\n> So I checkout local/trunk, and create a new file, commit and dcommit.\n> Umm, it's been committed to branch1 on the repo: not trunk,\n> \n> So I figure I'm quite obviously doing something wrong here. Could\n> someone give me a hand and tell me what it is I'm getting wrong?\n\nIf you run \"git-log local/trunk\", does the first commit to show\na \"git-svn-id: \" line have the URL pointing to trunk or branch1?\n\nAgain, if you're unsure about where you're committing to,\n\"git-svn dcommit -n\" in 1.5.3 is your friend.\n\n[1] - as long as you don't use git-merge or git-pull. If you decide to\n do those things, make sure you have Lars's latest patches\n that enables --first-parent.\n Otherwise stick with format-patch/am/cherry-pick/fetch/rebase\n\n-- \nEric Wong\n"},{"id":"52977","messageId":"85r6l9zlt4.fsf@lola.goethe.zz","threadId":"9820","inReplyTo":"20070908052126.GB28855@soma","subject":"Re: git-svn: Branching clarifications","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-08T06:57:27Z","receivedAt":"2007-09-08T06:57:27Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Eric Wong writes:\n\n> git-svn sets \"master\" to the most recently committed-to branch\n> in SVN the first time it fetches. \"git-log master\" will tell\n> you (look at the git-svn-id: lines).\n\nSigh. Another \"surprise the user by an arbitrary looking choice that\nmight possibly correspond to what he wants done because it something\nobscure in the commit history suggests so\" design decision.\n\nI don't want my master set according to something that a coworker (or\neven myself) happened to commit last to.\n\nPlease. git-svn is told how to find the trunk on its command line.\nNothing makes sense (short of an _explicit_ wish otherwise for which\nit might make sense to create a command line option) than to map\nmaster to the trunk.\n\nAs a design rule: don't second-guess the user, _ever_, and\nparticularly not on decisions with large consequences. A tool should\nnot have a mind of its own but do what it is told. And if it can't\nfigure out what it is told, by simple, user-understandable criteria,\nbarf. And of course have a way to _direct_ it when it can't figure it\nout on its own, or if the simple and obvious default would not do the\nright thing.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"52978","messageId":"20070908074944.GC24166@muzzle","threadId":"9820","inReplyTo":"85r6l9zlt4.fsf@lola.goethe.zz","subject":"Re: git-svn: Branching clarifications","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-08T07:49:44Z","receivedAt":"2007-09-08T07:49:44Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"David Kastrup wrote:\n> Eric Wong writes:\n> \n> > git-svn sets \"master\" to the most recently committed-to branch\n> > in SVN the first time it fetches. \"git-log master\" will tell\n> > you (look at the git-svn-id: lines).\n> \n> Sigh. Another \"surprise the user by an arbitrary looking choice that\n> might possibly correspond to what he wants done because it something\n> obscure in the commit history suggests so\" design decision.\n> \n> I don't want my master set according to something that a coworker (or\n> even myself) happened to commit last to.\n> \n> Please. git-svn is told how to find the trunk on its command line.\n> Nothing makes sense (short of an _explicit_ wish otherwise for which\n> it might make sense to create a command line option) than to map\n> master to the trunk.\n\nKeep in mind that command-line arguments for trunk, branches and tags\nare _all_ optional to git-svn.\n\nIf only trunk or nothing is specified, the current behavior will always\nbe correct.\n\nThere's also a case if only branches and/or tags are specified, with no\ntrunk given. That would need to be handled, somehow...\n\nI've also tracked several (both OSS and closed) projects that have a\npolicy of doing all work on branches with a trunk that's almost never\nup-to-date.\n\nTracking the last-committed branch was the easiest to code, and we even\ntell the user which branch they're on. I guess I could add a message\ntelling them all the other refs they can \"git reset --hard\" to if they\ndon't like their current one.\n\n> As a design rule: don't second-guess the user, _ever_, and\n> particularly not on decisions with large consequences. A tool should\n> not have a mind of its own but do what it is told. And if it can't\n> figure out what it is told, by simple, user-understandable criteria,\n> barf. And of course have a way to _direct_ it when it can't figure it\n> out on its own, or if the simple and obvious default would not do the\n> right thing.\n\ngit-svn used to never check anything out and leave HEAD dangling. I was\nhappy with that, but I got a lot of user complaints from that, too.\n\n-- \nEric Wong\n"},{"id":"52979","messageId":"85ir6lziyq.fsf@lola.goethe.zz","threadId":"9820","inReplyTo":"20070908074944.GC24166@muzzle","subject":"Re: git-svn: Branching clarifications","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-09-08T07:58:53Z","receivedAt":"2007-09-08T07:58:53Z","isPatch":false,"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>> Please. git-svn is told how to find the trunk on its command line.\n>> Nothing makes sense (short of an _explicit_ wish otherwise for\n>> which it might make sense to create a command line option) than to\n>> map master to the trunk.\n>\n> Keep in mind that command-line arguments for trunk, branches and tags\n> are _all_ optional to git-svn.\n>\n> If only trunk or nothing is specified, the current behavior will\n> always be correct.\n\nSure, since Subversion does not distinguish trunk, branches, tags, or\neven projects from each other: they are just naming conventions in the\nrepository and nothing enforces them. So if you check out a single,\nnamed directory, it is natural that this will be master, and tracked.\n\n> There's also a case if only branches and/or tags are specified, with\n> no trunk given. That would need to be handled, somehow...\n\nJust barf unless a --master=thisbranch option is given. If you want\nto, you can allow multiple --track=remotebranch options as well,\ngiving you a tracking branch for the specified remote branches under\ntheir original name.\n\nSomething like that.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"}]}