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