Theodore Ts'o <tytso@xxxxxxx> writes:
> 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>
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@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.
Noted.
>> 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@xxxxxxxxxxxxx/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@xxxxxxxxxxxxx/pub/scm/fs/ext2/e2fsprogs.git
fetch = +refs/heads/*:refs/heads/*
; where do we push to and how?
pushurl = ssh://gitolite@xxxxxxxxxxxxx/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
--
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