[systemd-devel] [ANNOUNCE] Git development moved to github

[Lennart Poettering]

On Wed, 10.06.15 15:31, Alban Crequy (alban at endocode.com) wrote:

> On Tue, Jun 9, 2015 at 11:37 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Tue, 09.06.15 13:04, Filipe Brandenburger (filbranden at google.com) wrote:
> >
> >> On Tue, Jun 9, 2015 at 12:59 PM, Lennart Poettering
> >> <lennart at poettering.net> wrote:
> >> > [...] so we comment and ask for a new PR, and close the old one.
> >>
> >> See my previous comment, I think this "cure" is worse than the
> >> "disease" :-)
> >
> > Why would you say this? Why are multiple sequencial PR, where the old
> > obsoleted ones are closed and locked that bad?
> >
> >> Instead, just reuse the same PR and use `git push -f` to ship new
> >> versions of the commits to the same branch... Yes it's awful but
> >> unfortunately that's how GitHub works...
> >
> > Yeah, it is awful, and loses all the comments, as well is incompatible
> > with having multiple people making patch suggestions for the same
> > issue.
> 
> FWIW it only loses the comments if people comment on individual
> commits instead of commenting on the "Files changed" tab of a PR. I
> usually comment in this way on purpose instead of commenting on
> commits, so that the history of comments are kept in the PR, even
> after rebase (it might be folded if the chunk of the patch is not
> there anymore, but the comment is still in the PR). If you really want
> to comment on an individual commit (but I don't recommend it), you can
> include the reference of the PR in your comment (#42), then github
> will keep your comment attached to the PR.

This sounds really icky to me. On one hand they put so much emphasis
on branches as a grouping concept for commits. But then they want us
to forget about them when reviewing and just comment on the overall
diff? THis is wrong on many levels. If somebody sends us a huge blob
of things, and we ask them to split things into multiple smaller
patches we do so for a reason, to make it digestable for reviewing. If
we however then ignore the individual commits and review the whole
diff again, then the whole exercise is really pointless... It doesn't
get any simpler by the split, and we reviewed something different
thatn we actually are committing!  Moreover the commit msgs are
actually as much something to review as the commit bodies, and that
gets lost entirely...

I really start wondering what the github people were thinking with
this... There must be something I am missing, or the github folks
never used this stuff themselves...

Lennart

-- 
Lennart Poettering, Red Hat