Subject: Re: push.default???

From: Paolo Bonzini <[email-masked]>
Date: Wed, 24 Jun 2009 10:50:00 +0200

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

> 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