Re: updating merge request

[Jean Abou Samra]

Le 20/01/2023 à 23:45, David Zelinsky a écrit :
> > Note that it's not strictly necessary that a merge request consists of
> > one commit only: Logically independent "smallish" commits are fine
> > (possible example: one commit for the feature, one for the larger
> > documentation revision the feature necessitates). But always make sure
> > that each single commit gives a "working" version of LilyPond in order
> > to allow for bisecting later ...
> I see the logic in this.  In my case, most of the the MR reviews were
> pointing out typos or small stylistic corrections.  I can see that it
> makes sense to fix those with an --amend.  But one of the reviews
> (Jean's) suggested adding a few inline examples in the documentation I
> had written.  Is that something that's worth including as a new commit?
> Both versions are complete and valid; it's just a question of which is
> better.  After everyone sees the examples I've added, the consensus
> *might* be the original version was best.
>
> Does that make sense?



Not worth a separate commit IMHO. (Objections against adding examples
seem unlikely.)



> > (Personally, I use two local branches for developing a feature: one in
> > which I keep track of my progress by adding commit after commit, and
> > one which is the "squashed" version that I update with amend/squash
> > and use for pushing. git's interactive rebase feature is my best
> > friend here. But there might be better methods.)
> Yes, in any case I have no intention of overwriting my own local
> history.  I like to commit frequently, so each commit reflects some
> specific change, not a bunch of different things.  I will rebase -i on a
> parellel branch and squash the things that don't warrant new commits in
> the MR.



As you wish, however this sounds like it will involve lots of busywork.

In general, if splitting into multiple commits helps understanding,
it should be in the branch submitted for review anyway. If it doesn't,
it's not clear to me why you want the chronology for yourself, but
it's your choice of course.

OpenPGP_signature
Description: OpenPGP digital signature