Merging from Debian with patches applied

[James Westby]

On Tue, 16 Feb 2010 16:19:20 -0600, John Arbash Meinel <john at arbash-meinel.com> wrote:
> To make sure I understand. If you use quilt, it moves the location on
> the patch stack (by reverse applying the patches). Leaving you with a
> working dir that doesn't have the 'newer' patches applied. Then if you
> change stuff and "build", it recomputes the current patch.

Yes, I'm not sure if that's automatic, or whether you are expected to
"refresh" and then "pop" back to the top of the stack.

> I believe this means that you get a single snapshot with all patches,
> and a list of patches that are managed by quilt, right? (What I mean is
> that we don't import the series of patches, just the tip.)

Yes, you get a single commit where the tree is the code with all the
patches applied, and also contains a directory containing those patches.

> Wouldn't it also potentially run into problems with conflicts in the
> patch files themselves?

Indeed, and they are a huge pain to resolve.

> When you say "first patch" you mean the first patch against the
> orig.tar.gz, right? And IIRC the issue is that Ubuntu's orig.tar.gz may
> be a different version that debians.

Yes, but there can be other reasons that cause the patch to require
fuzz.

> Well, trying to integrate a DVCS with a patch workflow is a bit tricky
> regardless. Because you don't know where in history a given patch would
> apply. Consider if 2 patches overlapped in a section. (eg debian
> provides a feature, and Ubuntu provides a bugfix for that feature.)

Yes.

> If we handled the patches as actual commits, then in theory we could
> tell more accurately what part of the updates apply to what patch.
> (Since they would be directly associated.)

Yes.

> Now I guess in both debian and ubuntu all changes vs orig.tar.gz have to
> be represented by a patch. So in theory the 'merge' operation could
> start at the beginning, and merge the 'orig.tar.gz' changes. Then it can
> check to see if the first patch is identical on both sides, and if so,
> skip forward (applying the patch). If they aren't identical, it could
> ask the user do you want to:

> a) apply just patch A and leave patch B in the queue to be applied later
> b) apply just patch B and leave patch A in the queue to be applied later
> c) apply patch A and remove patch B (patch A supersedes B)
> d) apply patch B and remove patch A (patch B supersedes A)
> e) apply both to create a new patch C

> for (e) you may also have conflicts you want to resolve. A different UI
> would be:

> a) apply patch A to WT (and step the queue)
> b) apply patch B to WT (and step the queue)
> c) delete patch A from the queue
> d) delete patch B from the queue
> e) edit WT

> The idea is that you decide which patch gets applied next as you
> regenerate the patch series. This could actually interact fairly well
> with bzr commits / a loom, but for starters it could just be an
> interactive patch resolution.

That could work. However, not every change *has* to be represented as a
quilt patch, but the v3 format enforces that (I'm pretty sure, I haven't
tried to break it).

> I would probably have it start with a line like:

> patch A applies (exactly/with fuzz), patch B applies (exactly/with fuzz)
> patch A and patch B are identical

> Then you would do
> a d

> (apply one and delete the other from the queue)

> If it applied with fuzz, I assume you would regenerate the patch at that
> point.

> If the patches aren't identical, then you probably also want a few
> possible displays:

> 1) show patch A as unidiff
> 2) show patch B as unidiff
> 3) show differences between A & B

> All in all, this seems like a good place for a nice gui, since there is
> enough stuff going on that you'd really like to have a fair amount of
> assistance sorting it all out.

I think that would be nice to have.

> Does quilt support 'merging' 2 patch queues?

Not to my knowledge.

Thanks,

James