5 ms·

> This is also the primary reason why I highly dislike merge commits: They make git logs extremely unreadable. I really really disagree. If the branch has one

> This is also the primary reason why I highly dislike merge commits: They make git logs extremely unreadable. I really really disagree. If the branch has one logical commit then no merge commit is needed. Otherwise the merge commit shows what happened and more importantly that these N commits came into the mainline as a single change.

adtac 8y ago
I fail to see how that would be useful. Commits are supposed to be atomic, self-contained changes by themselves. More often than not, I see merge commits only when people abuse commits for temporary state of work (with useless commit messages like "fix" and "temp"). Instead, if each commit did one thing and one thing only, why would you need a visual indicator that these set of commits came from a particular branch?
- jonahx 8y ago
  Because they are logically grouped and that grouping is often more important than the commits themselves -- together, they accomplish a higher-level goal. You want both that goal and the individual tasks which achieved it to be visible.
  - adtac 8y ago
    That information can and should be a part of the commit body. An extra commit just for that information is, in my opinion, a hack and a workaround. I guess we have fundamental differences on how a tree should be structured. It's more of a DAG in your case, but I prefer to keep a tree a tree.
    - jonahx 8y ago
      Not sure I follow your argument. How would you put information about the semantic meaning of a series of commits into "the commit body"? The only point I'm making essentially is that "the commit" is too granular to capture all the information you need about your work and its history. You need some kind of grouping mechanism as well. It doesn't have to be merge commits, necessarily. But as I understood it, your original argument was that "there is no need for anything higher level than a commit." But there clearly is imo.
      - Thiez 8y ago
        If you tag HEAD after each merged PR you can still see which commits belong together, they'll be between two tags.
        jonahx 8y ago
        Yeah, when I said: > It doesn't have to be merge commits, necessarily. I was thinking of a tagging strategy.
scrollaway 8y ago
So tell me, this is readable for you? https://imgur.com/GCWsFwU https://imgur.com/GCWsFwU And I'm not cherry-picking... I usually see much, much worse git logs than this from merge-commit users. In fact, if I scroll down, this is what it looks like: https://imgur.com/a/nQXWa4Q https://imgur.com/a/nQXWa4Q Edit: For a point of comparison, here's one of my projects using atomic commits and rebases: https://imgur.com/a/vTZ5qxT https://imgur.com/a/vTZ5qxT
- monsieurbanana 8y ago
  Let me fix this for you... git log --first-parent With that switch and writing correct merge-commit messages you get the best of both approaches.
  - scrollaway 8y ago
    "And correct merge-commit messages" -- I've NEVER seen those. In 99.99999% of projects, this is what you'll get: https://imgur.com/a/4f6Hw2w https://imgur.com/a/4f6Hw2w
    - monsieurbanana 8y ago
      You're moving goalposts. Yes almost nobody changes the default merge-commit message. But that's because, like you, they don't know about --first-parent (or they just don't care about commit history) That doesn't mean using merge-commits is wrong, that means people write bad commit messages, which you already complained about.
      - scrollaway 8y ago
        … am I moving goalposts? I do know about --first-parent and it is not intended to be a feature to make git logs readable. It gets rid of nearly the entire git history. At this point, you might as well simply go to the github page and look at merged PRs; that will actually get you something readable. I fear you may be terribly misunderstanding the point of atomic commits and readable commit messages. Everything within a merge commit will still come up during a bisect, for example. If the commits are non-atomic and/or they are badly written, that is still an issue. --first-parent hides the problem, and adds a new one. I'm not sure what your thinking is. Once again, what's more readable to you of all the screenshots I linked?
lysp 8y ago
I go one step further - All changes (even single commits) are in a feature branch. Feature branch is prefixed with issue number. eg. PROJ-1234-update-ui-to-do-something. That ensures that every commit is logged against an issue. If you list --first-parent and show the list of merge commits, you see a list of features which were implemented into the dev branch. If you need to drill down into lower level changes of a feature, you can look at the individual commits that were made in that branch. That way merge commits are atomic commits of features, and commits in a branch are logical commits/steps for an individual feature. And in answer to the original post - I try to make all commits have a message of what was the type of change, what the change was, and where it was. eg. "Added a clear button to reset all form elements on the update address page". The general rule is, you should be able to read the commit message and know exactly what was changed and where. Compared to "Added clear button".
- scrollaway 8y ago
  This is IMO a potentially good system but it requires a lot of rigor. In my experience, such systems break down unless they are rigidly enforced, and that's never fun for anybody.
  - lysp 8y ago
    The way I have set it up is to do 2 things: 1) Create a post-commit hook script that only allows commits into feature branches. This prevents accidentally committing into the dev/master branches (it still allows merges). 2) Create a script file that all developers use to start / end features which handles all the branch creation, pushing and pulling. That way the process is standardised and you cant make a mistake. eg. * script startfeature abc123-this-is-new-feature * script endfeature (this automatically picks up local open features) The only time there is ever an issue is when the end-feature causes a conflict. This is solved by rebasing your local branch, fixing up any issues in your commmits and then ending it again.
- maelkum 8y ago
  I am using this method to a great success at my current job. It leads to always having a clear, well-defined place where you look for changes related to issue XYZ. Support from tooling also helps a lot, e.g. "checkout branch of issue XYZ".

adtac 8y ago

I fail to see how that would be useful. Commits are supposed to be atomic, self-contained changes by themselves. More often than not, I see merge commits only when people abuse commits for temporary state of work (with useless commit messages like "fix" and "temp"). Instead, if each commit did one thing and one thing only, why would you need a visual indicator that these set of commits came from a particular branch?

jonahx 8y ago
Because they are logically grouped and that grouping is often more important than the commits themselves -- together, they accomplish a higher-level goal. You want both that goal and the individual tasks which achieved it to be visible.
- adtac 8y ago
  That information can and should be a part of the commit body. An extra commit just for that information is, in my opinion, a hack and a workaround. I guess we have fundamental differences on how a tree should be structured. It's more of a DAG in your case, but I prefer to keep a tree a tree.
  - jonahx 8y ago
    Not sure I follow your argument. How would you put information about the semantic meaning of a series of commits into "the commit body"? The only point I'm making essentially is that "the commit" is too granular to capture all the information you need about your work and its history. You need some kind of grouping mechanism as well. It doesn't have to be merge commits, necessarily. But as I understood it, your original argument was that "there is no need for anything higher level than a commit." But there clearly is imo.
    - Thiez 8y ago
      If you tag HEAD after each merged PR you can still see which commits belong together, they'll be between two tags.
      - jonahx 8y ago
        Yeah, when I said: > It doesn't have to be merge commits, necessarily. I was thinking of a tagging strategy.

scrollaway 8y ago

So tell me, this is readable for you? https://imgur.com/GCWsFwU https://imgur.com/GCWsFwU And I'm not cherry-picking... I usually see much, much worse git logs than this from merge-commit users. In fact, if I scroll down, this is what it looks like: https://imgur.com/a/nQXWa4Q https://imgur.com/a/nQXWa4Q Edit: For a point of comparison, here's one of my projects using atomic commits and rebases: https://imgur.com/a/vTZ5qxT https://imgur.com/a/vTZ5qxT

monsieurbanana 8y ago
Let me fix this for you... git log --first-parent With that switch and writing correct merge-commit messages you get the best of both approaches.
- scrollaway 8y ago
  "And correct merge-commit messages" -- I've NEVER seen those. In 99.99999% of projects, this is what you'll get: https://imgur.com/a/4f6Hw2w https://imgur.com/a/4f6Hw2w
  - monsieurbanana 8y ago
    You're moving goalposts. Yes almost nobody changes the default merge-commit message. But that's because, like you, they don't know about --first-parent (or they just don't care about commit history) That doesn't mean using merge-commits is wrong, that means people write bad commit messages, which you already complained about.
    - scrollaway 8y ago
      … am I moving goalposts? I do know about --first-parent and it is not intended to be a feature to make git logs readable. It gets rid of nearly the entire git history. At this point, you might as well simply go to the github page and look at merged PRs; that will actually get you something readable. I fear you may be terribly misunderstanding the point of atomic commits and readable commit messages. Everything within a merge commit will still come up during a bisect, for example. If the commits are non-atomic and/or they are badly written, that is still an issue. --first-parent hides the problem, and adds a new one. I'm not sure what your thinking is. Once again, what's more readable to you of all the screenshots I linked?

lysp 8y ago

I go one step further - All changes (even single commits) are in a feature branch. Feature branch is prefixed with issue number. eg. PROJ-1234-update-ui-to-do-something. That ensures that every commit is logged against an issue. If you list --first-parent and show the list of merge commits, you see a list of features which were implemented into the dev branch. If you need to drill down into lower level changes of a feature, you can look at the individual commits that were made in that branch. That way merge commits are atomic commits of features, and commits in a branch are logical commits/steps for an individual feature. And in answer to the original post - I try to make all commits have a message of what was the type of change, what the change was, and where it was. eg. "Added a clear button to reset all form elements on the update address page". The general rule is, you should be able to read the commit message and know exactly what was changed and where. Compared to "Added clear button".

scrollaway 8y ago
This is IMO a potentially good system but it requires a lot of rigor. In my experience, such systems break down unless they are rigidly enforced, and that's never fun for anybody.
- lysp 8y ago
  The way I have set it up is to do 2 things: 1) Create a post-commit hook script that only allows commits into feature branches. This prevents accidentally committing into the dev/master branches (it still allows merges). 2) Create a script file that all developers use to start / end features which handles all the branch creation, pushing and pulling. That way the process is standardised and you cant make a mistake. eg. * script startfeature abc123-this-is-new-feature * script endfeature (this automatically picks up local open features) The only time there is ever an issue is when the end-feature causes a conflict. This is solved by rebasing your local branch, fixing up any issues in your commmits and then ending it again.
maelkum 8y ago
I am using this method to a great success at my current job. It leads to always having a clear, well-defined place where you look for changes related to issue XYZ. Support from tooling also helps a lot, e.g. "checkout branch of issue XYZ".