On 2 June 2015 at 15:34, Martin Pitt <martin.p...@ubuntu.com> wrote: > David Herrmann [2015-06-02 13:06 +0200]: >> Our preferred way to send future patches is "the github way". This >> means sending pull-requests to the github repo. Furthermore, all >> feature patches should go through pull-requests and should get >> reviewed pre-commit. This applies to everyone. Exceptions are >> non-controversial patches like typos and obvious bug-fixes. > > Makes sense. On the operational level, should we use the > "automatically merge" feature of git hub once approving? On the plus > side it's very convenient, but you'll get one "Merge" commit for every > PR (which is often just one commit), so we'd almost double the entries > in "git log". Or can github be told to not do that? > > Merging manually is quite a bit of work, as you have to add a new > remote every time, fetch that, and pull from it. But it does keep a > cleaner git log history.
One doesn't need to add a named remote.... If you have write access, at the bottom of the pull request there is a link to command line instructions, excluding "make sure you are on the right target branch" and "you know where to push" it boils down to: git pull https://github.com/somebody/systemd.git branch-name-that-was-proposed one step. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel