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

[Lucas De Marchi]

On Tue, Jun 9, 2015 at 7:01 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> Well, but it's really weird... If you start out with a patch things
> are tracked as PR. If you start out without a patch things are tracked
> as an issue. And they have quite different workflows, as PRs cannot be
> reopened and issues can, for example.
>
> I am pretty sure issues should be at the core of things...
>
> WHat really surprises me about the whole discussion is that we cannot
> be the first ones running into this. Given the success of github this
> must be a common issue. And if it is, then either github is actually
> prety bad, or I am too stuck in my bugzilla mindset and haven't really
> grokked the github way of doing things yet.

You really aren't.  I commented on this thread before and on my quest
to try to understand the github model I found several people with the
same problems. It's worth reading
https://github.com/torvalds/linux/pull/17#issuecomment-5654674  -
Those are not the same problems you are facing and those I really care
about, but there is much about the "github model" there.

Projects with proper per-commit review have a hard time with github
because it's not the github model.  The github model is you push a
lots of things people may suggest some changes and the original author
just pushes new code on top.  The pullrequest in github ui is just a
chronological view of out-of-place comments and new pushes. There are
exceptions to this, but it pretty much covers the vast majority of
projects really using the issues/pr featues in github.  Of course
there are the petty projects in which losing comments doesn't matter
much and reviews are pretty much superficial.  It's really hard to see
projects in github with good commit messages and proper commit
reviews.  And I'd say some of the github limitations that pushes for
this kind o behavior.

Since I care about comments in each patch what I'm doing in projects I
maintain (and I do have some private repositories) is to have
something similar to what you suggest: opening a second pullrequest
and reference the first one.  Bear in mind though the comments are
*always attached to the commit* not the pullrequest. So in the extreme
case the person sending the pullrequest removes *his* remote, you lost
the comments. This may not hurt now, but it really does after one year
when you are trying to find that comment.

Then people will try to convince you to comment on the pullrequest
rather the individual commits.  It's rather a sick place to be in for
whom are used to proper reviews. Github does has nice features,
integration with other tools, etc. But I was really shocked when their
review system was *the* reason systemd was getting aboard.

Oh... not to mention the pullrequest doesn't show commits in order
(https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/).
I was bitten by this back in 2013 when I was using github much more
and I had forgotten. Looks like things didn't change since then. Now
when I'm reviewing pullrequests I never trust to review them directly
in the browser but I rather pull all the pullrequests with a variant
of your "git pullnotes":

alias.pullpr = fetch origin refs/pull/*:refs/pull/*

-- 
Lucas De Marchi