Re: [Gnu-arch-users] how to recover from large conflicts?

[Denys Duchier]

Tom Lord <address@hidden> writes:

>     > 4. temporarily back out the patch of mine that is probably causing
>     >    trouble, star-merge, then re-apply my patch slightly tweaked.  I
>     >    don't know how to do this either except by explicitly applying it
>     >    backwards and then committing - is that the only option here?
>
> That's not a bad option at all.  You can do that between commits, too
> -- you don't have to commit after reverting the earlier patch.

I don't? arch won't try to temporarily "undo" local changes?

> There's many dinky little variations on this -- e.g., you could use
> `undo' naming his latest rev as the baseline to revert your local
> changes, merge, then redo (again, hoping for a smaller conflict).

er... what???.  This is where I could really use an example.  This
sounds all so tentalizing, but, you know, most people are not you :-)
and as a consequence have a rather less thorough understanding of how
to apply arch in practice.  I really wish such scenarii would make it
into the tutorial (or some other piece of documentation).  Perhaps
this example (of conflicts created simply by reindenting) could be
examined in an additional chapter.

> One question that your question raises is whether or not we want to
> make it possible to pass the `--ignore-whitespace' flag down to patch.

No, this would not work.  Indentation is significant in Python code.
What would be good would be if diff could (1) ignore indentation for
the purpose of matching, (2) but retain the differences for the
purpose of producing patches.  I.e. basically I would like these two
lines to (in a way) "match":

        AAA
                AAA

but still produce a patch:

-       AAA
+               AAA

> Another question that this raises is whether or not we want some extra
> fanciness in `patch(1)' to deal with very large hunks.
>
> That is to say, let's suppose that his changes involve a very large
> hunk that conflicts with a tiny change in your sources.   It may be
> that by splitting his large hunk into three smaller ones, you'd get
> two that apply cleanly, and one small one that doesn't.   Might be
> worth playing around with.   (This would be at the level of "small
> research problem".)

exactly.  That's another (nicer :-) way to talk about "hacking" the
diffs as I suggested.  Certainly, it would be good to have a way to do
this, and it would help to know what exactly is the format of these
.rej files.  That wasn't clear to me.

So what are the operations that we might want to have?

- explode a diff into individual hunks
- split a hunk at a point
- remove a hunk
- replace a hunk
- implode a sequence of hunks into a diff
- take a piece of code and create a (pos or neg) hunk
etc...

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE