(Replying to PARENT post)

> I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition?

The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Often my first attempt at a change does something in an illogical order, or I make related changes that later end up in a separate merge. In the short term that change in thinking is somewhat interesting. In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.

The stronger version of this completely discards any history when merging a feature, but I often find that to get rid of useful information.

๐Ÿ‘คjorams๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

You might be interested in this take on rebase then

https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

> The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.

๐Ÿ‘คPH95VuimJjqBqy๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

Small "cleanup" changes required after merging a larger change are often very educational. They highlight subtle nuances in the code that were not thought of when the large change was merged. If the smaller changes were rebased to make one large commit, the edge-case history is also lost.
๐Ÿ‘คprirun๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

> The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps.

Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either.

> In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.

Source control is the wrong tool for this job, that's what comments and tickets are for. Source control can help you retroactively figure out how and sometimes why something evolved in a certain way, like a good archaeological tool, but we don't use crude tools when there are better tools.

I've taken to literally embedding ticket numbers along with comments directly in the code and in commit comments to document exactly why code does what it does. All functional changes are tied to tickets [1], and the tickets contain the full context, and the code comments contain a summary of that rationale. Use the right tool for the job.

[1] where "functional changes" means changes that can affect behaviour, rather than stylistic changes on variable naming or revising comments that have no visible effects.

๐Ÿ‘คnaasking๐Ÿ•‘2y๐Ÿ”ผ0๐Ÿ—จ๏ธ0