Re: push.default???

On Wed, Jun 24, 2009 at 10:50:00AM +0200, Paolo Bonzini wrote:

Here is what I think you are missing: in the proposed workflow, there is  
an entire group working on one big feature, so there is effectively one  
remote per feature.

I think you are making this more complicated than it is. I just claim
that the idea that "branch names must be identical in both ends" is
not necessarily the best model.

In a sufficiently large origanisation with multiple levels of
repositories (access restrictions, locality, whatever) branch names
are not globally unique, and there is no reasonable way to check if a
branch name is used elsewhere. It is much easier to treat local branch
names as strictly local, and worry about naming (only) when you push
somewhere.

So - even if someone decided to name something "issue-331318" on a
public repository, it doesn't mean you want to call it that locally,
even if you want to push to it.

If a branch already exists on a public repo, it doesn't mean a branch
with the same name but with different contents/purpose cannot exist in
a different repo. So you may have to name the branch something else
locally. Pull knows how to deal with this, but push did not (before
"--tracking").

Another example:

You have worked for a few days on an issue, but need help from someone
else with something. You have set up a public shared repo named
"public", and do:

git push public HEAD:fred-helpme

Fred wants to name it something else that makes him remember what this
branch is about, and does:

git fetch public
git checkout -b tmp-help-john public/fred-helpme
<hack hack>
git commit
git push   (no more arguments, and no need to remember what it was named)

You then fetch and look at what Fred has done, and maybe you just use
it, or maybe you don't. Afterwards git push public :fred-helpme to get
rid of the temporary shared branch.

- Finn Arne