4 ms·

> Under the hood, all the commit really says is: > Merge: 8 6 > So it tells you that these two parents have been merged together, but it doesn’t tell you whic

by neolog 5y ago

> Under the hood, all the commit really says is: > Merge: 8 6 > So it tells you that these two parents have been merged together, but it doesn’t tell you which one used to be main. You might guess 8, because it’s the leftmost one, but you don’t know for sure. Why don't I know for sure it's gotta be the one on the left?

cesarb 5y ago
> Why don't I know for sure it's gotta be the one on the left? Because of fast-forward merges. It will be the one on the left if you, as expected, were on the master branch and merged the feature branch ("git checkout master; git merge feature"). But if you were on the feature branch, merged the master branch into the feature branch (usually, this is done to resolve conflicts), and then went back to the master branch and merged the resulting feature branch into it ("git checkout feature; git merge master; git checkout master; git merge feature"), it will be a fast-forward merge: no new commit will be created, and master will point to the merge commit which was originally on the feature branch, which is going on the opposite direction as you would expect. The solution, as others have already mentioned here, is to do all merges to master as non-fast-forward ("git merge --no-ff feature"); that gives a consistent order to all merge commits on the master branch, and the end effect is the most similar to the "grouping" feature OP wants (if everything on master are these non-fast-forward merges, the difference between one merge and the preceding one is that "group").
- neolog 5y ago
  Thanks. - It's still ok to "git-pull --ff=only", right? - Is it possible to enforce this at the CI level?
  - wizzwizz4 5y ago
    Yes to both, though I don't know how to enforce it. (A push hook would do.)
- rusebor 5y ago
  > which is going on the opposite direction as you would expect. It looks like a bug which should be fixed. Git should create a merge commit when it sees that "the direction" changes.

by neolog 5y ago

cesarb 5y ago

> Why don't I know for sure it's gotta be the one on the left? Because of fast-forward merges. It will be the one on the left if you, as expected, were on the master branch and merged the feature branch ("git checkout master; git merge feature"). But if you were on the feature branch, merged the master branch into the feature branch (usually, this is done to resolve conflicts), and then went back to the master branch and merged the resulting feature branch into it ("git checkout feature; git merge master; git checkout master; git merge feature"), it will be a fast-forward merge: no new commit will be created, and master will point to the merge commit which was originally on the feature branch, which is going on the opposite direction as you would expect. The solution, as others have already mentioned here, is to do all merges to master as non-fast-forward ("git merge --no-ff feature"); that gives a consistent order to all merge commits on the master branch, and the end effect is the most similar to the "grouping" feature OP wants (if everything on master are these non-fast-forward merges, the difference between one merge and the preceding one is that "group").

neolog 5y ago
Thanks. - It's still ok to "git-pull --ff=only", right? - Is it possible to enforce this at the CI level?
- wizzwizz4 5y ago
  Yes to both, though I don't know how to enforce it. (A push hook would do.)
rusebor 5y ago
> which is going on the opposite direction as you would expect. It looks like a bug which should be fixed. Git should create a merge commit when it sees that "the direction" changes.