>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
>  * 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

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

Reply via email to