3 ms·

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

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.
stormbrew 10y ago
I don't believe the problems with visualization of merge commits are insurmountable. Nearly all the command line tools (other than, really notably, bisect) allow a --first-parent flag that makes navigating them much simpler. Even gitk supports this mode, so doing it in a gui is also possible. 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.
laurent123456 10y ago
I think both approaches are fine to be honest. I usually go for a merge tree because I don't want to bother with rebase, and whether it's a flat tree or a merge tree, I can usually find whatever I'm looking for in the log. 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.
eridius 10y ago
You should be pushing for GitHub to improve their commit display instead of celebrating them adding something that lets you contort your history to work around it.
- scrollaway 10y ago
  Right, because GitHub is obviously the only tool I, or any of my contributors, use that has a git history. (Yes, I know about whatever command line flags you're suddenly feeling the urge to tell me about) 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.
  - eridius 10y ago
    Cynicism? It's not cynicism. It's the fact that a lot of people, including me, think rebase-before-merge is an antipattern and should be discouraged.
    - scrollaway 10y ago
      "Complaining about features that people ask for getting implemented" is a far worse antipattern.
      - eridius 10y ago
        It seems you don't actually understand the complaint, and are resorting to a schoolyard "no you" tactic to try and deflect. 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.

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.

stormbrew 10y ago

I don't believe the problems with visualization of merge commits are insurmountable. Nearly all the command line tools (other than, really notably, bisect) allow a --first-parent flag that makes navigating them much simpler. Even gitk supports this mode, so doing it in a gui is also possible. 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.

laurent123456 10y ago

I think both approaches are fine to be honest. I usually go for a merge tree because I don't want to bother with rebase, and whether it's a flat tree or a merge tree, I can usually find whatever I'm looking for in the log. 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.

eridius 10y ago

You should be pushing for GitHub to improve their commit display instead of celebrating them adding something that lets you contort your history to work around it.

scrollaway 10y ago
Right, because GitHub is obviously the only tool I, or any of my contributors, use that has a git history. (Yes, I know about whatever command line flags you're suddenly feeling the urge to tell me about) 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.
- eridius 10y ago
  Cynicism? It's not cynicism. It's the fact that a lot of people, including me, think rebase-before-merge is an antipattern and should be discouraged.
  - scrollaway 10y ago
    "Complaining about features that people ask for getting implemented" is a far worse antipattern.
    - eridius 10y ago
      It seems you don't actually understand the complaint, and are resorting to a schoolyard "no you" tactic to try and deflect. 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.