On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote:
> But in a triangular workflow, the way to make the result reach the
> "upstream" is *not* by pushing there yourself. For developers at
> the leaf level, it is to push to their own repository (often on
> GitHub), which is different from where they (initially) clone from
> in order to bootstrap themselves, and (subsequently) pull from in
> order to keep them up-to-date. And then they request the published
> work to be pulled by the "upstream".
Yep, what I do personally is to call the destination of this "publish", i.e.:
[remote "publish"]
url = ssh://gitolite@xxxxxxxxxxxxx/pub/scm/linux/kernel/git/tytso/ext4.g
push = +master:master
push = +origin:origin
push = +dev:dev
So my typical work flow when I am ready to submit to Linus is:
git tag -s ext4_for_linus
git push publish
<wait for this to propagate from ra.kernel.org to git.kernel.org,
typically ~5 minutes>
git request-pull git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git origin > /tmp/pull
<use /tmp/pull as the e-mail body to send to Linus, cc'ing
LKML and linux-ext4@xxxxxxxxxxxxxxx>
But actually, it's much more common that I am doing a "git push
publish" so that (a) it can get picked up by the daily linux-next tree
(for integration testing even before Linus pulls it into his tree),
and (b) so other ext4 developers so they can either test or develop
against the ext4 tree in progress.
I suppose it would be convenient for "git push" to push to the
"publish" target, but I don't get confused about pushing to origin,
since semantically what I am doing is publishing the current state of
the ext4 tree so other people can see it. So "git push publish" makes
a lot of sense to me.
> Even in a triangular workflow, @{u} should still refer to the place
> you integrate with, i.e. your "upstream", not to the place you push
> to publish the result of your work.
>
> This branch.<branch>.rewindable safety however cannot be tied to
> @{u}. The bottom boundary you want to be warned when you cross is
> the change you pushed out to your publishing repository, and it may
> not have reached remotes.origin.<branch> yet.
Indeed, and in fact for my use case what I promise people is that all
of the commits between origin..master are non-rewindable. It's the
commits betewen master..dev which are rewindable. So for me, I'd
still use the safety feature even for my rewindable branch, but
instead of using remotes/publish/dev the "no-rewind" point, I'd want
to use remotes/publish/master as the "no-rewind" point.
Right now I do this just by being careful, but if there was an
automatic safety mechanism, it would save me a bit of work, since
otherwise I might not catch my mistake until I do the "git push
publish", at which point I curse and then start consulting the reflog
to back the state of my tree out, and then reapplying the work I had
to the right tree.
> We will be introducing remote.pushdefault configuration in the
> upcoming 1.8.3 release, so that you can say.....
>
> and hopefully it would let you do this:
>
> git checkout master
> ... after working on it ...
> git push
Yes, that would be convenient. BTW, one of the other things which I
do for e2fsprogs is that I use multiple publishing points, which is
mostly for historical reasons --- it used to be that repo.or.cz wasn't
all that reliable, and the 10-15 minute replication time from
ra.kernel.org to git.kernel.org got really old.
So what I do is something like this:
git push publish ; git push repo ; git push code
where....
[remote "publish"]
url = ssh://gitolite@xxxxxxxxxxxxx/pub/scm/fs/ext2/e2fsprogs.git
fetch = +refs/heads/*:refs/heads/*
push = next
push = master
push = maint
push = debian
push = +pu
[remote "code"]
url = https://code.google.com/p/e2fsprogs/
fetch = +refs/heads/*:refs/heads/*
push = next
push = master
push = maint
push = debian
push = +pu
[remote "repo"]
url = ssh://repo.or.cz/srv/git/e2fsprogs.git
push = next
push = master
push = maint
push = debian
push = +pu
I don't know if this is something you'd want git to encourage, or
support explicitly, but I thought I'd mention it.
- Ted
--
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