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

On Oct 23, 2007, at 12:58 PM, Johannes Schindelin wrote:

I try to explain the workflow that I'd use the feature for. Maybe an easier setup could be used to achieve the same. Any suggestions for a simpler setup are welcome.

The workflow is used by a group of developers that all have access to a shared repository. One major goal is to keep the setup for most developers simple. They are new to git and as few commands as possible should be sufficient to start working. Besides the typical stable branches (master, next) shared topic branches should be available that can be used to develop and review features before they are merged to the stable branches. Patches are not send by email.

So here's the setup:

The central shared repo is called project-shared.git and contains,
for example, the following branches:
    master
    next
    work/topicA
    work/topicB
    ...

Developers clone the repo and check out the branches they are interested in. For example a developer may want to track next and work on topicB:

    git clone ssh://central.example.com/project-shared.git project
    cd project
    git checkout -b next origin/next
    git checkout -b work/topicB origin/work/topicB

This is sufficient. No adding of remotes is needed. Neither is a private repository on a server required. After cloning, developers have all they need.

Later work/topicB has new commits and should be pushed:

    git push origin

The default behaviour of push is fine. Only matching branches are pushed.

_But_, origin is a shared repository. Therefore branches may have advanced and git push may report

error: remote 'refs/heads/next' is not a strict subset of local ref 'refs/heads/next'. maybe you are not up-to-date and need to pull first?

So here's the problem. The developer didn't do anything wrong. But git complaints with an error. Git also recommends to run pull, so the developer runs "git pull". But this doesn't help, because it's only updating work/topicB and "git push" will complain with the very same error.

What you need to do is

    git checkout <local-branch>
    git pull
    git checkout <local-branch2>
    git pull
    ...

for every local branch.

This is absolutely stupid. Therefore the developer starts to hate git, or she just starts to ignore the errors because they don't have a real meaning most of the times. And later, when the error could be helpful she would ignore it, too.

The problem described can only happen with a shared repository. In a workflow that pulls from read-only repos and pushes to a private repo that is read-only for others, such a problem cannot happen. Because in a non-shared repository the branches cannot be advanced by others. But in a shared repository they can.

I see two reasonable solutions:
1) "git push" only pushes the current branch.
2) "git pull" pulls all branches as proposed by Andreas.

Maybe something that I don't see is fundamentally wrong with the setup.

Johannes, you mentioned that it is essential to distinguish remote branches from local branches. In general, I agree. The problem described above is 'smaller' if you have less local branches that you're not actively working on. But I believe it is reasonable to have more than one of them. The remotes track everything and your local branches are a subset of things you're interested in although you're not working on each of the branch every day. I don't think it's reasonable to delete a local branch immediately each time you stopped working on it.

I think root of the problem is that git is more focused on pulling from read-only and pushing to non-shared repos. The support for shared repos needs to be improved before it is perfect.

	Steffen