gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] "should conflict" situation but no conflicts occur


From: Tom Lord
Subject: Re: [Gnu-arch-users] "should conflict" situation but no conflicts occur
Date: Sun, 28 Sep 2003 14:47:46 -0700 (PDT)



    > From: Alexander Deruwe <address@hidden>

    > I've run into a merge situation where I _think_ a conflict should have
    > occured, but it didn't:

    > tla--aderuwe--1.1 is a branch of Tom's tla--devo--1.1, and
    > tla--whitespace--1.1 is a branch from --aderuwe--.  In --whitespace--,
    > I've fixed up some more whitespace issues (converting tabs to spaces and
    > removing end-of-line spaces).

    > Now, after --whitespace-- branched from --aderuwe--, in Tom's
    > tla--devo--1.1 the file libarch/cmd-update.c was updated (the vsnspec
    > variable changed name to rvsnspec; I haven't investigated the 'why?' of
    > this).  What this means is that my whitespace cleanups have cleaned up the
    > "vsnspec version", and I can confirm I touched lines with that variable in
    > it.  I've brought --aderuwe-- up to date with Tom's latest, and then
    > wanted to star-merge with --whitespace--.

    > Weird thing is that I did _not_ get any conflicts on cmd-update.c,
    > instead I got a cmd-update.c that used vsnspec in the lines I touched, and
    > rvsnspec in the lines touched by Tom's changes.

    > Isn't this a situation in which conflicts would have to occur?  Is this a
    > bug or just a misunderstanding on my behalf?

    > If I need to provide more accurate information, please just let me know.

No, I think I got it.  This was a fun exercise and, while I hate to
say it, I now really wish I had a really nice GUI or Emacs mode ---
too many trees and command outputs floating around here! :-)


You have two versions:


        tla-aderuwe--1.1                        tla--whitespace--1.1
          (branch of my tla--devo--1.1)           (branch of tla--aderuwe--1.1)

and of interest is:


                patch-19        -----tag------> base-0
          (up-to-date w/
           my tla--devo--1.1--patch-134)        ... 
                                                (many patches fixing
                                                 whitespace)
                                                ...

                                                patch-82
                patch-20        ~~~~merge~~~~~> patch-83
           (your patch-20
            merges up to my
            tla--devo--1.1--patch-153)



I made six trees:

        tla--devo--1.1--patch-134       (from me)
        tla--devo--1.1--patch-153       (from me)
        tla--aderuwe--1.1--patch-19     (from you)
        tla--aderuwe--1.1--patch-20     (from you)
        tla--whitespace--1.1--patch-82  (from you)
        tla--whitespace--1.1--patch-83  (from you)

and compared these using `diff -r -w'.   `-w' means "ignore
whitespace.

Ignoring whitespace, these are all equal:

        tla--devo--1.1--patch-134
        tla--aderuwe--1.1--patch-19
        tla--whitespace--1.1--patch-82

And, ignoring whitespace, these are equal:

        tla--devo--1.1--patch-153
        tla--aderuwe--1.1--patch-20

but these are not equal, even ignoring whitespace:

        tla--devo--1.1--patch-153
        tla--whitespace--1.1--patch-83

yet they should be.   In effect, whitespace patch-83 has some
reversions.

How did those reversions happen?   I tried retracing your steps with:


        % cd tla--whitespace--1.1--patch-82
        % tla star-merge tla--aderuwe--1.1--patch-20

As expected, when merging into a whitespace-changing branch, there's
no shortage of conflicts.

I looked at the conflicts and, sure enough, they appear to overlap
with the reversions in tla--aderuwe--1.1--patch-83.

So, it looks like a "user error" (really a UI problem) in resolving
conflicts before making patch-83.

Having introduced reversions in whitespace patch-83, they'll tend to
persist in later merges to or from aderuwe.

I said "really a UI problem".   I did the star-merge twice:   Once the
usual way, and again with the `-t' option to use diff3 style conflict
merges.

The first way, with all the conflicts in .rej files, is a big mess.
It's hardly surprising that some of the conflicts got resolved the
wrong way, creating reversions.

The new way, which wasn't yet available when you did that merge, using
-t and getting <<<<-style conflict markers, would have made it much,
much easier to do these merges  (essentially, if merging into
whitespace, delete the TREE version of the code and fix the whitespace
on the MERGED-IN version;   merging from whitespace, delete the
MERGED-IN version and fix whitespace on the TREE version.)

As a consequence of this, when I merge back from aderuwe to pick up
your whitespace changes and bug-fix, some reversions are introduced.

Fortunately, these are very easy to find with `diff -r -w' and there
are so few of them that I'm going to do the merge and just clean those
up.  

-t






reply via email to

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