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. I'd very much prefer to keep current look of the git tree, without gratuitous merge commits. For bigger changes, which are composed of a larger number of commits, merges are fine. But most patchsets to systmed are either a single commit or two or three.
Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
