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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
