git-svn: Branching clarifications

I have a few questions about how/when to use git branches when using git-svn (I'm a tad confused...)

Say I've initialised and fetched a git repo involving trunk and one branch (say branch1) from an svn repository.

If I do git branch -a, I see similar to the following:

* master
branch1
trunk

(branch1 and trunk are in red for me, which I figure means they're remotely tracked or something like that?)

OK, so that's telling me that I currently have master checked out into my working copy. My question is: where did master come from? Is it a local branch of trunk?

Moving on, say I want to work on branch1. Can I simply issue git checkout branch1? If I do so I get this:

$ git branch -a
* (no branch)
  master
  branch1
  trunk

Which is a bit scary. It seems my working copy is orphaned...

OK, so let's assume I'm supposed to create a local branch of each remote branch I want to work on. So:

$ git branch local/branch1 branch1
$ git checkout local/branch1

$ git-branch -a
* local/branch1
  master
  branch1
  trunk

Am I supposed to have used --track when creating this branch? What are the implications for specifying or not specifying that flag when using git-svn?

So I do some editing on this branch, commit and dcommit. The changes appear as expected in the repo.

At this point if I checkout master, the contents look like local/branch1, which isn't what I'd suspected (that it would be a branch of trunk). What does master represent?

So I checkout local/trunk, and create a new file, commit and dcommit. Umm, it's been committed to branch1 on the repo: not trunk,

So I figure I'm quite obviously doing something wrong here. Could someone give me a hand and tell me what it is I'm getting wrong?

Thanks!

Russ

Yes, that seems to be the case (I just enabled color.branch=auto in .git/config for the first time).

git-svn sets "master" to the most recently committed-to branch in SVN the first time it fetches. "git-log master" will tell you (look at the git-svn-id: lines).

After you do your initial fetch/clone, it should say something like:

----------------------------------------------------------------------
Checked out HEAD:

    svn://my-repository-here/branches/foo r12345

----------------------------------------------------------------------

Yes it is. Branches under the refs/remotes/ hierarchy were created back in the day to tell the local user they should not commit to them directly.

That's correct. You can also use "git checkout -b local/branch1 branch1" instead of those two commands.

--track has no effect with git-svn. dcommit will automatically figure out which branch it should commit to[1]. Running "git-svn dcommit -n" with 1.5.3 will tell you which URL you'll commit to.

(see above)

If you run "git-log local/trunk", does the first commit to show a "git-svn-id: " line have the URL pointing to trunk or branch1?

Again, if you're unsure about where you're committing to, "git-svn dcommit -n" in 1.5.3 is your friend.

[1] - as long as you don't use git-merge or git-pull. If you decide to do those things, make sure you have Lars's latest patches that enables --first-parent.
Otherwise stick with format-patch/am/cherry-pick/fetch/rebase

Eric Wong

Sigh. Another "surprise the user by an arbitrary looking choice that might possibly correspond to what he wants done because it something obscure in the commit history suggests so" design decision.

I don't want my master set according to something that a coworker (or even myself) happened to commit last to.

Please. git-svn is told how to find the trunk on its command line. Nothing makes sense (short of an _explicit_ wish otherwise for which it might make sense to create a command line option) than to map master to the trunk.

As a design rule: don't second-guess the user, _ever_, and particularly not on decisions with large consequences. A tool should not have a mind of its own but do what it is told. And if it can't figure out what it is told, by simple, user-understandable criteria, barf. And of course have a way to _direct_ it when it can't figure it out on its own, or if the simple and obvious default would not do the right thing.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

Keep in mind that command-line arguments for trunk, branches and tags are _all_ optional to git-svn.

If only trunk or nothing is specified, the current behavior will always be correct.

There's also a case if only branches and/or tags are specified, with no trunk given. That would need to be handled, somehow...

I've also tracked several (both OSS and closed) projects that have a policy of doing all work on branches with a trunk that's almost never up-to-date.

Tracking the last-committed branch was the easiest to code, and we even tell the user which branch they're on. I guess I could add a message telling them all the other refs they can "git reset --hard" to if they don't like their current one.

git-svn used to never check anything out and leave HEAD dangling. I was happy with that, but I got a lot of user complaints from that, too.

Eric Wong

Sure, since Subversion does not distinguish trunk, branches, tags, or even projects from each other: they are just naming conventions in the repository and nothing enforces them. So if you check out a single, named directory, it is natural that this will be master, and tracked.

Just barf unless a --master=thisbranch option is given. If you want to, you can allow multiple --track=remotebranch options as well, giving you a tracking branch for the specified remote branches under their original name.

Something like that.

David Kastrup, Kriemhildstr. 15, 44793 Bochum