4 ms·

What I wish github supported was "git rebase && git merge --no-ff", or as Azure DevOps calls it "semi-linear merge". A fairly linear history is a lot easier to

by epage 4y ago

What I wish github supported was "git rebase && git merge --no-ff", or as Azure DevOps calls it "semi-linear merge". A fairly linear history is a lot easier to read but it is nice to preserve the branch by having a merge-commit.

saghm 4y ago
That's what I prefer to use when merging locally (often from a cleaned up version of my feature branch). I'd for for it to be added, but at this point I honestly just wish there were a way for me to manually push and then have it be tied to the PR in some way that shows it as "merged" rather than "closed", since that would essentially handle not only my preference but any possible one someone could have in the future. It would be cool if there were some flag I could specify with a PR id or something when pushing, but I'm not really sure that's feasible without some sort of standard protocol, since I don't expect (and wouldn't want!) git to put in Github-specific functionality. I'd certainly settle for some menu item in Github's PR view for a maintainer to be able to do something like select a recent push from a menu to then be attached to the PR's metadata for future viewers, but at this point I doubt it will ever be added.
q7xvh97o2pDhNrh 4y ago
Genuinely asking: What's the value prop of having the merge-commit in the history for you? Have you ever capitalized on it? And if so, could you share the command-line-fu that's helped you take advantage of having such a commit in your repo history? I'm asking because I used to do exactly this and feel much the same way as you — I felt it was nice to preserve the historical context. At some point, it dawned on me that, amidst all the anecdata I'd acquired, I'd never once benefited from having those commits cluttering up the history. These days, I usually advocate "squash & merge" for the 80%+ of teams that lack the discipline to write good commit messages for every one of their branch commits. And, for those rare teams where every engineer writes thoughtful commit messages on their branches (a true delight!), I savor being able to do "git rebase && git merge --ff". Either way, we end up with a lovely linear history of (hopefully) atomic commits.
- seba_dos1 4y ago
  git log --first-parent git log --graph --oneline As long as we're not talking about single commit merges, these merge commits don't clutter the history; they enrich it.
- chrsig 4y ago
  it's way easier to revert the merge commit than potentially every commit that was included in it. having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame. With a merge commit, I can make individual commits for logical changes, potentially rebasing, or squashing commits together. that also gives an opportunity to write more intentional and informative commit messages. once i have a good changeset, I can publish a single PR for review. I've only really taken to this approach lately, for a long time I just didn't care. As the years go by, I care more and more about what git blame can tell me. I've been maintaining some projects for a long time, and I've had to pick up many projects that don't have their original authors available for consultation. In both cases, having a quality git commit log is just a time saver. I don't care about preserving the history from when the code was initially typed, I care about the context the log can provide me about the change sets that have been applied. I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" If you're dealing with a more junior team, or people that don't care about the log, it's really a toss up for me. Roll your dice on maybe an informative message helping you, or sift through 15 commits saying "poke", or squash an enormous commit and get a single sentence about it.
  - q7xvh97o2pDhNrh 4y ago
    > I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" Strongly agree with this. I hold the line on this for every team I lead (which, sadly, is not every team I consult for, so sometimes I have to keep my mouth shut and spend my political capital elsewhere). Many junior/mid-level engineers have simply never seen commit messages and source control done well. Additionally, because many folks starting out in the field don't know how to truly use git beyond memorizing a few basic commands [1], they also never harvest any of the benefits of writing great commit messages. I've got a stash of links that I find myself often sending to engineers who are on the way up, and the tpope article on git commit messages [2] is one I find myself sharing around constantly. [1]: https://xkcd.com/1597/ https://xkcd.com/1597/ [2]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
sudo_chmod777 4y ago
Vote here: https://github.com/community/community/discussions/8940 https://github.com/community/community/discussions/8940

by epage 4y ago

saghm 4y ago

That's what I prefer to use when merging locally (often from a cleaned up version of my feature branch). I'd for for it to be added, but at this point I honestly just wish there were a way for me to manually push and then have it be tied to the PR in some way that shows it as "merged" rather than "closed", since that would essentially handle not only my preference but any possible one someone could have in the future. It would be cool if there were some flag I could specify with a PR id or something when pushing, but I'm not really sure that's feasible without some sort of standard protocol, since I don't expect (and wouldn't want!) git to put in Github-specific functionality. I'd certainly settle for some menu item in Github's PR view for a maintainer to be able to do something like select a recent push from a menu to then be attached to the PR's metadata for future viewers, but at this point I doubt it will ever be added.

q7xvh97o2pDhNrh 4y ago

Genuinely asking: What's the value prop of having the merge-commit in the history for you? Have you ever capitalized on it? And if so, could you share the command-line-fu that's helped you take advantage of having such a commit in your repo history? I'm asking because I used to do exactly this and feel much the same way as you — I felt it was nice to preserve the historical context. At some point, it dawned on me that, amidst all the anecdata I'd acquired, I'd never once benefited from having those commits cluttering up the history. These days, I usually advocate "squash & merge" for the 80%+ of teams that lack the discipline to write good commit messages for every one of their branch commits. And, for those rare teams where every engineer writes thoughtful commit messages on their branches (a true delight!), I savor being able to do "git rebase && git merge --ff". Either way, we end up with a lovely linear history of (hopefully) atomic commits.

seba_dos1 4y ago
git log --first-parent git log --graph --oneline As long as we're not talking about single commit merges, these merge commits don't clutter the history; they enrich it.
chrsig 4y ago
it's way easier to revert the merge commit than potentially every commit that was included in it. having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame. With a merge commit, I can make individual commits for logical changes, potentially rebasing, or squashing commits together. that also gives an opportunity to write more intentional and informative commit messages. once i have a good changeset, I can publish a single PR for review. I've only really taken to this approach lately, for a long time I just didn't care. As the years go by, I care more and more about what git blame can tell me. I've been maintaining some projects for a long time, and I've had to pick up many projects that don't have their original authors available for consultation. In both cases, having a quality git commit log is just a time saver. I don't care about preserving the history from when the code was initially typed, I care about the context the log can provide me about the change sets that have been applied. I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" If you're dealing with a more junior team, or people that don't care about the log, it's really a toss up for me. Roll your dice on maybe an informative message helping you, or sift through 15 commits saying "poke", or squash an enormous commit and get a single sentence about it.
- q7xvh97o2pDhNrh 4y ago
  > I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" Strongly agree with this. I hold the line on this for every team I lead (which, sadly, is not every team I consult for, so sometimes I have to keep my mouth shut and spend my political capital elsewhere). Many junior/mid-level engineers have simply never seen commit messages and source control done well. Additionally, because many folks starting out in the field don't know how to truly use git beyond memorizing a few basic commands [1], they also never harvest any of the benefits of writing great commit messages. I've got a stash of links that I find myself often sending to engineers who are on the way up, and the tpope article on git commit messages [2] is one I find myself sharing around constantly. [1]: https://xkcd.com/1597/ https://xkcd.com/1597/ [2]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...

sudo_chmod777 4y ago

Vote here: https://github.com/community/community/discussions/8940 https://github.com/community/community/discussions/8940