Theodore Tso wrote:
On Thu, Oct 25, 2007 at 12:33:09PM +0200, Andreas Ericsson wrote:
Because it's convenient, ofcourse. Don't you have 'maint', 'next'
and 'master' in your clone of git.git? I'm guessing at least 99% of
the people on this list have those branches lying around in their
clones, even if they only ever use 'next' and/or 'master'.
I find it just as easy to say: "git checkout origin/maint" or "git
checkout origin/next" when I want to examine some other branch.
If I want to make a change against maint, then I follow up "git
checkout origin/maint" with a "git checkout -b <topic-name>". Part of
Except that <topic-name> in this case will always be maint, since
only small bugfixes go on that branch. We tried using different-named
branches earlier, but the "git push <local-branch>" behaviour was
much too common, and we ended up with far too many randomly named
branches on the mothership repository.
You're using a diferent workflow, and with users who aren't interested
in learning the fine points of git. But main issue is that git isn't
optimized for what you want to do.
Correct. I'm working on optimizing it right now though :)
So I can suggest a couple of
different approaches. One is to simply do things the 'hg' way.
Explicitly set up different repos for the different branches. It's
more inefficient, but it does work.
That makes diffing harder to do, and for those few long-living topics
that get pushed to mothership, there's no logical way for the user to
get only that branch. With the *:refs/remotes/foo/* config thing, this
works seemlessly today.
Another would be to set up a wrapper script for "git-clone" that
creates a separate local working directory for each branch. So for
example, it might do something like this:
#!/bin/sh
# Usage: get-repo <URL> [dir]
URL=$1
dir=$2
branches=`git-ls-remote --heads $URL | sed -e 's;.*/;;'`
if [ "$dir"x = "x" ]; then dir=`basename $URL`; fi
git clone $URL .temp-repo
mkdir $dir
cd $dir
for i in $branches; do
mkdir $i
cd $i
git init
git remote add -t $i origin $URL
echo ref: refs/heads/$i > .git/HEAD
git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i
# do it a second time to get the tags (bug in fetch?)
git fetch ../../.temp-repo refs/remotes/origin/$i:refs/remotes/origin/$i
git merge origin/$i
git config remote.origin.push $i:$i
cd ..
done
cd ..
rm -rf .temp-repo
For bonus points, this script could be made smarter so that each of
the branches shared a common git object database, and some error
checking would be nice, but hopefully this gets the basic idea across.
This way, the "basic git users" get a separate working directory for
each branch, where "git pull" updates that particular branch, and "git
push" updates changes to the remote branch.
Does this do what you want?
Not really, I'm afraid. Apart from missing out on the auto-download of
new repos you get with "fetch = refs/heads/*:refs/remotes/origin/*",
it seems inelegant.
- Ted
P.S. Note by the way that if you are having everyone own access to
push into a single central repository, having a "next" branch probably
doesn't make seense. You're probably way better off just simply
having "master" (which would be your devel branch), and "maint" for
bug fixes.
We have
maint = maintenance code. some repos have several maint-branches
master = integration-tested code that will end up in next release
testing = unit-tested features, ready for integration testing
We can't really do without them, but perhaps I can do what Dscho
suggested in another email and force everyone to delete their
locally-modifiable branches once they're done making changes to
them. It'll end up being more commands to run for a single fix,
but at least it's not error-prone.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
