Back

@simontatham All this except that "URL of a git repository + branch name" is my last choice, not first, largely for the same reason: it could disappear tomorrow, or get force-pushed/replaced between when I start reviewing it and when I eventually want to merge it. This actually happened several times with things folks were trying to get in musl, & it delayed them months or worse. Personally I always want changes submitted in a form with immutable record.

@dalias hmm. I think there are really two separate questions there: (a) the risk of the linked-to repo vanishing _while_ you're still reviewing and considering the contribution, and (b) the risk of it vanishing long afterward so that the long-term record goes away.

I've never considered (b) particularly important, although I'm open to being persuaded otherwise. To my way of thinking, once I've accepted a patch, the _final_ version of the patch is important to preserve, because it reflects the history of how my actual code evolved. But all the review drafts are just scaffolding – important during construction, but after you're done you can safely take them down and throw them away. I apply this equally to other people's patches sent to me, and my own patches I send to other people.

I've never yet had the problem of the repo containing the PR branch vanishing in mid-review. I would have guessed that it wouldn't be common because it's in the submitter's interest to keep it running! But I suppose I'm thinking on the timescale of weeks at most, however long it takes me to either accept or reject.

If PRs were public, then it seems more plausible you'd want to keep even the rejected ones forever. A patch I didn't think was worthy of getting into _my_ version of the code might still be useful to someone else to apply downstream of me.