Why include `-m` in git log?

[Tom-van-Woudenberg]

In my previous PR #99, I added an option to deal with unwanted merge commits. However, I was wondering why to include those merge commits at all? Wouldn't it make sense to by default exclude merge commits and deduct the date on the commits which actually add content? I'd propose to remove the -m option in the git log command by default and only add it as optional (with or without the --first-parent option). If you agree @mgeier I'll open a new PR.

[mgeier]

Thanks for this suggestion!

I must confess that I'm not an expert with regards to all the git command line options, I've mostly found the current set of arguments by trial and error (and with help from other contributors!).

I had forgotten about this, but I did some digging in the git history of this repo and found #25 (which happened nearly 5 years ago). It turns out that for a very short time I had used --first-parent, but I have then replaced it with -m. I may have been mistaken, but I wrote this about --first-parent:

This means that the "last changed" date will actually be the date of the merge commit and not the individual commit within the merged branch. In other words, it will be the "change accepted date" rather than the "change authored date".

Is that correct or did I make this up?

Anyway, feel free to make a PR and educate me about the intricacies of those flags!

[Tom-van-Woudenberg]

Thank you for your quick reponse.

This means that the "last changed" date will actually be the date of the merge commit and not the individual commit within the merged branch. In other words, it will be the "change accepted date" rather than the "change authored date".

I've difficulty with the git commands too, but I think the what you say is actually the effect of -m.

How I think it works: -m gives merge commits a list of file changes, so like regular commits leading to dates being added for a merge instead of the acutal content change.

The --first-parent option only follows the main line history, so it prevents commits within other branches (like "merge main into feature" commits) from affecting the dates. Without it, you could see later dates from when main was merged into another branch, even though the change happened earlier. Combined with -m, that means that the "merge" date is used rather than the actual content authored date.

This could be a desired way showing dates (merge dates instead of actual change dates), but I think not the preferred one. The preferred one would have neither the -m nor --first-parent flag, so that we can distinguish merge commits from 'content changing' commits.

I'll open a PR where I did that (removed those steps but kept them as an option). However, I now have difficulty parsing the log because the output of those merge commits is now different. Could you have a look?

[mgeier]

Combined with -m, that means that the "merge" date is used rather than the actual content authored date.

According to my experiments with git (see my comments in #101), I don't think that adding -m to --first-parent makes any difference.

And -m on its own shows even the mainline changes with the "merged date". I think nobody wants that and we should simply remove it without an option.