Theodore Ts'o <> 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://
>       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 to,
>      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:// origin > 
> /tmp/pull
>     <use /tmp/pull as the e-mail body to send to Linus, cc'ing
>      LKML and>
> 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 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 wasn't
> all that reliable, and the 10-15 minute replication time from
> to 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://
> ...
> [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://
        fetch = +refs/heads/*:refs/heads/*
        ; where do we push to and how?
        pushurl = ssh://
        pushurl =
        pushurl = ssh://
        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
More majordomo info at

Reply via email to