On Tue, Jun 9, 2015 at 7:01 PM, Lennart Poettering <lenn...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel