Re: git-svn: Branching clarifications

[Russ Brown <pickscrape@xxxxxxxxx>]

Eric Wong wrote:
> Russ Brown <pickscrape@xxxxxxxxx> wrote:
>
>> 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?
> 
> 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
>   ----------------------------------------------------------------------
> 

Ah, I see. As discussed elsewhere in this thread, I think it's therefore
probably most wise to ignore the master branch completely for the time
being and manually create local branches as needed instead when using
git-svn.

>> 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...
> 
> 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.
> 

ok. I figure it's probably best to configure git-svn to create the
remote trunk branch with a name other than simply 'trunk' as it is in my
case so I can create a local branch with that name, which makes more
sense from a usability point of view. This may have been a mistake on my
part though when first setting it up.

Having just tried it again, it does create the branches with names
simply 'trunk' and 'branch1'. Since I won't actually be using those
directly, I've found it more sensible to tweak the config after init to
add an extra level into the name ('repo/trunk' and 'repo/branch1') so I
can create more pleasant local branch names to work with. Is there any
disadvantage to this approach?

>> 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
> 
> That's correct.  You can also use "git checkout -b local/branch1 branch1"
> instead of those two commands.
> 

Handy shortcut. :)

>> 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?
> 
> --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.
> 

Sweet.

>> 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?
> 
> (see above)
> 
>> 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?
> 
> 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.
> 

Yes, this is proving quite useful. It would also be useful to be able to
see a list of commits that dcommit have 'queued' to dcommit from the
command line.

> [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
> 

Would it be sensible to somehow or other render these commands unusable
when dealing with operations in a git-svn repository that could cause
damage? Don't know how feasible it would be though. I do know though
that if there's a button there that someone could press to mess things
up, someone *will* press it. :)

-- 

Russ
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html