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 Brown <pickscrape@gmail.com> wrote:

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 <normalperson@yhbt.net> writes:

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 <dak@gnu.org> wrote:

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 <normalperson@yhbt.net> writes:

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.