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

Theodore Ts'o [off-list ref] writes:

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

quoted

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>

And at this point I presume that you wish this "push" automatically
pushed out ext4_for_linus, just like "fetch" by default grabs tags
that point into the history being fetched?

I think "push --follow-tags" in the upcoming 1.8.3 would work for
you if that is the case.

   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.

Noted.

quoted

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.

Sounds sensible.

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

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.

I think you can have more than one destination URLs to a single
remote you are pushing as long as what are pushed and how are common
to them, that is, something like this:

[remote "publish"]
	; where do we fetch/pull from and how?
	url = ssh://gitolite@ra.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
	fetch = +refs/heads/*:refs/heads/*
	; where do we push to and how?
	pushurl = ssh://gitolite@ra.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
	pushurl = https://code.google.com/p/e2fsprogs/
	pushurl = ssh://repo.or.cz/srv/git/e2fsprogs.git
	push = next
	push = master
	push = maint
	push = debian
	push = +pu