On Tue, 16 Dec 2014, Rainer Gerhards wrote:
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...
I'm still in the dark about what the problem is.
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).
yep, this is only significant when there's a need to back out a branch that's
not ready yet. For your personal work it's probably not significant, if and when
we are getting more patches from others the probability will go up that one of
the things you are being asked to pull won't work and will need to be
dropped/fixed. If you clone each external pull into a local dev branch and test
it, you can avoid the need to drop it from the master-candidate branch, but that
can quickly add up to more work.
So there's not a pressing need to change this now, but keep it in mind for the
future.
David Lang
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.
_______________________________________________
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.
