5 ms·

I also work this way and advocate against squash merging or putting all the context into the PR. A big reason for me is that I've built up a lot of context in

by js2 4y ago

I also work this way and advocate against squash merging or putting all the context into the PR. A big reason for me is that I've built up a lot of context in my head when writing code. When I make the commit, that context is fresh in my mind and flows easily into the commit message. But say instead I make a half-dozen commits with just single sentence descriptions. At the end of my work day I push the commits to a new branch and open a PR, and start writing the PR description. What was I thinking 5 hours ago when I wrote that first commit? I've forgotten. I've lost context. So I always try to commit and document as I go. At that point I don't spend a lot of time getting the commit messages perfect, but I make sure they at least have all my thoughts. Before I push up the commits, I'll use "git rebase -i" and "reword" to edit the messages (typos, reformatting the text, maybe adding additional thoughts as I look at the diff). Then I open the PR and at that point, maybe I'll add additional context but usually my PRs are just an abstract and I ask reviewers to look at the commits themselves. It drives me crazy how hostile GitHub is to reviewing individual commits. Many teams end up with squash-merges though because frankly: (a) developers don't know how to use git beyond committing and pushing so; (b) PR feedback is addressed by adding more commits and pushing them up, as opposed to amending the original commits; combined with; (c) GitHub only grudgingly accommodating an amend+force push workflow. Frankly Gerrit is a better-designed review tool, but it's not widely used.

simonw 4y ago
This is why my workflow is so issue heavy: I use issue comments to constantly capture my context as I'm working, rather than using small commits. I sometimes even run "git diff" and copy the result into an issue comment to record a potential implementation route that I'm not fully convinced of just yet.
- davnn 4y ago
  If most of the workflow and documentation is not based on git, but instead on issues and PRs, is there an easy way to swap the underlying platform, i.e. GitHub to Gitlab?
  - simonw 4y ago
    Not easy but possible: you export a copy of the issue thread content (via the issues API, which I have a bunch of experience with). Then you host those copies as flat HTML somewhere, such that anyone who needs to find issue 56 can hit some-url/56.html Then you could either rewrite the commit history to add links to this new location to each commit, or I'm investigating using the "git notes" mechanism to add those updated issue links to existing commits without needing to rewrite commit messages (and hence rewrite the hashes).
u801e 4y ago
> So I always try to commit and document as I go. At that point I don't spend a lot of time getting the commit messages perfect, but I make sure they at least have all my thoughts. Before I push up the commits, I'll use "git rebase -i" and "reword" to edit the messages (typos, reformatting the text, maybe adding additional thoughts as I look at the diff). I actually don't bother with committing anything to version control until I'm done with the feature or fix. I then will create a diff against the base branch and stage each individual part and create a commit from it. I then push up those commits to the remote. > It drives me crazy how hostile GitHub is to reviewing individual commits. I actually have an ingrained habit of middle-clicking on the commit sha1 and add my comments on the commit itself. It doesn't really show up with any context in the main PR view though. Lately, I've started running git log -p --reverse origin/master.., piping the output into vim, prefixing every line with '>' and typing my comments inline like I would with an email message (trimming the parts that I'm not responding to), and then pasting the entire thing in a single comment on Github. > Frankly Gerrit is a better-designed review tool, but it's not widely used. I actually wish more pepole would use the email patch review process. At least there, reviewing individual commits is the default and the relation among multiple commits is preserved. I'm not sure how that's accomplished in Gerrit.
- Quekid5 4y ago
  > I actually wish more pepole would use the email patch review process. At least there, reviewing individual commits is the default and the relation among multiple commits is preserved. I'm not sure how that's accomplished in Gerrit. Gerrit adds a changeset-id (changeset = patch) to each commit message via local hooks -- this allows for tracking patches even when rewriting. (Ofc, if you remove/rewrite the changeset-id the connection gets broken, but it's pretty rare that that happens.) Other than that it basically functions exactly like a more user-friendly patches-as-email.
  - u801e 4y ago
    So, if you implement a feature that involves multiple commits, when you push the branch up, will all the commits in the branch have the same changeset-id? If not, how is the relation between commits on a branch maintained during review and in the history after the branch is merged?

by js2 4y ago

simonw 4y ago

This is why my workflow is so issue heavy: I use issue comments to constantly capture my context as I'm working, rather than using small commits. I sometimes even run "git diff" and copy the result into an issue comment to record a potential implementation route that I'm not fully convinced of just yet.

davnn 4y ago
If most of the workflow and documentation is not based on git, but instead on issues and PRs, is there an easy way to swap the underlying platform, i.e. GitHub to Gitlab?
- simonw 4y ago
  Not easy but possible: you export a copy of the issue thread content (via the issues API, which I have a bunch of experience with). Then you host those copies as flat HTML somewhere, such that anyone who needs to find issue 56 can hit some-url/56.html Then you could either rewrite the commit history to add links to this new location to each commit, or I'm investigating using the "git notes" mechanism to add those updated issue links to existing commits without needing to rewrite commit messages (and hence rewrite the hashes).

u801e 4y ago

> So I always try to commit and document as I go. At that point I don't spend a lot of time getting the commit messages perfect, but I make sure they at least have all my thoughts. Before I push up the commits, I'll use "git rebase -i" and "reword" to edit the messages (typos, reformatting the text, maybe adding additional thoughts as I look at the diff). I actually don't bother with committing anything to version control until I'm done with the feature or fix. I then will create a diff against the base branch and stage each individual part and create a commit from it. I then push up those commits to the remote. > It drives me crazy how hostile GitHub is to reviewing individual commits. I actually have an ingrained habit of middle-clicking on the commit sha1 and add my comments on the commit itself. It doesn't really show up with any context in the main PR view though. Lately, I've started running git log -p --reverse origin/master.., piping the output into vim, prefixing every line with '>' and typing my comments inline like I would with an email message (trimming the parts that I'm not responding to), and then pasting the entire thing in a single comment on Github. > Frankly Gerrit is a better-designed review tool, but it's not widely used. I actually wish more pepole would use the email patch review process. At least there, reviewing individual commits is the default and the relation among multiple commits is preserved. I'm not sure how that's accomplished in Gerrit.

Quekid5 4y ago
> I actually wish more pepole would use the email patch review process. At least there, reviewing individual commits is the default and the relation among multiple commits is preserved. I'm not sure how that's accomplished in Gerrit. Gerrit adds a changeset-id (changeset = patch) to each commit message via local hooks -- this allows for tracking patches even when rewriting. (Ofc, if you remove/rewrite the changeset-id the connection gets broken, but it's pretty rare that that happens.) Other than that it basically functions exactly like a more user-friendly patches-as-email.
- u801e 4y ago
  So, if you implement a feature that involves multiple commits, when you push the branch up, will all the commits in the branch have the same changeset-id? If not, how is the relation between commits on a branch maintained during review and in the history after the branch is merged?