6 ms·

This strikes me as perhaps the worst merge method possible for git. Sometimes people call your main branch soup, and this will make that an incredibly accurate

This strikes me as perhaps the worst merge method possible for git. Sometimes people call your main branch soup, and this will make that an incredibly accurate description. People are bizarrely terrified of merge commits.

yxhuvud 10y ago
Then don't use it. I'd been happy to just have an option to support fast forward merges without merge commits, but this really nails my preferred work flow.
- masklinn 10y ago
  > support fast forward merges without merge commits Isn't that essentially what this is? It's a rebase followed by a fast-forwarded merge, there should be no merge commit.
  - yxhuvud 10y ago
    Well, what I'm saying is that I'd be happy even if I had to rebase manually in the case that master had moved on since the pull request had been created.
omouse 10y ago
Indeed they are and you're going to get merge commits when you're continuing work on a branch and you're using branches rather than having people use separate repos (which is the superior choice). I'm amazed at how many companies allow branches rather than allowing repo forks.
patrec 10y ago
I, too used to wonder about this. But in git merge commits basically break bisect and revert. You can't tell git to only consider feature merges for it's bisection (which is normally what you want), nor will revert on a merge commit behave the way people expect. And not everyone enjoys reading long essays about to work around these problems.
- cesarb 10y ago
  Could you elaborate? I find it hard to believe that merge commits break bisect, since git bisect was developed for use by the Linux kernel developers, and the Linux kernel repository uses merge commits heavily.
  - stormbrew 10y ago
    As an advocate for both merges and bisect, even I have to admit that the experience of using bisect over merges can be quite terrible. I would prefer if bisect had a working --first-parent mode, because most of the time that's what I really want. Git-core seems against this, though. Not sure if it's on technical or aesthetic grounds.
  - patrec 10y ago
    Let's assume you found a serious bug in production. Probably one of the recently landed feature branches contains the offending change. If you rebase feature branches into master as a single squashed commit, things are straightforward: you run a git bisect HEAD $LAST_KNOWN_GOOD and then you might revert the offending commit and re-deploy before you dig into the problem deeper and fix the bug. If you have a normal merge based workflow, your bisect will likely require some babysitting because git doesn't offer an easy way to just bisect your merge commits into master. Firstly of course there will also be many more commits to consider, most of which you don't really care about at this point and which will slow down the bisect. More importantly some of the intermediate commits from the feature branches will almost certainly be broken, because typically not every single commit even goes through CI. You can work around that by hacking something up to ignore these commits but it's probably gonna be a pain. Once you found the problematic feature you want to back out you then will spend half an hour googling how to revert merge commits. Of course, there are advantages to having the "intermediate" commits available and if git bisect were better designed the experience with merge branches should be strictly better, but in practice it's enough of a pain that people who semantically prefer merges opt for a rebase-based workflow.
    - cyphar 10y ago
      > More importantly some of the intermediate commits from the feature branches will almost certainly be broken, because typically not every single commit even goes through CI. You can work around that by hacking something up to ignore these commits but it's probably gonna be a pain. git bisect skip. Also, if your maintainers aren't doing a `git rebase -x "make test" origin/master` before merging then you're the ones to blame. Not merge commits. > Once you found the problematic feature you want to back out you then will spend half an hour googling how to revert merge commits. `git revert <merge commit>`. Or if by "revert" you mean "change the history to the state it used to be in" you can do `git reset --hard <old HEAD using git log --first-parent>`. > Of course, there are advantages to having the "intermediate" commits available and if git bisect were better designed the experience with merge branches should be strictly better, but in practice it's enough of a pain that people who semantically prefer merges opt for a rebase-based workflow. git bisect is actually quite well designed considering it works given any two commits (even if the histories are different). To be fair, it doesn't handle histories where a bug is fixed and broken multiple times -- but there's no nice way of dealing with that (it's a hard problem to solve without iterating through each commit).
masklinn 10y ago
It is pretty good for single-commit branches, though the previous squash commit already handled that case fine.
scrollaway 10y ago
Then please don't use it. In the mean time, here's how a flat tree looks to contributors: https://github.com/jleclanche/fireplace/commits/master https://github.com/jleclanche/fireplace/commits/master Versus a merge tree: https://github.com/hashicorp/terraform/commits/master https://github.com/hashicorp/terraform/commits/master Consider that the git log is one of the first thing contributors will look at. The cleaner it is, the better the experience. I've been waiting for this for a long time. Thank you github!
- barrkel 10y ago
  The merge tree looks much more useful me; links to the PR with discussion is a lot nicer in a collaborative team than a series of commits by individuals.
  - scrollaway 10y ago
    What if your workflow primarily isn't PR-oriented? eg you have discussions on a different channel than Github. Point is, it's good to have both. And personally, I find terraform's git log unreadable and unusable.
    - stormbrew 10y ago
      I still think it's better to have a logical grouping of related work. I prefer merge commits, but even squash merges at least achieve this as well.
    - arielb1 10y ago
      I find terraform's git log to be more readable. You can get a quick overview for which commits corresponds to which feature by following the first-parent chain.
- infogulch 10y ago
  This is why people want to rebase. Now we could use some UI improvements to the github commits page to make the merge method not look so ugly. Lets say: collapse merge commits into a single gray line and roll up the commits made on the branch(es) underneath the merge commit line, maybe indented.

yxhuvud 10y ago

Then don't use it. I'd been happy to just have an option to support fast forward merges without merge commits, but this really nails my preferred work flow.

masklinn 10y ago
> support fast forward merges without merge commits Isn't that essentially what this is? It's a rebase followed by a fast-forwarded merge, there should be no merge commit.
- yxhuvud 10y ago
  Well, what I'm saying is that I'd be happy even if I had to rebase manually in the case that master had moved on since the pull request had been created.

omouse 10y ago

Indeed they are and you're going to get merge commits when you're continuing work on a branch and you're using branches rather than having people use separate repos (which is the superior choice). I'm amazed at how many companies allow branches rather than allowing repo forks.

patrec 10y ago

I, too used to wonder about this. But in git merge commits basically break bisect and revert. You can't tell git to only consider feature merges for it's bisection (which is normally what you want), nor will revert on a merge commit behave the way people expect. And not everyone enjoys reading long essays about to work around these problems.

cesarb 10y ago
Could you elaborate? I find it hard to believe that merge commits break bisect, since git bisect was developed for use by the Linux kernel developers, and the Linux kernel repository uses merge commits heavily.
- stormbrew 10y ago
  As an advocate for both merges and bisect, even I have to admit that the experience of using bisect over merges can be quite terrible. I would prefer if bisect had a working --first-parent mode, because most of the time that's what I really want. Git-core seems against this, though. Not sure if it's on technical or aesthetic grounds.
- patrec 10y ago
  Let's assume you found a serious bug in production. Probably one of the recently landed feature branches contains the offending change. If you rebase feature branches into master as a single squashed commit, things are straightforward: you run a git bisect HEAD $LAST_KNOWN_GOOD and then you might revert the offending commit and re-deploy before you dig into the problem deeper and fix the bug. If you have a normal merge based workflow, your bisect will likely require some babysitting because git doesn't offer an easy way to just bisect your merge commits into master. Firstly of course there will also be many more commits to consider, most of which you don't really care about at this point and which will slow down the bisect. More importantly some of the intermediate commits from the feature branches will almost certainly be broken, because typically not every single commit even goes through CI. You can work around that by hacking something up to ignore these commits but it's probably gonna be a pain. Once you found the problematic feature you want to back out you then will spend half an hour googling how to revert merge commits. Of course, there are advantages to having the "intermediate" commits available and if git bisect were better designed the experience with merge branches should be strictly better, but in practice it's enough of a pain that people who semantically prefer merges opt for a rebase-based workflow.
  - cyphar 10y ago
    > More importantly some of the intermediate commits from the feature branches will almost certainly be broken, because typically not every single commit even goes through CI. You can work around that by hacking something up to ignore these commits but it's probably gonna be a pain. git bisect skip. Also, if your maintainers aren't doing a `git rebase -x "make test" origin/master` before merging then you're the ones to blame. Not merge commits. > Once you found the problematic feature you want to back out you then will spend half an hour googling how to revert merge commits. `git revert <merge commit>`. Or if by "revert" you mean "change the history to the state it used to be in" you can do `git reset --hard <old HEAD using git log --first-parent>`. > Of course, there are advantages to having the "intermediate" commits available and if git bisect were better designed the experience with merge branches should be strictly better, but in practice it's enough of a pain that people who semantically prefer merges opt for a rebase-based workflow. git bisect is actually quite well designed considering it works given any two commits (even if the histories are different). To be fair, it doesn't handle histories where a bug is fixed and broken multiple times -- but there's no nice way of dealing with that (it's a hard problem to solve without iterating through each commit).

masklinn 10y ago

It is pretty good for single-commit branches, though the previous squash commit already handled that case fine.

scrollaway 10y ago

Then please don't use it. In the mean time, here's how a flat tree looks to contributors: https://github.com/jleclanche/fireplace/commits/master https://github.com/jleclanche/fireplace/commits/master Versus a merge tree: https://github.com/hashicorp/terraform/commits/master https://github.com/hashicorp/terraform/commits/master Consider that the git log is one of the first thing contributors will look at. The cleaner it is, the better the experience. I've been waiting for this for a long time. Thank you github!

barrkel 10y ago
The merge tree looks much more useful me; links to the PR with discussion is a lot nicer in a collaborative team than a series of commits by individuals.
- scrollaway 10y ago
  What if your workflow primarily isn't PR-oriented? eg you have discussions on a different channel than Github. Point is, it's good to have both. And personally, I find terraform's git log unreadable and unusable.
  - stormbrew 10y ago
    I still think it's better to have a logical grouping of related work. I prefer merge commits, but even squash merges at least achieve this as well.
  - arielb1 10y ago
    I find terraform's git log to be more readable. You can get a quick overview for which commits corresponds to which feature by following the first-parent chain.
infogulch 10y ago
This is why people want to rebase. Now we could use some UI improvements to the github commits page to make the merge method not look so ugly. Lets say: collapse merge commits into a single gray line and roll up the commits made on the branch(es) underneath the merge commit line, maybe indented.