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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html