4 ms·

Just always do a merge commit into your main branch, and you have the best of both worlds, don't you? - A straight history of merge commits you can revert or b

Just always do a merge commit into your main branch, and you have the best of both worlds, don't you? - A straight history of merge commits you can revert or bisect. - Handy pointers to all the branches you merged, in case you ever need them (I never have, but I do use merge commits) At some point I may learn to let go and go full squash-and-rebase, which is the same thing just without the handy pointers to the dev branches (which, if I ever needed them, I'm sure there's a git command to fish them out of the repo). But for now I'm OK

TomSwirly 4y ago
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.
u801e 4y ago
> Handy pointers to all the branches you merged, in case you ever need them The one thing that GitHub does when it generates the merge commit (which it does even for fast-forward merges) is that it adds a link to the PR associated with that commit. It's a handy way to go back to the PR and see the review of the branch before it was merged. For projects that use the email patch workflow like the Linux kernel or git itself, the merge commit message contains the branch name which can be used to find the mailing list discussion. In the git project, you can find the "what's cooking" emails to find the branch name and references to the message-id of the patch series cover letter.

TomSwirly 4y ago

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.

u801e 4y ago

> Handy pointers to all the branches you merged, in case you ever need them The one thing that GitHub does when it generates the merge commit (which it does even for fast-forward merges) is that it adds a link to the PR associated with that commit. It's a handy way to go back to the PR and see the review of the branch before it was merged. For projects that use the email patch workflow like the Linux kernel or git itself, the merge commit message contains the branch name which can be used to find the mailing list discussion. In the git project, you can find the "what's cooking" emails to find the branch name and references to the message-id of the patch series cover letter.