3 ms·

Because the second parent commit of the merge commit gives you the pointer to the list of commits off the main branch where the feature is implemented. Without

by u801e 6y ago

Because the second parent commit of the merge commit gives you the pointer to the list of commits off the main branch where the feature is implemented. Without the merge commit, there would be no easy way to group commits that implement a feature.

Dylan16807 6y ago
You're focusing on the wrong part of the picture. Yes, you need that data to be stored somewhere. But the complaint is not that a merge commit or equivalent data structure exists somewhere. It's that if you get the equivalent of 'asdflklf' shown in the log, especially when it's displayed in a compact and supposedly information-dense form, something has gone wrong. If we take it as true that merge commits have no useful information by definition, shouldn't they have a blank commit message? Or a message of "merged branch X"? And why are we spending lines displaying them in the denser log formats?
- dgfitz 6y ago
  All of my merge commits say “merged x with y” and all of my branch commits say “created branch z” They are useful because it shows very clearly when a branch and merge was done. Dates and times are useful. Knowing the parent of a branch is useful. Knowing when a branch was merged back in to another branch is useful.
- u801e 6y ago
  > It's that if you get the equivalent of 'asdflklf' shown in the log I think the fundamental problem is that commands like merge and revert generate their own default commit message and don't bring up the editor so that further updates can be made. At my job, I always will tell people that they need to include why they're reverting a commit in the commit message. I haven't really done anything about enforcing standards on merge commit messages, but perhaps including the cover letter or PR description in the merge commit would be a good start.

3 ms·

Because the second parent commit of the merge commit gives you the pointer to the list of commits off the main branch where the feature is implemented. Without

by u801e 6y ago

Dylan16807 6y ago
You're focusing on the wrong part of the picture. Yes, you need that data to be stored somewhere. But the complaint is not that a merge commit or equivalent data structure exists somewhere. It's that if you get the equivalent of 'asdflklf' shown in the log, especially when it's displayed in a compact and supposedly information-dense form, something has gone wrong. If we take it as true that merge commits have no useful information by definition, shouldn't they have a blank commit message? Or a message of "merged branch X"? And why are we spending lines displaying them in the denser log formats?
- dgfitz 6y ago
  All of my merge commits say “merged x with y” and all of my branch commits say “created branch z” They are useful because it shows very clearly when a branch and merge was done. Dates and times are useful. Knowing the parent of a branch is useful. Knowing when a branch was merged back in to another branch is useful.
- u801e 6y ago
  > It's that if you get the equivalent of 'asdflklf' shown in the log I think the fundamental problem is that commands like merge and revert generate their own default commit message and don't bring up the editor so that further updates can be made. At my job, I always will tell people that they need to include why they're reverting a commit in the commit message. I haven't really done anything about enforcing standards on merge commit messages, but perhaps including the cover letter or PR description in the merge commit would be a good start.