@martijnbraam Thanks for this! I've been wondering about the benefits of this workflow (haven't tried it myself yet) and this is the first article on the topic I actually found helpful.

@Alexmitter I have thunderbird on most machines, aerc on a lot of them. That's the nice thing about imap, you can set up as much mail clients for different purposes as you need.

@martijnbraam interesting read. What I still don’t get is: how would you deal with conflicts in the patches send to you? Let’s say the patch was made on an older version of the source and there are conflicting changes. IMHO solving this would also require some rebasing of sources and resending of patches, wouldn’t it?

@appelgriebsch in the case of a merge conflict in the patch you'd either rebase that patch locally before you merge it, instead of rebasing it, force-pushing it to the authors git repo, then merging it.

Or you ask the author to rebase it and send a new patchset I guess.

@martijnbraam yeah I guess so too, but wouldn’t it be basically the same procedure as with the PR? I would also ask the author of a PR to rebase his branch and update the PR in case of conflicts

@appelgriebsch for small conflicts you're not pushing to someone elses git repo, you just apply the changed patch directly. That's the main difference. Most changes I've had just apply cleanly though, in case of gitlab it's always rebasing if there's some unrelated commit in between.

@martijnbraam thanks for clarifying. That’s definitely a plus point for the PATCH variant. I usually have to do rebasing of PRs on Bitbucket or GitHub as well as soon as there are newer (and unrelated) commits to the master / main branch...

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.