social.noyu.me

if you have only used github pull requests then i'm sorry but you have never seen how software development can be good

github pull requests are like if a student hands in an assignment, you hand it back to them covered in red marks, and they submit a “new version” that is the same piece of paper, but they stapled a second page to it listing all the changes they imagined making (repeat ad nauseam)

github pull requests are like if the title and abstract of a journal article were entirely exempt from peer review, and also some divine force automatically cut off the title mid-sentence, moving the rest into the abstract unaltered, and inserting a random number afterwards

github pull requests are like if papers in journals did not contain any actual citations or bibliography, only little superscript numbers that refer to citations you can look up on some cloud service that will definitely never go down taking history with it, don't worry about it

@hikari I wish fossil was more common

@hikari I would simply submit a fresh new assignment with no trace of the previous one

@hikari we're just gonna, uh.

why do we need reviews anyway.

@hikari how do i boost something multiple times. they are HORRIBLE.

@hikari i've had people send me diffs on dicksord and it's somehow a better experience than pull requests

@hikari

Actually, https://git-send-email.io was refreshingly close to better parts of #Gerrit without its horror parts.

#git

@hikari

https://nasamuffin.github.io/git/open-source/email/code-review/2019/05/22/how-i-learned-to-love-email-patches.html

@hikari Pushing updates as fixup commits allows some preservation of history, at least during the review phase (it will be lost when the commits are squashed at merge time though).

@hikari LGTM.

@hikari Heptapod improves this with the evolution changeset from #mercurial https://heptapod.net/pages/quick-start-guide.html

@hikari What's your take on Git*Lab*'s Merge Requests workflow?

@vldi from my limited experience of them they seem like a github PRs clone?

@hikari It does not have to be used that way, but here is my observed difference in how people use the two systems: GitHub's PRs are from clone repo to source repo, while GitLab's MRs are inside the same repo from a contributor's branch to a maintainer branch.

GitHub [simplified] steps are across repos:
1. Clone repo to contributor or update if cloned before
2. Push a patch to contributor's main.
3. Send a PR
4. Clean up once PR is decided

GitLab's [simplified] steps are in the same repo:
1. Check out (or use WebUI to make) a contributor's branch
2. Push a patch to the contributor's branch
3. Send an MR to the main (auto-sweep contributor's branch on merge)

An apparent downside in the latter workflow is that a maintainer needs to sweep abandoned contributor's branches.

However, I also saw that users perceive working on a branch as a process with less friction, at least in corporate environments. I did not observe much OSS development collaboration on GitLab.

@vldi @hikari my company uses GitHub PRs within the same repo in a similar way to your Gitlab example. I guess the only difference is when GitHub doesnt give contributors permission to make a branch, but really a fork is the same thing with a bit more annoyance

@hikari @vldi yeah, they’re pretty much the same. But even worse for dependent patches