Le 20/01/2023 à 10:36, Aaron Hill a écrit :
On 2023-01-19 11:01 pm, Werner LEMBERG wrote:[SNIP] Nope. The preferred way is to make the MR's commit as pretty as possible. No final squashing.That *almost* seems like squashing, but with more steps. Certainly, there is nothing to squash if everything is expressed neatly in one commit. At the end of the day, it makes for a nice clean history in the main line either way you approach.The only critique might come down to where one is expected to apply their effort. When possible, engineers should take advantage of automated systems so their time is spent primarily on the problem at hand. That could mean using linters to reformat code, leveraging continuous integration to run test suites, or (in this case) letting repositories systematically squash (or rebase, or whatever) when accepting requests. It saves contributors making ambiguous choices and/or doing what amounts to busy work.I will need to remember to keep my branches tidy before I submit anything, since I cannot rely on squash as a crutch.
In our case, Gitlab's feature to automatically squash all commits upon merging doesn't fit the bill because we often do MRs with multiple commits that we *do* want to end up as separate commits in master (Lukas gave an exampe). Rewriting history is just something that one might not be used to coming from other projects, but perfectly fine for our purposes. In the end, doing "git commit --amend --no-edit" isn't more work than "git commit -m 'fix it'", especially with an alias. In case that helps anyone, I have these in my ~/.gitconfig, to make editing the history more convenient: [alias] reword = commit --amend pushfl = push --force-with-lease sync = rebase master rework = !git rebase -i $(git merge-base HEAD master) continue = rebase --continue abort = rebase --abort fixup = commit --amend -a --no-edit select-fixup = commit --amend --no-edit Jean
OpenPGP_signature
Description: OpenPGP digital signature