4 ms·

There's also another problem: The git workflow doesn't jell with the natural flow of code review. What should that flow look like? 1. You send out a change fo

There's also another problem: The git workflow doesn't jell with the natural flow of code review. What should that flow look like? 1. You send out a change for review. 2. You get review comments. 3. You fix the comments. 4. Repeat from #2 as many times as necessary. 5. You merge the change. In git, how do you address review comments? You can either amend, in which case, at least on Github, you lose history while in review; or you add another commit, which essentially forces you to squash when you merge, which results in large commits. How do you do stacked changes? How do you continue working on your feature while waiting for a change to be reviewed, and rebase the comments quickly? With jj, it's jj edit and jj next.

motorest 2y ago
> How do you do stacked changes? How do you continue working on your feature while waiting for a change to be reviewed, and rebase the comments quickly? What? Are you actually asking this question? I mean, what answer do you need other than a basic intro to PR tutorial from the likes of GitHub or GitLab? But to answer your question, you continue working on your feature exactly like you've been working so far. You do not need to amend or squash. You can instead do the right thing and address PR feedback by pushing individual commits. How the PR branch is merged is a separate concern, and you are free to squash or rebase or whatever you'd like, because none of this is a Git issue. Why do you think this is an issue with Git?
- morgannewman 2y ago
  [dead]
Izkata 2y ago
> or you add another commit, which essentially forces you to squash when you merge, which results in large commits. Please no. Just do a normal merge instead of destroying history. Having those as separate commits is extremely useful for those of us who actually have had to dig into the history to track down why something is the way it is.

motorest 2y ago

> How do you do stacked changes? How do you continue working on your feature while waiting for a change to be reviewed, and rebase the comments quickly? What? Are you actually asking this question? I mean, what answer do you need other than a basic intro to PR tutorial from the likes of GitHub or GitLab? But to answer your question, you continue working on your feature exactly like you've been working so far. You do not need to amend or squash. You can instead do the right thing and address PR feedback by pushing individual commits. How the PR branch is merged is a separate concern, and you are free to squash or rebase or whatever you'd like, because none of this is a Git issue. Why do you think this is an issue with Git?

morgannewman 2y ago
[dead]

Izkata 2y ago

> or you add another commit, which essentially forces you to squash when you merge, which results in large commits. Please no. Just do a normal merge instead of destroying history. Having those as separate commits is extremely useful for those of us who actually have had to dig into the history to track down why something is the way it is.