On 2 June 2015 at 15:56, Daniel P. Berrange <[email protected]> wrote: > On Tue, Jun 02, 2015 at 04:34:03PM +0200, Martin Pitt 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. > > FWIW, 'git log --no-merges' displays the "clean" history when > merges are present.
I also like --first-parent a lot, that "squishes" the pull request into the single commit in the log / graph (aka bzr style default log output). -- 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
