Re: updating merge request

[David Zelinsky]

Lukas-Fabian Moser <lfm@gmx.de> writes:

> Am 20.01.23 um 07:38 schrieb Aaron Hill:
>
>> On 2023-01-19 8:54 pm, David Zelinsky wrote:
>>
>>> Am I misunderstanding something?  Or is what it says in 3.2 a mistake?
>>
>> If GitLab works similar to GitHub ...
>
> Accepted practice in lilypond development is different. We all rewrite
> history ... Gitlab itself has the feature of keeping track of the
> various versions of a merge requests and letting us browse them
> conveniently.

Ok, I understand this now.  It took me a while but I finally found where
this is explained:

  https://docs.gitlab.com/ee/user/project/merge_requests/versions.html

I wish this were documented more prominently, both in the GitLab docs
and in the Contributor's Guide, since it's a GitLab feature that is
quite different from (some might say contrary to) the usual git
behavior.  Granted it is mentioned in GC 3.2, but, without more
explanation, to someone experienced with git but not GitLab it just
sounds mysterious, or like a mistake.  Maybe the CG could include the
above link.


> 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?


> (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.

-David