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

Michael Pyne mpyne at purinchu.net
Thu Jun 11 05:10:28 CEST 2009


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.

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.

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

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090610/3bbdb26d/attachment.sig 


More information about the Kde-scm-interest mailing list