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

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

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

> 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
> ...
> [remote "repo"]
> ...
> I don't know if this is something you'd want git to encourage, or
> support explicitly, but I thought I'd mention it.