On Tue, Jun 2, 2015 at 4:34 PM, 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.

Use github.

With the decision to move to github, we need to accept the github
model and with that accept possible cosmetic issues.

If it turns out to be too crazy, we have to question github, not
fiddle around with local rebases.

Kay
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to