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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]