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
