I've noticed listed problems, they surely do exist. but stepping back a little - proposed solution sounds like: "lets make a brand new version control system for already existing version control system".
Reorient GitHub pull requests around changesets
141–150 of 210 posts
Re: Reorient GitHub pull requests around changesets
#142The changeset workflow is what Gerrit uses. Gerrit is great.
There's a free service (GerritHub) that lets you use Gerrit for your public GitHub project. The learning curve for it is pretty steep if you've never used Gerrit before, though, and it does have some reliability issues. But for a certain kind of project it can really transform the code review experience.
Re: Reorient GitHub pull requests around changesets
#143I am slowly convinced that comments on PRs are like comments on blog posts or youtube videos. Ephemeral, irrelevant and ineffective. If you really want to "reply", put up your own blog post or a "reacts" video. Same for code. unless it's simple typo fixes or improvements, deeper fixes come from writing code samples yourself. I recently commented on a juniors code, and put in about four lines of code showing how I wou…
I frequently use “suggestion” to provide a change I think would be better.
‘’’suggestion ‘’’
Re: Reorient GitHub pull requests around changesets
#144Jm2c, but by far the best place I've ever worked (my current client) we don't do code reviews at all unless the author wants feedback. PRs are good ways to defend your code base from bad code, and they were born in open source where you literally have no clue who the contributor is, but years of experience left me convinced that I don't want such a system where there's constant need to overview each other's work. I w…
[deleted]
Re: Reorient GitHub pull requests around changesets
#145It might be less correct from a taxonomy perspective but why not just a different branch for each change?
Re: Reorient GitHub pull requests around changesets
#146More and more I'm starting to appreciate the email based PR
It's simple, scalable, and has none of the mentioned problems. The main drawback is that contributors have to learn a proper mail user agent (Gmail is notoriously bad with patches).
I guess for sending parches using git tooling instead of an email client works best. At least according to https://git-send-email.io/
Re: Reorient GitHub pull requests around changesets
#147A lot of people mentioning Gerrit, but Gitlab seems to support this too. It also removes approvals for the new changeset in case any were already present (by default, you can now disable this). It seems to have supported changesets forever so I'm surprised GitHub doesn't.
I've also considered not allowing contributors to force push. Instead any changes would be pushed (possibly as fixup! or squash! commits) so all history of the merge request is easily accessible. To be rebased/squashed later, of course.
Re: Reorient GitHub pull requests around changesets
#148Earlier quoted context omitted.
> It'd be a useful thing to import without having to bring in the whole charade of using email and mailing lists (which most mail clients tend to be very unfavorable of in general nowadays) This is a misconception. git itself has commands (git-format-patch and git-send-email) that automate the creation of patches and sending changeset email threads to the mailing list. The only thing one needs to do is set the approp…
No, it is not a misconception. How do I apply a patch from gmail to a specific git repo on my computer? (I would genuinely like to know the answer, but it must not involve mutt, gnus, or dovecot!)
Save the email to your local machine (in gmail, click the 3 dots and choose download message). Then run
git am Re: Reorient GitHub pull requests around changesets
#149It's surprising to me that GitHub currently doesn't attach review comments to specific commits, but only to timestamps, and I agree that it would be great to improve that. But I don't understand how a contributor can feel pressure to address all of the reviewers' comments in a single commit: They can commit as many times as they want, and only push when they feel it's ready. And in the case where they may want to off…
> It's surprising to me that GitHub currently doesn't attach review comments to specific commits It is possible to comment on commits in github (you can do it by clicking on the sha1 of the commit and then making a comment on a line in the diff). But the comment won't show up in the main PR diff window. > But I don't understand how a contributor can feel pressure to address all of the reviewers' comments in a single…
>A changeset consists of one or more commits where each makes one logical change
I don't yet see how that is different from just... a sequence of commits, which you can do now. (If you want to claim that you could quickly make a bunch of messy local commits and afterwards reorganise them into a more logical group of commits in a changeset -- you can already do that, without any new concept of changesets, by using `git rebase -i`.)
Re: Reorient GitHub pull requests around changesets
#150isn't this what Gitlab have? Instead of v1, 2, 3 you're able to see them at the state of each git commit hash