[nuttx] Squashing Commits

[[e-mail] [nuttx]]

[Sorry if this is a duplicate]

Some of you have noticed that I have been squashing all PRs that consist of multiple commits. That is something that I have to do because the commit history is full of stupid useless comments like "fixed a bug", "updated some comments", etc. Some PRs consist of dozens of commits.. some that succinctly address functionality but the rest garbage, micro-detailed steps on you way to the implementation.

None of this is needed and makes my job impossible. I create the ChangeLog and the ReleaseNotes from the git log. For the NuttX 7.22 release the git log for the nuttx/ repository only was over 11 thousand lines long!!! It took me three miserably, full time days to generate more precise ChangeLogs and ReleaseNotes from the mountain of garbage in the GIT logs.

I started squashing PRs sometime before NuttX-7.23. For the 7.23 release, the nuttx/ git log was around 4 thousand lines. It still took me a full day to generate the ChangeLogs and ReleaseNotes but at least I did not contemplate suicide for multiple consecutive days.

So be forewarned ALL PRs will be squashed WITHOUT EXCEPTION. Some people have started asking me not to squash the PRs in the comments accompanying PR text. I will ignore such requests. Please don't bother to ask; I will just disappoint you. All PRs will be squashed unconditionally.

Squashing PRs does raise one complexity when you rebase from the upstream master. It will really screw up the history in your local fork. And the history will be progressively and exponentially more screwed with each squashed PR. This can be relative easily fixed in your fork by rebasing using the --onto option has described here: https://stackoverflow.com/questions/35901915/how-to-rebase-after-squashing-commits-in-the-original-branch

If you have already rebased the squashed commit, then your fork has been damaged and I don't know of any way to repair it.

Greg

[[e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
[Sorry if this is a duplicate]

I guess it wasn't.

Post by ***@yahoo.com [nuttx]
Squashing PRs does raise one complexity when you rebase from the upstream master. It will really screw up the history in your local fork. And the history will be progressively and exponentially more screwed with each squashed PR. This can be relative easily fixed in your fork by rebasing using the --onto option has described here: https://stackoverflow.com/questions/35901915/how-to-rebase-after-squashing-commits-in-the-original-branch

Another thing you can do is to do all of your development of a branch. I have been doing this myself when I know in advance that the work is going to requiret multiple commits (because, sadly, I am the perpetrator of most of the "stupid useless comments").

git branch project1
git checkout project1

Then, when I complete all of the work on the 'project1' branch, I squash all of the changes into one commit on the master:

git checkout master
git merge --squash project1

If the PR is now against the master, there will be only one commit on the master, the PR will be only one commit, there will be no squash, there will be no possibility of corrupting the history.

After you have squashed the 'project1' branch to master you can get rid of it and all of its history:

git branch -D project1

Or, if you want to preserve the branch, merge back from master using the --onto option as I mentioned in the previous email

Greg