Martin, On Oct 14, 2012, at 10:40 PM, Martin Geisler <[email protected]> wrote:
> Gary Oberbrunner <[email protected]> writes: > >> OK. Martin and everyone, thanks for your thoughts on this! I think we >> have three possible courses of action. >> >> 1a: Russel, in his repo, reapplies his changes (somehow) to the current >> tip, and we move forward from there. >> 1b: Russel, in his repo, backs out my backout, applies some fixes, and >> resubmits a pull request. >> >> Downside: repo history is ugly, and Russel's changes possibly end up in one >> big commit, and his job is harder. Upside: not sure. >> >> 2: I or Bill (as maintainer) use >> https://bitbucket.org/scons/scons/admin/strip to reset the bitbucket repo >> back to just before the bad merge. I think this would make the new tip: >> f461304: Merged pull request #44 (make README a ReStructuredText file) >> (Rob M would have to resubmit pull request #46.) >> >> Downside: anyone who's got local changes based on tip will be confused, and >> there's a risk of the stripped changesets coming back on push. But this is >> all very recent and probably everyone who cares is reading this, and only a >> few people have push privileges to bitbucket/scons/scons. Upside: nice >> clean repo history, and Russel can just resubmit his pull request with his >> fixes. >> >> 3: We take Martin's advice, and abandon the merge changeset. I'm not >> actually sure how to do this in a bitbucket context. Martin, assuming we >> just want to go back to f461304 (see >> https://bitbucket.org/scons/scons/changesets), and move forward from there, >> abandoning everything since then (all Russel's changes, which were on >> default in his repo as well as merging Rob Managan's change 3771fa3), what >> do we do? I'm not sure how Bitbucket will handle multiple heads -- will >> one be the visible "main" one? >> >> Downside: I don't know how to do this, and it's all done on our public >> bitbucket, so it's a bit dangerous. (Martin: your version dealt with >> named branches; we're all on default.) Upside: agrees with Martin's >> advice as well as a Stack Overflow question I saw. > > This option 3 should be the safest: you mark the head (8764000) as > closed locally and push to Bitbucket. You can then make a new commit > From somewhere good (f461304) and that will be it. I've done that here: > > https://bitbucket.org/mg/scons/changesets > > The closed head is hidden from 'hg heads' by default and if a branch has > nothing but closed heads, then the branch itself is hidden from 'hg > branches'. That's all there is to this --close-branch mechanism. Could you list the commands to do this. (none of use are super knowledgable on mercurial (yet:))? > >> Opinions? I think I like #2 best, as it seems simple enough and will >> get us back to a good state quickly. I'd go with #3 if people say it's >> better in some way and I get good instructions. > > Rewriting public history all depends on how many people you expect to > annoy... if you get 10 pull requests per week and those people would > need to recreate some work if you strip the Bitbucket repo, well then > you might want to avoid it. If you get 1 pull request per week and if > most contributors read this list, well then go ahead. Our pull request volume is usually ~1-3/week. If we do the strip, then we would need to ask all forks to do the same if they'd already merged? Thanks! -Bill Deegan Co-Manager SCons Project. _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
