6 ms·

I bet you're other thinking in this case. In general, the expectation on GitHub is that PR commit history doesn't matter, and owners should simply squash on acc

by hoten 3y ago

I bet you're other thinking in this case. In general, the expectation on GitHub is that PR commit history doesn't matter, and owners should simply squash on acceptance. I think most contributors don't event consider that all their commits are visible or would be of interest and only think about the final product. It's certainly simpler for the contributor to do the squashing, but when GitHub makes it so simple in practice it doesn't matter.

akx 3y ago
I disagree pretty hard with this – for instance I've recently needed to dig into the code for the Gradio library, and when PRs are like https://github.com/gradio-app/gradio/pull/3300 https://github.com/gradio-app/gradio/pull/3300 (and the merge commit's message is what it is) it's hard to understand why some decisions have been made when doing `git annotate` later on.
- hardware2win 3y ago
  I disagree, commits are mehh Pull requests, patch notes, documentation and comments should be source of truth Git is not project management tool, it just manages my letters history.
- dboreham 3y ago
  I don't think you're in disagreement. Parent is saying that it is customary nowadays to have crap commit history. You're saying that crap commit history is problematic from a s/w engineering perspective. Both are true.
- oftenwrong 3y ago
  Curious use of `annotate` instead of `blame`. Former user of cvs, bk, hg, bzr, fossil, etc?
  - seabass-labrax 3y ago
    My favourite tool for this is the blame command in Magit (the Git client for Emacs). You can cycle between styles; one shows the commit message as a kind of header in-line with the code for instance. Another just shows a faint rule between lines that were changed in different commits. Then, one can press return to show the specific commit that the line was changed in. Well worth a try if you haven't already!
  - akx 3y ago
    No-blame culture :grin: (Also, JetBrains tools use "Annotate".)
- charrondev 3y ago
  I’ve worked on a project with devs that write crap commit messages. It’s far easier to just commit to squash merging and requiring good PR titles and descriptions (which become the commit message following the squash). Especially when you have multiple people working on a shared branch rebasing can be quite painful. The most common example of this is when sharing a branch with a QA.
Arch-TK 3y ago
People wonder why Linus Torvalds dislikes github. Imagine writing a highly performant and featureful relational database and successfully using it with large projects for a while without the database itself becoming particularly popular and then having a company come along and popilarise your database by telling lots of people about how good it is as a flat key value store. Then people are really confused and annoyed as to why their key value store has this complicated and confusing relational database attached to it so they write lots of guides skimming over the details to help people get better at using the database to just store keys and values in one table. If I was Linus I would be pretty pissed too.
- zarzavat 3y ago
  As far as I understand, Linus doesn’t write code. He reviews code other people have written, and even other deputies review the code before it gets to him. Additionally, many people are paid to work on his project by other companies. Linus doesn’t pay them, yet he’s their boss. All of this is to say that Linus is very insulated from externalities. He can insist on his platonic ideal of a commit and SCM, if it makes his life easier. He’s like the editor at a publishing house, rejecting countless manuscripts yet never writing a word himself. And that’s fine. However, most people do not use an SCM like Linus does. If you’re maintaining an open source project on GitHub you’re probably working for free, as are the people submitting PRs. The more difficult you make their lives, the fewer people will be willing to submit PRs and the more work you’ll have to do eventually.
  - Arch-TK 3y ago
    It's really irrelevant what Linus does now or what your personal opinion of version control is. The point is, git does certain things well, and a large portion of its users don't seem to need or want it. Not it might be because those users don't understand what they're missing out or whatever, but git was written by Linus from endless experience dealing with both contributing and maintaining code. It's simply wrong to suggest that Linux has no idea what he's talking about from a contributor perspective. Moreover, there's still plenty of people, who actually understand git, who are happy with the workflow that it was designed around. Yes it's a complex tool, but it's not as nonsensical or confusing as the people insisting on not using it to its full extent seem to always claim it is.
deleted 3y ago
[deleted]
GrinningFool 3y ago
> In general, the expectation on GitHub is that PR commit history doesn't matter, and owners should simply squash on acceptance. This varies greatly from project to project, and is by no means a general expectation.

by hoten 3y ago

akx 3y ago

I disagree pretty hard with this – for instance I've recently needed to dig into the code for the Gradio library, and when PRs are like https://github.com/gradio-app/gradio/pull/3300 https://github.com/gradio-app/gradio/pull/3300 (and the merge commit's message is what it is) it's hard to understand why some decisions have been made when doing `git annotate` later on.

hardware2win 3y ago
I disagree, commits are mehh Pull requests, patch notes, documentation and comments should be source of truth Git is not project management tool, it just manages my letters history.
dboreham 3y ago
I don't think you're in disagreement. Parent is saying that it is customary nowadays to have crap commit history. You're saying that crap commit history is problematic from a s/w engineering perspective. Both are true.
oftenwrong 3y ago
Curious use of `annotate` instead of `blame`. Former user of cvs, bk, hg, bzr, fossil, etc?
- seabass-labrax 3y ago
  My favourite tool for this is the blame command in Magit (the Git client for Emacs). You can cycle between styles; one shows the commit message as a kind of header in-line with the code for instance. Another just shows a faint rule between lines that were changed in different commits. Then, one can press return to show the specific commit that the line was changed in. Well worth a try if you haven't already!
- akx 3y ago
  No-blame culture :grin: (Also, JetBrains tools use "Annotate".)
charrondev 3y ago
I’ve worked on a project with devs that write crap commit messages. It’s far easier to just commit to squash merging and requiring good PR titles and descriptions (which become the commit message following the squash). Especially when you have multiple people working on a shared branch rebasing can be quite painful. The most common example of this is when sharing a branch with a QA.

Arch-TK 3y ago

People wonder why Linus Torvalds dislikes github. Imagine writing a highly performant and featureful relational database and successfully using it with large projects for a while without the database itself becoming particularly popular and then having a company come along and popilarise your database by telling lots of people about how good it is as a flat key value store. Then people are really confused and annoyed as to why their key value store has this complicated and confusing relational database attached to it so they write lots of guides skimming over the details to help people get better at using the database to just store keys and values in one table. If I was Linus I would be pretty pissed too.

zarzavat 3y ago
As far as I understand, Linus doesn’t write code. He reviews code other people have written, and even other deputies review the code before it gets to him. Additionally, many people are paid to work on his project by other companies. Linus doesn’t pay them, yet he’s their boss. All of this is to say that Linus is very insulated from externalities. He can insist on his platonic ideal of a commit and SCM, if it makes his life easier. He’s like the editor at a publishing house, rejecting countless manuscripts yet never writing a word himself. And that’s fine. However, most people do not use an SCM like Linus does. If you’re maintaining an open source project on GitHub you’re probably working for free, as are the people submitting PRs. The more difficult you make their lives, the fewer people will be willing to submit PRs and the more work you’ll have to do eventually.
- Arch-TK 3y ago
  It's really irrelevant what Linus does now or what your personal opinion of version control is. The point is, git does certain things well, and a large portion of its users don't seem to need or want it. Not it might be because those users don't understand what they're missing out or whatever, but git was written by Linus from endless experience dealing with both contributing and maintaining code. It's simply wrong to suggest that Linux has no idea what he's talking about from a contributor perspective. Moreover, there's still plenty of people, who actually understand git, who are happy with the workflow that it was designed around. Yes it's a complex tool, but it's not as nonsensical or confusing as the people insisting on not using it to its full extent seem to always claim it is.

deleted 3y ago

[deleted]

GrinningFool 3y ago

> In general, the expectation on GitHub is that PR commit history doesn't matter, and owners should simply squash on acceptance. This varies greatly from project to project, and is by no means a general expectation.