4 ms·

Merge commits add negative value to your commit history. They are a memory of a commit ID and of a branch that no longer exist. They add complexity and empty

Merge commits add negative value to your commit history. They are a memory of a commit ID and of a branch that no longer exist. They add complexity and empty information to your project for no useful value. Also, for writing git tools, life is much easier if the commits form a tree. But a merge commit has _two_ parents. If you have even one merge commit, your commits are no longer a tree. > Handy pointers to all the branches you merged, in case you ever need them (I never have TOO MUCH INFORMATION. No, get rid of it. Extract any information you might need into the code review or the branch. I mean, that commit ID will probably float around your repo for the next six months, so it isn't like it's gone immediately. It's hoarding! Let it go! :-)

seba_dos1 4y ago
> It's hoarding! Let it go! :-) Don't. There's no cost of retaining it and it's super useful to have it when needed. Are you trying to tell me that you never use tools like bisect or blame, and find reading commit messages with justification of the whole worth of a MR instead of a single logical atomic change that are then grouped into a MR more informative? (unless you mean the exact pointer to the exact branch you worked on, in which case - sure, there's no need to keep it, rebase that branch while merging and let original commit IDs go, they're useless) In a ff-only merge workflow with merge commits, all you get from a merge commit is grouping some commits together with some commit message. There's no cost to it since you can still easily consider the whole repo to be like a tree, and it makes browsing through commit logs easier for humans without making tools like bisect less useful, like squashing does. Reading threads like this one, I get an impression that people who want to squash things away and remove information to "keep history clean" are simply not very proficient in using git as a tool that helps with development.

seba_dos1 4y ago

> It's hoarding! Let it go! :-) Don't. There's no cost of retaining it and it's super useful to have it when needed. Are you trying to tell me that you never use tools like bisect or blame, and find reading commit messages with justification of the whole worth of a MR instead of a single logical atomic change that are then grouped into a MR more informative? (unless you mean the exact pointer to the exact branch you worked on, in which case - sure, there's no need to keep it, rebase that branch while merging and let original commit IDs go, they're useless) In a ff-only merge workflow with merge commits, all you get from a merge commit is grouping some commits together with some commit message. There's no cost to it since you can still easily consider the whole repo to be like a tree, and it makes browsing through commit logs easier for humans without making tools like bisect less useful, like squashing does. Reading threads like this one, I get an impression that people who want to squash things away and remove information to "keep history clean" are simply not very proficient in using git as a tool that helps with development.