(squashing some 'wip' commits before publishing the contribution is still useful of course, but 'address review comment X'-style commits, that I used to squash on merge, now seem worth keeping)

@tumdum I guess 'it depends' :D - for 'clearly this should have been different in the first place' amending makes sense, but for 'this alternate way of doing things is superior' or 'this additional thing is needed as well' separate commits can be nice.

If the contribution already consists of multiple commits and the change 'belongs' to one of the 'earlier' commits, going back and amending that commit might not be worth it. Might make sense to squash the whole thing though :D

@loveisgrief there is no debate that the intermediate commits can be helpful.

They have disadvantages as well: for example, it is more likely the code is in a 'broken state' on the intermediate commits, and you could land on those during a 'git bisect' for a completely unrelated problem, interfering. Also 'Fixed X' might be a distraction when X was actually introduced on that same branch.

Having '--first-parent' eliminates a disadvantage, making it more likely to be worth it.

@luka @madskjeldgaard I don't know either, but I suspect at the start of the project the author still hoped 'this time we will keep it simple' (the 'good' kind of 'stupid', as in KISS ;) )

@ck @codeberg @jgoerzen yes, this would be great.

Spam and impersonation would be problems to consider - but since commits can already be signed there's lots of opportunity to distinguish commits by 'known' entities from less verifiable sources.

@humanetech @fdroidorg huge selection-bias though: I suspect the fediverse population already has a high percentage of users that would describe themselves as tech-savvy...

@jgoerzen @eludom I'm definitely not trying to say GitHub is so great, I share your desire to bring more decentralization back to the forefront - but I'd like to understand better what people like so much about email for collaboration.

My personal feeling so far is that we indeed need better tools for 'contribution tracking' (that should include good email interfaces as well), but 'just' going back to mailinglists would throw out a lot of baby with the bathwater.

4/4

@jgoerzen @eludom I agree the GitHub review web interface leaves a lot to be desired, but on the other hand: is context-switching between the code and a consolidated webpage so much worse than context-switching between the code and a large email thread/tree? I didn't find other options (gerrit etc) very pleasant to use here either, but still better than wading through a mailing list archive...

3/4

@jgoerzen @eludom sending to a private address you're in the dark: did they get the email at all? Was it marked spam?

With a mailinglist, when you don't get a quick reply (which you can't always expect), having you contribution hidden in the email archive for months ago makes you wonder - did they forget about it? Should I remind someone?

Having it in the 'open prs report' is nice, and easier to discover esp. for others that don't follow the list closely.

2/3?

@jgoerzen @eludom this may be a bit of a tangent, but I'd like to understand better why people like "patches via email" so much.

I agree it's nice to submit your contribution from the commandline.

However, once you've sent it, I usualy quite miss the reporting of a forge: giving the contribution a URL, tracking the state (waiting for review, reviewed with comments, merged, closed).

1/3?