Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued

On Thu, Oct 25, 2007 at 12:33:09PM +0200, Andreas Ericsson wrote:

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 the reason though, why I *want* to keep the topic branch around is precisely because I don't get to push to the central repository. So I want to keep it around so either (a) the central maintainer can pull from me, and I delete it only after he's done the pull, or (b) so I can use git-chery so I can see when patches that I created and sent via git-format-patch and git-send-email have been accepted.

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. 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. And if the bulk of your users are, ah, "aggressive ignorant" about git --- and many developers don't care about learning the fine points of their tools, and a successful software company needs to learn how to leverage the skills of such mid-level engineers (only at a startup or if you are at Google can you insist only only hiring the best and brightest) --- then it might be that the 'hg' approach is easier. Certainly that was the approach Larry McVoy has always used with BitKeeper, and he is focused on meeting the needs of his corporate customers.

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?

							- 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.