5 ms·

Merge flows are vital for understanding the history after the fact. It should be trivial to make a view that just hides merge commits, if you're so allergic to

Merge flows are vital for understanding the history after the fact. It should be trivial to make a view that just hides merge commits, if you're so allergic to them, but you can't recover them once they're gone. For the sake of your future sanity (and your coworkers'), please stop trying to rewrite history for the sake of aesthetics. The defaults are what they are for a reason.

johnisgood 7y ago
It is not for the sake of aesthetics though. When I do, say, git pull remote-foo master, then it opens up my text editor with the default "Merge branch 'master' of git://.../foo into bar" commit message. How is this useful or informative? There are lots of repositories with this uninformative commit message. Yes, perhaps rebase is not the best way to go about it, but then could it just be a limitation of git? Or am I missing something? I am not sure. I am looking forward for https://pijul.org/ https://pijul.org/ though, it seems to solve this issue. Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one? If so, how would you do it? If it is possible, should I just have a list of all the commits' message in that one merge commit? Regardless, I see lots of "Merge branch ... of ... into ..." commit messages and they are not useful to me at all. Why do you think people keep doing it?
- Nullabillity 7y ago
  It's much more informative than not having any information about where or whether a merge happened at all, regardless of what the message is. > Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one? If there are any conflicts then it will force you to stop and resolve them, which seems like a decent point to document anything that needs to be. Otherwise, you can always amend in a more relevant message afterwards.
  - yebyen 7y ago
    > If there are any conflicts then it will force you to stop and resolve them Rebasing does this too. Can't we compromise, and agree to never allow "git pull" to spontaneously and unthinkingly create a merge commit with two parents? Instead, let's do merges of our rebased feature branches, into the trunks that they are based on, but with "no-ff" – this retains the information you wanted about what feature branches have merged into what trunks, and when. But the history of each branch maintains linearity and no commit ever has more than one parent. I don't have to work with either of you, but this is how we resolved this debate on my team, and we haven't looked back. It's not even worth having this conversation unless you need branches to be long-lived. But if someone else ever has to rebase your branch with merges in it, they'll thank you if you have honored this, and curse you under their breath if you have left these thoughtless merge commits around. Do merge, but please only merge deliberately. (I also recommend checking out Deliberate Git for a great talk on Git, with similar ideas! https://vimeo.com/72762735 https://vimeo.com/72762735)
    - Nullabillity 7y ago
      > Rebasing does this too. Can't we compromise, and agree to never allow "git pull" to spontaneously and unthinkingly create a merge commit with two parents? No. Shorter-lived branches naturally bring a smaller window to create nonsense history, but the risk is still there, and the benefits are as absent as ever. > But if someone else ever has to rebase your branch with merges in it, they'll thank you if you have honored this, and curse you under their breath if you have left these thoughtless merge commits around. So.. don't? That seems like a good thing, software should discourage you from shooting yourself in the foot.
      - yebyen 7y ago
        Making a commit with two parents is shooting yourself in the foot, because every other kind of commit can be summarized as a single diff, which means you can definitely do bisect without misery. What is the simple diff content of a merge commit which solves a conflict between two parents? There isn't one, change my mind. We both agree that software should discourage shooting yourself in the foot. We disagree about which one of us is using the feature that encapsulates the moment where shooting ourself in the foot happens. It's not nonsense history if it reflects the order that branches were actually merged, which is far more interesting than the order in which commits were written concurrently across disparate branches IMHO. If you are working with other people that can't read your thoughts, especially those who are too distant to reach you to return the favor when you have inflicted pain on them, they will appreciate it if you rebase your feature branch before submitting your PR and don't send forward an unmerged conflict unless we actually need to talk it over for some reason. On the other hand I don't know anyone who will be mad that you did this. The rebase feature exists for a reason, and so does amend, reset, squash, etc. How many of these features do you think I shouldn't use? I am only discouraging the use of one feature, the automatic octopus merge that happens when you thoughtlessly run "git pull". Why do thoughtless things? Don't you want to review the code you've pulled? Rebasing also guarantees that the commit your CI has tested is identical to the commit that becomes head after the branches merge. How do you guarantee that your branches still function properly after merges? Carefully running the tests by hand between merge and push? My test suite is too large, and we are too busy for that, friend.
jbergens 7y ago
Rebasing and keeping commits makes very easy to read history, everything is in a logical order. The order may not be the exact chronological order in which is was written but that is rarely needded, the rebases guarantee that it _could_ have been written as the history shows and you can see all changes afterwards. I have used this in projects and it worked great for the whole team for a long time. You can of course do something else which can work for you and your team.

johnisgood 7y ago

It is not for the sake of aesthetics though. When I do, say, git pull remote-foo master, then it opens up my text editor with the default "Merge branch 'master' of git://.../foo into bar" commit message. How is this useful or informative? There are lots of repositories with this uninformative commit message. Yes, perhaps rebase is not the best way to go about it, but then could it just be a limitation of git? Or am I missing something? I am not sure. I am looking forward for https://pijul.org/ https://pijul.org/ though, it seems to solve this issue. Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one? If so, how would you do it? If it is possible, should I just have a list of all the commits' message in that one merge commit? Regardless, I see lots of "Merge branch ... of ... into ..." commit messages and they are not useful to me at all. Why do you think people keep doing it?

Nullabillity 7y ago
It's much more informative than not having any information about where or whether a merge happened at all, regardless of what the message is. > Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one? If there are any conflicts then it will force you to stop and resolve them, which seems like a decent point to document anything that needs to be. Otherwise, you can always amend in a more relevant message afterwards.
- yebyen 7y ago
  > If there are any conflicts then it will force you to stop and resolve them Rebasing does this too. Can't we compromise, and agree to never allow "git pull" to spontaneously and unthinkingly create a merge commit with two parents? Instead, let's do merges of our rebased feature branches, into the trunks that they are based on, but with "no-ff" – this retains the information you wanted about what feature branches have merged into what trunks, and when. But the history of each branch maintains linearity and no commit ever has more than one parent. I don't have to work with either of you, but this is how we resolved this debate on my team, and we haven't looked back. It's not even worth having this conversation unless you need branches to be long-lived. But if someone else ever has to rebase your branch with merges in it, they'll thank you if you have honored this, and curse you under their breath if you have left these thoughtless merge commits around. Do merge, but please only merge deliberately. (I also recommend checking out Deliberate Git for a great talk on Git, with similar ideas! https://vimeo.com/72762735 https://vimeo.com/72762735)
  - Nullabillity 7y ago
    > Rebasing does this too. Can't we compromise, and agree to never allow "git pull" to spontaneously and unthinkingly create a merge commit with two parents? No. Shorter-lived branches naturally bring a smaller window to create nonsense history, but the risk is still there, and the benefits are as absent as ever. > But if someone else ever has to rebase your branch with merges in it, they'll thank you if you have honored this, and curse you under their breath if you have left these thoughtless merge commits around. So.. don't? That seems like a good thing, software should discourage you from shooting yourself in the foot.
    - yebyen 7y ago
      Making a commit with two parents is shooting yourself in the foot, because every other kind of commit can be summarized as a single diff, which means you can definitely do bisect without misery. What is the simple diff content of a merge commit which solves a conflict between two parents? There isn't one, change my mind. We both agree that software should discourage shooting yourself in the foot. We disagree about which one of us is using the feature that encapsulates the moment where shooting ourself in the foot happens. It's not nonsense history if it reflects the order that branches were actually merged, which is far more interesting than the order in which commits were written concurrently across disparate branches IMHO. If you are working with other people that can't read your thoughts, especially those who are too distant to reach you to return the favor when you have inflicted pain on them, they will appreciate it if you rebase your feature branch before submitting your PR and don't send forward an unmerged conflict unless we actually need to talk it over for some reason. On the other hand I don't know anyone who will be mad that you did this. The rebase feature exists for a reason, and so does amend, reset, squash, etc. How many of these features do you think I shouldn't use? I am only discouraging the use of one feature, the automatic octopus merge that happens when you thoughtlessly run "git pull". Why do thoughtless things? Don't you want to review the code you've pulled? Rebasing also guarantees that the commit your CI has tested is identical to the commit that becomes head after the branches merge. How do you guarantee that your branches still function properly after merges? Carefully running the tests by hand between merge and push? My test suite is too large, and we are too busy for that, friend.

jbergens 7y ago

Rebasing and keeping commits makes very easy to read history, everything is in a logical order. The order may not be the exact chronological order in which is was written but that is rarely needded, the rebases guarantee that it _could_ have been written as the history shows and you can see all changes afterwards. I have used this in projects and it worked great for the whole team for a long time. You can of course do something else which can work for you and your team.