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