Re: push.default???

[Finn Arne Gangstad <finnag@pvv.org>]

On Tue, Jun 23, 2009 at 03:28:04PM +0200, Paolo Bonzini wrote:
> Finn Arne Gangstad wrote:
>> On Tue, Jun 23, 2009 at 02:59:10PM +0200, Paolo Bonzini wrote:
>> [...]
>>> Before going on, can you explain your use case for --push=tracking 
>>> (in a  case where --push=current wouldn't do the same)?
>>
>> The idea with "tracking" is to push the current branch to wherever it
>> would pull from, making push & pull "equivalent" in some sense.
>>
>> This is different from "current" if you have/choose to name the local
>> branch something else than the remote branch. This happens a lot when
>> using multiple remotes.
>
> Yes, but when using multiple remotes is it really common that:
>
> 1) I have the permission to push to them (as opposed to sending a pull  
> request)?  If I have permission to push only to the mob branch, for  
> example, I would still set my tracking branch to the master branch.

I don't know how common it is, but it is certainly not unheard of. You
have a shared public server, and a group-shared public server and so
on. You only need a single shared public server for this to make sense
however.

> 2) I *do* want to push to them often?  If I use tracking for my topic  
> branches, push.default=tracking seems a sure way to big mess when I do  
> "git push" on the wrong branch.

In our shared repositories, we have a few protected branches that only
integrators can push to, so no one else can accidentally push to
them. These are typically the branches that it makes sense to track
"by default".

If a group sets up a shared public branch, it is typically for
working together on some feature. There are very few surprises if
the group works like this:

 1. Do some modifications
 2. git commit
 3. git pull [--rebase]
 4. git push
 5. goto 1 .. 

For people used to CVS, this is a nice way to start working with git.
It requires --tracking to work properly though (--current only works
if you remember to use the same branch name).

> Instead, with push.default=current "git  
> push" would just tell me "new branch created" and then I can do "git  
> push branch-name:" to delete the newly created branch.

Well, you need to add the name of the remote. And while not exactly
impossible to find, for the target audience it may be a bit more
cumbersome than it should be:

branch: git symbolic-ref HEAD | sed -e s=refs/heads/==
remote: git config branch.<branch>.remote

And if you want to figure out what the branch you pulled from is
named, you have to do something like

git config branch.<branch>.merge | sed -e s=refs/heads/==

> I don't remember who it was, but when I tried changing the behavior for  
> "git push" someone screamed loudly that fetching and pushing are two  
> different things, and making things work uniformly across the two is not  
> necessarily correct.  The details probably were different, but I think  
> that I am saying the same now.

Different use cases want different things from push. If you are the top
level integrator of a project and are trying to keep 3 remotes in sync
with your master repository, "matching" seems to be what you want.

If you are a leaf-node worker pushing to a public repository, it
isn't. But --tracking may be a valid choice sometimes (and is, in some
sense, very close to SCMs people may be used to).

- Finn Arne