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.
People are bizarrely terrified of merge commits.
https://github.com/jleclanche/fireplace/commits/master
Versus a merge tree:
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!
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.
Whether it's faster to search for something in a flat tree or not remained to be proven. It feels like it's mostly a matter of personal taste.
Point is, it's good to have both. And personally, I find terraform's git log unreadable and unusable.
In terms of the preservation of useful information, I vastly prefer the merge tree. And using merge trees appropriately and never using merge trees at all are both matters of discipline.
Edit: And for fucks sake can't I be happy GitHub implemented an outstanding feature request I've personally been asking for years? The cynicism from some of the people on this site really gets to me sometimes. Stop.
The problem is that this merge option is considered by many to be actively harmful, and GitHub adding support for this is basically them tacitly saying that this is a perfectly fine merge method to use. This will almost certainly cause an increase in the number of people using this merge method, which is a shame as it really should be discouraged instead of encouraged.
The other problem is the main argument in favor of this merge method is the fact that GitHub displays non-linear commit histories terribly. That should not be an argument in favor of having a poor merging strategy, that should be an argument in favor of GitHub revamping their commit history display to actually be useful.
It is not up to you to decide other people's and teams' workflows. It is not up to you to decide what is or isn't harmful in the context of another team. And it is certainly not up to you to decide that GitHub shouldn't provide features their paying customers are asking for, because of concerns of a completely different context and workflow.
I appreciate that you are more than familiar with git, but that doesn't give you free reign to decide what is and isn't an antipattern for other people. In fact, you should understand far better than the average HN user just how absurd your reasoning is if you'd step back from it a little.
What you call antipattern, a lot of people call feature. If GitHub now clashes with you on a philosophical level, consider moving to GitLab (oh, wait, GL has supported this and far worse for a far longer time).
The developers using rebase flows do not affect your life. They do not affect your work. They, and their "antipatterns", are as harmful to you as an iOS user is to an Android one. And your merge flow does not affect me. What does affect me is reading constant unwarranted negativity on Hacker News, a community where my expectations have so far been above those of reddit's unending stream of cynicism. And it bugs me far, far more that this has been your reaction to a company listening to its customer base, than you or I could ever care about deciding what flow is or isn't an antipattern.
Bloody hell.
> The developers using rebase flows do not affect your life.
Yes they do. If they didn't affect my life, I wouldn't care. But every time I have to deal with an open-source project that adopts this workflow, it affects me. Every time I end up working on a project that's adopted this workflow, it affects me. And it affects me in more subtle ways too, such as tooling being geared around a largely-linear history instead of a history with lots of merges (e.g. GitHub's commit history display).
> And it bugs me far, far more that this has been your reaction to a company listening to its customer base
They're barely listening. There's a long list of far more valuable changes they could make, that they're not doing, because they seem to not really care. It took an extremely long time, a very high-profile blog post calling them out, and competition from GitLab for them to finally start improving the core of their product (pull requests), and they're still missing a lot of useful functionality (e.g. rebase tracking). And of course they haven't even touched the commit history display, even though, as has been mentioned multiple times, it really sucks for a non-linear history. In fact, most of their product hasn't improved in a long time.
Don't build a series of commits where a later one fixes an earlier one; organize them into a logical series of changes, such that the project works after each commit.
Right now build systems don't even do the "build and test the final commit" bit right; it should of course test against a pre-merge (not on the branch) but again that tends to be a pain to set up.
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.
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).
Isn't that essentially what this is? It's a rebase followed by a fast-forwarded merge, there should be no merge commit.
I'm amazed at how many companies allow branches rather than allowing repo forks.