[Kde-scm-interest] thoughts about git + kdesvn-build

[Chani]

On June 10, 2009 20:10:28 Michael Pyne wrote:
> Hi all,
>
> So I'm trying to think of the best way to ensure that kdesvn-build executes
> the right series of commands to ensure that a given branch is downloaded
> from a given repository, even if they get switched in the config file,
> without having to rely on naming schemes, and without interfering with the
> user's own development efforts.
>
> This has been helping me to learn git along the way, which is nice.  This
> is what I've determined so far:
>
> 1. It seems to me that it is best to add the repository to use as a
> "remote" in git.  Right now I'm using git remote -v to list all known
> remotes.  If the repository is listed then kdesvn-build will just use the
> corresponding remote object.  If the repository is not already known my
> plan is to add a remote for it, basing the name off of the repo URL (i.e.
> git://qt.gitorious.org/+kde- developers/qt/kde-qt.git would use kde-qt as a
> default remote name).  This establishes how to refer to the repository in
> git.

you're probably better off doing git clone git at gitorious.org:path-to-repo
this will download everything and set it up nicely; the remote will be called 
"origin". also, I know that at least for gitoritous.org you need to use git@ 
instead of git:// if you want to be able to push. git:// seems to be the 
equivalent of anonsvn.

>
> 2. Branching is a bit more difficult for me.  I know that a local tracking
> branch much exist to track a remote branch.  My intention is to use git
> checkout -b to create the local branch if the branch is not already
> available.

no, do it like this:
git branch --track $branch origin/$branch
and then git checkout $branch

the --track may be unnecessary, actually.

>
> My questions are:
>
> * Is there an accepted naming scheme for the local tracking branch?  Right
> now I'm just using $remote/$branch for the name but that gives problems
> with ambiguous references (I may just substitute - for / to make the branch
> name I think).

I don't know, but it makes sense to me to just call it $branch. I've never 
worked with >1 remote, though (not counting gitsvn)

> * Is there a good way to tell that there is a local tracking branch
> specifically for a given remote branch?  I'm thinking this will work:
>
> git branch --contains refs/remotes/$remote/$branch
>
> and that if that command outputs any branches, it will be only branches
> that are tracking that remote (and not merely predecessors, for instance). 
> This way kdesvn-build could re-use a local tracking branch that's been
> already created by the user or a previous kdesvn-build run.
>
> 3. From there, I'm planning just to use git checkout $localBranch and then
> git pull to verify that local is up-to-date to complete the process.
>
> Anything else I'm missing?

probably ;) git's quite the powerful system. this is my second year using it 
for gsoc, and I still feel like I know almost nothing of its power or its 
personality... kinda like with vim... :)

hopefully thiago can give you some more pointers.

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090610/8916e8ac/attachment.sig