Re: push.default???

From: Paolo Bonzini <paolo.bonzini@gmail.com>
Date: Jun 24, 2009, 08:50 UTC
Message-ID: <4A41E8B8.8050803@gmail.com>
In-Reply-To: <7vprcu96td.fsf@alter.siamese.dyndns.org>

Show 13 quoted lines

> You are forking off of shared 'master', but you are developing a feature
> on a separate branch 'feature'.
> 
> However, when 'feature' is fully cooked, before pushing it back to be
> shared with others in the group, don't you do any testing with the work
> done by others while you were working on 'feature'?  That means you first
> integrate your 'feature' locally into shared 'master' and make sure all
> fits together well.
> 
> Until you do that, you cannot be confident that the feature you developed
> is fit for public consumption.  But if you test after merging 'feature'
> into 'master', what you determined as good is in 'master', which you can
> push back to the remote's 'master'.

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.

In fact, what was not clear to me before Finn explained it is the way these remotes are configured and mapped to local branches. In his setup, your own master branch is tracking integration/master, but your feature branch is tracking feature/master. You're effectively using a centralized repository but splitting it across several remotes, presumably for two reasons: 1) access control, 2) so that people can choose which parts of the repository to mirror.

Mind that this is quite a mangled DVCS workflow :-) since you're distributing the centralized repository (!), so you're not using topic branches and you're not committing very often; if you were using topic branches you would have to use --no-track or risk pushing by mistake to feature/master. You just map "svn update" to "git pull --rebase" and "svn commit" to "git commit + git push".

So, every time you finish some aspect of 'feature', you rebase it on top of the tracked branch feature/master to test it with the work done by others, and then push. The rebasing is taken care of by "git pull", so it makes sense in this case that pushing to feature/master is done with plain "git push".

Show 5 quoted lines

> Could it be possible that this desire to push "tracking" is not a cure for
> anything real, but merely a kludge to work around a misfeature of "rebase"
> UI that does not allow "integrate that branch here but do not merge it but
> by first rebasing it"?  In other words, if we had "git merge --rebase feature"
> [to merge rebased feature into master, then "git push origin HEAD"] becomes the

 > right thing to do, eliminating the need for "put my 'feature' into 
their 'master'".
 >

> For a group that sets up a shared public branch to be used for working
> together on some feature, replace 'master' with 'some feature' above, and
> 'feature' with 'your part of the work on the feature'; the story is the
> same.

I think this makes sense, but it is not what Finn was going after. In his setup, there is no 'your part of the work on the feature', everything is done in a single branch.

Now, here is a plan to realize the same workflow with a different implementation.

1) introduce a new configuration key branch.autosetuppush that 
automatically adds a remote.*.push entry whenever a tracking branch is 
created.

I think this is also the right time to introduce per-remote autosetup keys remote.*.autosetup{merge,rebase,push}. In fact I would introduce these per-remote configurations before, as a kind of "step 0".

2) introduce git push --current (or maybe --head-only) that uses 
whatever refspec "git push" uses, but always restrict pushing to the 
current branch.  This would only apply to "git push" without explicit 
refspecs.

3) introduce remote.*.pushHeadOnly to make "git push" always behave like 
"git push --current".

Note that the new command line option is not really needed, but it would make testing harder if --current behavior could be specified only with configuration keys.

4) introduce a --push option for "git remote add".  Every push.default 
configuration, thanks to steps 1 and 3, now maps to a simple configuration:

  --push=current -> remote.*.push = HEAD
  --push=tracking -> remote.*.autosetuppush=remote.*.pushHeadOnly=true
  --push=matching -> remote.*.push = :

In addition, --push=mirror could be implemented to do the same as --mirror.

I have a rough draft of all but the last step already implemented (I have not even compiled, but I wanted to measure roughly the complexity of the features; unless I screwed up big, it seems like a "calm" patch series). I like this way more than the "magic refspec". Unlike push.default, it builds entirely on the concept of refspecs. But unlike the magic refspec, it fits with the rest of --track better, and it just uses two easily understood knobs to achieve its objective.

Paolo