[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tom Lord
Subject: Re: [Gnu-arch-users] how to recover from large conflicts?
Date: Wed, 24 Sep 2003 16:16:02 -0700 (PDT)

    > From: Denys Duchier <address@hidden>

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

Another option, since your changes in your branch are small, is to
star-merge the other direction:  `get' his tree;  `star-merge' from
your branch;  `set-tree-version' to your branch;  commit.   You'll
still have a conflict to resolve this way, but from your description,
it sounds like it will be a much smaller conflict.

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).

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.
But such an option could very easily be "not the right thing" here:
you could merge from his tree but no pick-up the reindenting around
the conflicting hunk;  or you could merge to his tree and wind up with
your changes but improperly formatted (rather like merging code from
Miles :-).

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".)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]