Sent from phone, thus brief. Am 16.12.2014 21:15 schrieb "David Lang" <[email protected]>: > > On Tue, 16 Dec 2014, Rainer Gerhards wrote: > >> Is there any way I can work decently with pull requests with those >> throw-away branches? Right now most are against master, wich means I need >> to manually merge and it always looks like I closed unnerved. . > > > I think I'm missing something here. a pull request should just be the url of the branch to pull in, you should be able to pull that in to any branch you want, not just the one they forked from. Pulling in to a different branch may generate more conflicts, but that can happen when other things have been pulled into the branch they forked from as well. > > It's possible that this is a github gui issue. I'm talking in terms of the underlying git functionality.
Yup that's it. But so many folks care about these details. Probably there is no way this time to keep all happy... Given the fact that we did not have any issue that required reverting master-candidate it's probably not so pressing to use throw away branches. To be precise, if thrown away on two or three occasions but that was only local, before I pushed (I do at least a quick manual testbench run before that, as I always did). Rainer > > David Lang > > >> Sent from phone, thus brief. >> Am 16.12.2014 20:55 schrieb "David Lang" <[email protected]>: >> >>> On Tue, 16 Dec 2014, David Lang wrote: >>> >>> I ask >>>>> >>>>> because almost all pull requests are done against master branch, which >>>>> means I need to manually merge them to master-candidate and close the PR >>>>> as >>>>> "unmerged". >>>>> >>>>> It would probably much more efficient to have "master" be the >>>>> experimental >>>>> branch, and when the testbench succeeds move it to something like >>>>> "master-ok" (or so). >>>>> >>>> >>>> the thing is that the testing branch gets recreated for each run. It >>>> doesn't have a long term history (or shouldn't), so you don't want people >>>> trying to develop against this. >>>> >>> >>> after reading the rest of the thread, I'm not being clear here. And as a >>> result, what I was trying to describe and what Rainer is probaly doing >>> aren't likely to match. >>> >>> (much of this is copied from the approch that git uses for development) >>> >>> what I think that Rainer understood (and what I may have described) was >>> >>> 1. develop on branches >>> >>> 2. merge dev branches into test branch, test it >>> >>> 3. if all tests pass, merge test branch into master >>> >>> 4. otherwise, hack on dev or test branchs to fix problem, merge results >>> into test, test it, goto 3 >>> >>> >>> What I should have desribed is slightly different >>> >>> 1. develop on branches >>> >>> 2. create throwaway branch that merges all dev branches, test it >>> >>> 3. if all tests passes, merge those dev branches into master (since this >>> is the same merge that was done in #2 it should be trivial) >>> >>> 4. otherwise, goto #2 but skip merging the branch that caused problems. >>> >>> >>> the reason to test against a throw-away branch instead of a long-lived >>> branch is so that if you have a problem with a branch that's being merged >>> in, you can just drop that branch rather than needing to revert it. This >>> makes for a cleaner history as you won't have merge/revert commits in it. >>> >>> David Lang >>> >>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com/professional-services/ >>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >>> DON'T LIKE THAT. >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
