[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-scm-interest
Subject: [Kde-scm-interest] thoughts about git + kdesvn-build
From: Michael Pyne <mpyne () purinchu ! net>
Date: 2009-06-11 3:10:28
Message-ID: 200906102310.29029.mpyne () purinchu ! net
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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
["signature.asc" (application/pgp-signature)]
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic