16 ms·

I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feed

by js2 6y ago

I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. Alternately, if you just keep adding commits, then the final branch that gets merged (unless you squash) has all the in-progress work which pollutes the repo's history. Gerrit also has a finer grained permission model, but I don't care as much about that. Gerrit definitely expects the user to understand how git works conceptually a bit more than Github/lab.

nemetroid 6y ago
> With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.
- js2 6y ago
  Thanks. I haven’t used gitlab. I assumed it worked the same as GitHub. That’s good to know.
  - kevincox 6y ago
    Yup, GitLab works as expected here. It's always surprised me how quickly the old commit is garbage-collrcted when you force-push a branch on GitHub. It causes weird errors in CI runs and breaks viewing the old commits. Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)
0x0 6y ago
Gitlab DOES let you compare different versions of changesets in a merge request: https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...
depressedpanda 6y ago
But you don't force push with Gerrit? Just update your change set, then push to refs/for/<branch_name> again.
- 20after4 6y ago
  It's effectively similar to a force-push.
  - depressedpanda 6y ago
    I would say it's quite different, since you don't overwrite anything. Old patch sets are still available should you wish to roll back/reference either a particular commit, or a whole chain of commits.
- js2 6y ago
  It's been a while since I used it, but I guess the more important point is that it's a rebase-based workflow. My memory was you had to force push your working branch to refs/for. Thank you for the correction. I've actually setup and run instances of it as two companies, but as I say, it's been a while.
  - depressedpanda 6y ago
    Yes, I very much agree: the rebase-based workflow is what makes Gerrit superior to all other systems I've tried (of which I find Github and Bitbucket particularly loathsome). I felt I needed to correct you because with Gerrit you reserve the concept of force pushing for exceptional cases, which I think is the correct mental model. Force pushing should not be done frivolously.
- kortilla 6y ago
  It is a force push under the hood. You’re removing an old commit and creating a new one.
  - lacksconfidence 6y ago
u801e 6y ago
> With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. I'm not sure about Gitlab, but Github has recently added a feature where you can view the diff between the old branch head and new one. But, as far as I'm aware, there's no way to check out the previous branch head from the repo due to a lack of a remote branch pointing to it. At least git itself provides a range-diff command that allows you do see a diff between the commits between two versions of a given branch.

by js2 6y ago

nemetroid 6y ago

> With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.

js2 6y ago
Thanks. I haven’t used gitlab. I assumed it worked the same as GitHub. That’s good to know.
- kevincox 6y ago
  Yup, GitLab works as expected here. It's always surprised me how quickly the old commit is garbage-collrcted when you force-push a branch on GitHub. It causes weird errors in CI runs and breaks viewing the old commits. Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)

0x0 6y ago

Gitlab DOES let you compare different versions of changesets in a merge request: https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...

depressedpanda 6y ago

But you don't force push with Gerrit? Just update your change set, then push to refs/for/<branch_name> again.

20after4 6y ago
It's effectively similar to a force-push.
- depressedpanda 6y ago
  I would say it's quite different, since you don't overwrite anything. Old patch sets are still available should you wish to roll back/reference either a particular commit, or a whole chain of commits.
js2 6y ago
It's been a while since I used it, but I guess the more important point is that it's a rebase-based workflow. My memory was you had to force push your working branch to refs/for. Thank you for the correction. I've actually setup and run instances of it as two companies, but as I say, it's been a while.
- depressedpanda 6y ago
  Yes, I very much agree: the rebase-based workflow is what makes Gerrit superior to all other systems I've tried (of which I find Github and Bitbucket particularly loathsome). I felt I needed to correct you because with Gerrit you reserve the concept of force pushing for exceptional cases, which I think is the correct mental model. Force pushing should not be done frivolously.
kortilla 6y ago
It is a force push under the hood. You’re removing an old commit and creating a new one.
- lacksconfidence 6y ago

u801e 6y ago

> With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. I'm not sure about Gitlab, but Github has recently added a feature where you can view the diff between the old branch head and new one. But, as far as I'm aware, there's no way to check out the previous branch head from the repo due to a lack of a remote branch pointing to it. At least git itself provides a range-diff command that allows you do see a diff between the commits between two versions of a given branch.