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
