Re: github mirror of lilypond?

[Jonas Hahnfeld]

General things first: The UI of Gerrit v3 seems to be much nicer than
its previous version. Back then I found it incredibly hard to just look
at the diff. I just made another attempt for a random change from 
https://gerrit.wikimedia.org/ - does it really try to open a new tab
for each file if I click "Open All"? After managing to get into the
diff view, do I really need to navigate through the files one by one?
Preferably I'd like the diff of all files on one page, Rietveld at
least gives me the possibility to "Jump to" a named file.

With Gerit v3, I get an obvious "expand all" - wow.

Am Sonntag, den 19.01.2020, 08:50 +0100 schrieb Han-Wen Nienhuys:
> You can think of Gerrit as Rietveld v2
> 
> This somewhat off-topic, but the main reason people dislike Gerrit is
> that it requires contributors to put a Change-Id line in the bottom of
> the commit message, see eg.
> 
>   
> https://review.gerrithub.io/c/lilypond/lilypond/+/482034
> 
> 
> As one reworks the series of commits, the ChangeId is kept in place.
> This has the advantage that you can track how a proposed change
> evolves across the review process, and that you can easily submit
> multi-part changes for review.

That doesn't really bother me: As far as I understand that's as easy as
properly setting up a local commit hook.

> In the above, I sent a stack of 7
> commits for review at once.

That's where "Relation chain" and "Submitted together" come into play,
right? Funnily enough, "Submitted together" only shows predecessors...

From a high level, I think Gerrit expects reviewers to accept each
change individually. Does this really model the development style of
LilyPond? Being relatively new, I got the perception that we usually
split up a change into logically grouped commits. Eventually I want
them to be viewed and submitted as one push, not one by one as the
individual commits are accepted.
In that regard I really like how Pull Requests / Merge Requests in
GitHub / GitLab / gitea work: You can look at commit granularity if you
want to, but in the end you accept the whole thing. That's also good
because changes to a predecessor might require reworking later patches.

> Working with a single commit requires using commit --amend and with
> multiple commits requires using rebase -i, both of which Git newbies
> seems a little scared of.

Right, but as most other tools you can probably just upload and update
a patch file somewhere? That would be the easiest solution for new
contributors.

Jonas

> 
> On Sun, Jan 19, 2020 at 4:34 AM Karlin High <
> address@hidden
> > wrote:
> > On 1/18/2020 4:59 AM, Jonas Hahnfeld via Discussions on LilyPond
> > development wrote:
> > > I strongly dislike Gerrit, it's really hard to learn and even after
> > > some time I still can't figure out how to use it correctly.
> > 
> > This topic is outside my expertise. But I understood that Gerrit and
> > Rietveld are both descendants of Google's proprietary internal-use
> > Mondrian code review tool.
> > 
> > <
> > https://www.gerritcodereview.com/about.html
> > >
> > 
> > I see quite a few patches lately that show Jonas Hahnfeld as the author...
> > 
> > <
> > https://codereview.appspot.com/user/hahnjo
> > >
> > <
> > https://git.savannah.gnu.org/cgit/lilypond.git/log/?qt=author&q=Jonas+Hahnfeld
> > >
> > 
> > ...so I'm wondering if Rietveld has you suffering in silence ;) or if
> > the fork and rewrite mentioned on that Gerrit "about" page has greatly
> > diverged the user experiences of these respective products?
> > --
> > Karlin High
> > Missouri, USA
> 
> 
> 
>

signature.asc
Description: This is a digitally signed message part