Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Date: Fri, 22 Mar 2019 13:34:48 +0300
> From: Konstantin Kharlamov <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> > There's no requirement in Emacs development to send patches in series,
> > you can send a single patch for the entire changeset.  then you will
> > get only one notification.
> 
> This is odd, why would I do that?

You don't _have_ to.  I'm saying that you _can_ if that makes things
easier for you.

> If somebody would squash 20 commits into just one, and sent me for
> review, "break commits by functional" would be my very first
> comment.

You won't hear such comments here.  This is not one of the projects to
which you are used, this is Emacs.

> How a reviewer supposed to give any useful comments besides
> high-level stuff like "remove the commented out code there", if a
> sigle patch does 20 functionally different changes?

I was talking about a single changeset, i.e. a set of changes that fix
a particular problem or introduce a particular single feature.  The
rules for deciding what should be in a single changeset and what
should be split between several ones are unaffected by what I said;
the point is that you can submit changes for a single changeset as a
single patch.

If you do submit a single coherent changeset, trust me and others here
that we will be able to review it.  It's not your problem as a
submitter.

OTOH, submitting in a single submission to a single bug report a patch
series which constitute more than a single changeset _will_ get you
responses saying to break that into several unrelated reports and
series.

> Furthermore: if such patch was commited, how other developers in the 
> future, while studying the git-log, are supposed to make any sense of 
> this commit?
> 
> And how one supposed to git-bisect a regression with such a commit?

We do that all the time.  Many (most) of the contributors rebase their
changes on the latest master anyway, so this has to be dealt with
regardless of how you submit the patches.  E.g., most of those who
create public feature branches in the Emacs repository will rebase
before landing the feature, thus making bisection inside the branch
development very hard at best.