From: Eric Wong <normalperson@yhbt.net>
To: Russ Brown <pickscrape@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git-svn: Branching clarifications
Date: Fri, 7 Sep 2007 22:21:26 -0700 [thread overview]
Message-ID: <20070908052126.GB28855@soma> (raw)
In-Reply-To: <46E18095.60501@gmail.com>
Russ Brown <pickscrape@gmail.com> wrote:
> 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?)
Yes, that seems to be the case (I just enabled color.branch=auto in
.git/config for the first time).
> 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
----------------------------------------------------------------------
> 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, 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.
> 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.
> 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.
[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
next prev parent reply other threads:[~2007-09-08 5:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-07 16:47 git-svn: Branching clarifications Russ Brown
2007-09-08 5:21 ` Eric Wong [this message]
2007-09-08 6:57 ` David Kastrup
2007-09-08 7:49 ` Eric Wong
2007-09-08 7:58 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070908052126.GB28855@soma \
--to=normalperson@yhbt.net \
--cc=git@vger.kernel.org \
--cc=pickscrape@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).