Re: [PATCH] Added guilt.reusebranch configuration option.

From: Theodore Ts'o <tytso@mit.edu>
Date: May 23, 2013, 02:11 UTC
Message-ID: <20130523021123.GA23155@thunk.org>
In-Reply-To: <7vvc6aj14r.fsf@alter.siamese.dyndns.org>

On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> 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@ra.kernel.org/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@vger.kernel.org>

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.

Show 8 quoted lines

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

Show 8 quoted lines

> 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@ra.kernel.org/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