here is a cut-n-paste of a pull request from the linux-kernel list (the Dave referred to is not me) the stuff between the -- are the guts of the pull request and show the commit that it was branched (forked) from, what branch to pull (next), and the url to pull from.

so in this case

git pull git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 
next

would be the command line to merge in this pull request, and it will merge it into whatever branch you are working on at the time. As long as it is a decendent of 9a1dce3a059111a7289680f4b8c0ec4f8736b6ee, everything will 'just work'

David Lang


Dave,

Please pull this batch of fixes intended for the 3.19 stream!

For the Bluetooth bits, Johan says:

"The patches consist of:

 - Coccinelle warning fix
 - hci_dev_lock/unlock fixes
 - Fixes for pending mgmt command handling
 - Fixes for properly following the force_lesc_support switch
 - Fix for a Microsoft branded Broadcom adapter
 - New device id for Atheros AR3012
 - Fix for BR/EDR Secure Connections enabling"

Along with that...

Brian Norris avoids leaking some kernel memory contents via printk in brcmsmac.

Julia Lawall corrects some misspellings in a few drivers.

Larry Finger gives us one more rtlwifi fix to correct a porting oversight.

Wei Yongjun fixes a sparse warning in rtlwifi.

Please let me know if there are problems!

Thanks,

John

---

The following changes since commit 67e2c3883828b39548cee2091b36656787775d95:

  Merge branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (2014-12-14
20:36:37 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git
tags/master-2014-12-15

for you to fetch changes up to 9a1dce3a059111a7289680f4b8c0ec4f8736b6ee:

  rtlwifi: rtl8192ce: Set fw_ready flag (2014-12-15 13:46:20 -0500)

----------------------------------------------------------------




On Tue, 16 Dec 2014, David Lang wrote:

Date: Tue, 16 Dec 2014 12:15:37 -0800 (PST)
From: David Lang <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: rsyslog-users <[email protected]>
Subject: Re: [rsyslog] master branch

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.

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

Reply via email to