>But still all is not lost here. When you do decide to do the manual >merging when you needed those patches, you would need to: > > * Update your working tree to the parent of the commit that did the >reformat. > * Apply your patch to that tree and reformat the tree. > * Diff the reformat commit and your current working directory. That >would give the reformatted diff.
tl;dr: I need to figure out how I'm going to dig out of the rebasing hole I'm now in, and could use advice/help, and I think the above sequence doesn't work for queues of dependent patches. So in my 6 (current) repos on my main dev machine, I have ~150 mq patch queues with a total of ~3000-3500 patches (though perhaps only 2500 unique ones) - some ancient/abandoned, but most have (unfinished) work on some subject (not generally single bugs, but something like "datachannel", with some related patches and some independent patches, and usually with a tail of some temporary/abandoned/replaced patches). Perhaps not an optimal flow, but it has worked for me for many years. Some of these are under revision control (hg mq --init), and are synced with (shared) patch repos on hg.mozilla.org (for example webrtc.org update import patch queues, which typically got to 100-150 patches before squashing for landing). I also used that to share queues with my windows dev machine. Some queues I could drop, but probably the majority of queues and majority of patches within each queue I'll want to save, if I can. The "saving" could be done on an as-needed basis, they don't need to all be converted (and that helps with the issue of having to decide if they're still relevant). But I need a process that won't take crazy amounts of manual labor to save my patches. I'd guess I have about 1000 patches I may need to save, eventually, and several hundred in the short term. An example is a queue of work to redo Dispatch() to require an already_AddRefed<>; that has about 30 directory specific patches, hitting ~250 files (plus some cruft patches after those). Another is my profiler work queue, which has 42 patches, mostly for single issues (or 2 or 3 related patches for an issue), and perhaps 1/2 of them are still relevant. Dealing with normal bitrot when going back to one of these I'm used to, but the reformatting will make pretty much every patch be 100% conflicts I assume. So what are reasonable options here? Are any of the options an improvement on "deal with every patch totally manually with 100% conflicts"? (Which, over time as I go back to various queues, will use a lot of my time doing manual rebasing.) Note that the line above "Apply your patch to that tree" implies doing a manual un-bitrot if needed (like updating today), which is ok (as I said, it's the same as before the reformat; most will not need major surgery unless they're ancient). >From the discussion here, it sounds like some manual fixups might be needed after the tool runs as well. But doing this sequence for every patch sounds time-consuming. And a much bigger issue: I think that breaks down for a queue of patches that depend on each other - if I reformat the first patch, I can't go back to before the big reformat and just apply the second patch, as it may depend on the first. I'd have to (I guess) squash all the patches, which in most cases would be horribly worse than doing it 100% manually. So what are usuable options for a (long) queue of patches, which may be dependent? (Some aren't and so perhaps I could do the sequence above for each one, like the Dispatch queue with per-directory patches, but that's not the common case.) Can we come up with a way to partially script this, if there's a workable sequence? Or do I just have to do a ton of manual rebasing? Thanks for any help/ideas. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
