3 ms·

It's pretty easy though. Leave all the commits. Put meaningful messages in your merge commits, and your clean macro history is just merge commits and the messy

It's pretty easy though. Leave all the commits. Put meaningful messages in your merge commits, and your clean macro history is just merge commits and the messy one is the rest.

nomel 5y ago
Doesn’t this require that you get everything right before that merge commit? I often do this, but then have some integration related change that’s required after.
- dec0dedab0de 5y ago
  The change after would just be a new branch and then a new merge. First merge is adding the feature second merge is the bug fix.
astrange 5y ago
Merge commits prevent having clean history, because they lie to you. If you "git show" a merge commit, it hides almost all changes because they've been automatically merged, but it doesn't follow that they were merged correctly. This can cause things like gotofail.
- eMGm4D0zgUAVXc7 5y ago
  You can show the full changes by one of these: > git show --first-parent COMMIT # perspective of target branch = branch you were on when merging > git show -m COMMIT # perspective of both branches Lengthy explanation and more ways to do it: https://stackoverflow.com/questions/40986518/git-show-of-a-merge-commit https://stackoverflow.com/questions/40986518/git-show-of-a-m... Also the following works in my experience and is more easy to memorize because the command literally says what you want to know: > git diff COMMIT_BEFORE_MERGE..MERGE_COMMIT
- Twisol 5y ago
  I think the scenario you've described assumes that the branches have diverged -- that each branch has a commit not on the other. But if you always rebase your branch onto `develop` before merging, your branch definitively has no conflicts. If you then use `--no-ff` to merge, it will create a merge commit anyway. This article shows what I mean: https://euroquis.nl/blabla/2019/08/09/git-alligator.html https://euroquis.nl/blabla/2019/08/09/git-alligator.html . (The only thing missing is the rebase before merge, since the example image shows a case where a merge could have hidden some changes.)
  - thayne 5y ago
    If you do that then, the diff in git show for the merge commit will always be empty. But I think it's a solvable problem, there just needs to be a better/easier way to say, show the diff between the one side of the merge (usually the first/left) and the result of the merge when showing a merge commit. Or maybe there is an option I'm not familiar with. That said the rebase followed by --no-ff merge is my preferred approach as well.
    - Twisol 5y ago
      If [commit] is the merge commit for the feature, then this should work: git show [commit]^1..[commit] The ^1 incantation means "first parent", so in the feature branch style I'm describing, this would show the changes on all of the commits for the feature merged at [commit]. You can use `git diff` instead of `show` in the same way, if you just want the cumulative diff. It seems to work on the repository I've been contributing to, as it shows each of the commits that were part of the feature branch. The merge commit itself is empty, as desired, avoiding the up-thread concern of unreviewed auto-merged code.
jerf 5y ago
I want a clean merge history I can run git bisect against. The utility of git bisect is much diminished when the commit history is full of broken commits. It works best when all the commits successfully run the test suite at the time, which is perhaps not the highest standard of "clean commit" we could ask for but my impression is that it puts it fairly high vs. the "commit everything" criterion.
- ilammy 5y ago
  > I want a clean merge history I can run git bisect against. "git bisect" supports "--first-parent" too.
  - freewilly1040 5y ago
    All of these arguments are of the flavor “git supports —-flag-1%-of-users-know so that works.” But there’s a nontrivial cost to teaching all of your users a non default workflow, which you have to pay for every new person that comes along.
  - jerf 5y ago
    It doesn't matter what git supports if I'm bisecting into history where the tests don't run cleanly on every commit. Now I don't know whether the test case I'm bisecting with is broken because it's revealing the bug or if it's broken because the commit is broken. git bisect is literally mathematically useless if you get even a single --good or --bad wrong.

It's pretty easy though. Leave all the commits. Put meaningful messages in your merge commits, and your clean macro history is just merge commits and the messy one is the rest.

nomel 5y ago

Doesn’t this require that you get everything right before that merge commit? I often do this, but then have some integration related change that’s required after.

dec0dedab0de 5y ago
The change after would just be a new branch and then a new merge. First merge is adding the feature second merge is the bug fix.

astrange 5y ago

Merge commits prevent having clean history, because they lie to you. If you "git show" a merge commit, it hides almost all changes because they've been automatically merged, but it doesn't follow that they were merged correctly. This can cause things like gotofail.

eMGm4D0zgUAVXc7 5y ago
You can show the full changes by one of these: > git show --first-parent COMMIT # perspective of target branch = branch you were on when merging > git show -m COMMIT # perspective of both branches Lengthy explanation and more ways to do it: https://stackoverflow.com/questions/40986518/git-show-of-a-merge-commit https://stackoverflow.com/questions/40986518/git-show-of-a-m... Also the following works in my experience and is more easy to memorize because the command literally says what you want to know: > git diff COMMIT_BEFORE_MERGE..MERGE_COMMIT
Twisol 5y ago
I think the scenario you've described assumes that the branches have diverged -- that each branch has a commit not on the other. But if you always rebase your branch onto `develop` before merging, your branch definitively has no conflicts. If you then use `--no-ff` to merge, it will create a merge commit anyway. This article shows what I mean: https://euroquis.nl/blabla/2019/08/09/git-alligator.html https://euroquis.nl/blabla/2019/08/09/git-alligator.html . (The only thing missing is the rebase before merge, since the example image shows a case where a merge could have hidden some changes.)
- thayne 5y ago
  If you do that then, the diff in git show for the merge commit will always be empty. But I think it's a solvable problem, there just needs to be a better/easier way to say, show the diff between the one side of the merge (usually the first/left) and the result of the merge when showing a merge commit. Or maybe there is an option I'm not familiar with. That said the rebase followed by --no-ff merge is my preferred approach as well.
  - Twisol 5y ago
    If [commit] is the merge commit for the feature, then this should work: git show [commit]^1..[commit] The ^1 incantation means "first parent", so in the feature branch style I'm describing, this would show the changes on all of the commits for the feature merged at [commit]. You can use `git diff` instead of `show` in the same way, if you just want the cumulative diff. It seems to work on the repository I've been contributing to, as it shows each of the commits that were part of the feature branch. The merge commit itself is empty, as desired, avoiding the up-thread concern of unreviewed auto-merged code.

jerf 5y ago

I want a clean merge history I can run git bisect against. The utility of git bisect is much diminished when the commit history is full of broken commits. It works best when all the commits successfully run the test suite at the time, which is perhaps not the highest standard of "clean commit" we could ask for but my impression is that it puts it fairly high vs. the "commit everything" criterion.

ilammy 5y ago
> I want a clean merge history I can run git bisect against. "git bisect" supports "--first-parent" too.
- freewilly1040 5y ago
  All of these arguments are of the flavor “git supports —-flag-1%-of-users-know so that works.” But there’s a nontrivial cost to teaching all of your users a non default workflow, which you have to pay for every new person that comes along.
- jerf 5y ago
  It doesn't matter what git supports if I'm bisecting into history where the tests don't run cleanly on every commit. Now I don't know whether the test case I'm bisecting with is broken because it's revealing the bug or if it's broken because the commit is broken. git bisect is literally mathematically useless if you get even a single --good or --bad wrong.