Recent searches
Search options
On my quasi-blog: "Git without a forge"
https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
Most of my projects are hosted in bare git repositories on the web, and not on a forge site. I talk a bit about this: ways to send patches to a project like that (and which I personally prefer), and reasons why I haven't (yet?) changed my arrangements.
@simontatham This was interesting to read and a good reminder that every project is different.
Personally, I'm firmly in the "git send-email" camp, but that's only because I've set up my tools so that working with it is easy. When you can just tell the mail client "apply this thread to this git branch", it becomes one of the most convenient options. But I can see how working with a series of emails sucks when you have to manually save each into a file and apply them in the right order.
@simontatham The real reason why I like an email per patch, though, is because I feel it works really well for review and design discussions - just reply and keep the quote for the relevant parts of the patch for context (in whatever order makes the most sense for making the point). This is how email was meant to be used, so it's no surprise that it works well.
I suppose for both your and my approach, using a mailing list would be helpful, and solve the problems with missing public visibility?
@caoimhin I'm not sure I see the connection to one email per patch. If I receive a submission of a whole patch series, I might very well want to quote parts of more than one of the commits in a review comment, to point out how they don't match each other. "In patch 2 you document the new function as follows: [quoted diff] But in patch 5 you call it with these arguments here: [diff] which don't match what the docs say you should do."
I think it's just as easy to paste fragments of patch from gitk into my email composer, and doesn't limit me to replying to only one patch at a time!
But I take your point about handling git-send-email messages being easier if you set up some automation for it. I don't know if my MUA would make that easy to set up (but then I probably ought to get round to replacing it anyway).
@simontatham True, you already get many of the advantages even with a single email containing all patches. So that part is mostly an argument for plain-text patches in email.
I like individual mails because that keeps things in more managable pieces for me. I can reply to one patch and leave the other one marked as unread for another time. It also keeps the discussion more focussed on the individual incremental steps - after all, the theory is that each logical change is one patch.
@simontatham You're right that sometimes cross-referencing to another patch does happen. In my experience, that's more the exception, though, and then I can still manually quote from an other email or the local git branch if necessary.
I'm not trying to persuade you or anything. As I said, it's good to be reminded that different projects have different preferences and they probably have reasons for them.
I can work with any of your options, but what's convenient is different for everyone.