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

[Tom Lord]

    > From: Denys Duchier <address@hidden>

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

Here are two ways to do it.  There are many.  This is just a sketch,
you'll have to work out the exact command lines yourself.

* The Problem

  There are two versions in play: proj--mainline--1.0 and
  proj--otherline--1.0.

  proj--otherline--1.0--base-0 is a tag of one of the mainline
  revisions with the other revisions being simple `commit' revisions.

  otherline may contain several previous merges from mainline, as
  well as some changes that are local to otherline.

  Recently, some files in mainline have undergone a sweeping change to
  formatting -- large chunks of code were reindendented.

  Some of the large reindented regions on mainlnie correspond to
  smaller, locally modified regions on otherline.

  Naively, mainline could again be merged into otherline with:

        % tla get proj--otherline--1.0  otherline
        % cd otherline
        % tla star-merge proj--mainline--1.0

  however, there is a drawback.   Where small local changes on
  otherline overlap large re-indendting changes on mainline, the
  result will be a conflict in which the large reindentation is
  rejected as a conflict.    It's awkward to imagine trying to edit
  that conflict to merge it with the small local changes.

* Two Solutions

  One way to view the problem is that we'd like to merge in the
  reindentations _without_ conflicts, but then apply the local changes
  on otherline on top of that.

  Why do it that way?  Because the local changes are much smaller and
  while there will still be conflicts this way, they will be much more
  managable.

  We can achieve that goal a number of ways, here are two:

                  * FIRST SOLUTION (the long form) *

  I'm including this first solution because I think it's illustrative
  -- but the second solution effectively does the same thing with 
  fewer steps.


        % tla get proj--otherline--1.0 otherline
        % cd otherline
        
        % baseline=`tla log-ls --full -r proj--mainline--1.0 | head -1`

        % echo baseline
        address@hidden/proj--mainline--1.0--patch-X

  Note that $baseline is now the latest revision of `mainline' with
  which otherline is up-to-date.

        % tla undo $baseline

  Now your tree is exactly equal to the $baseline revision, and the
  local changes on otherline have been set-aside in an ,,undo-N
  directory.

        % tla {update,replay,star-merge} tla--mainline--1.0

  Because this is a trivially conflictless merge, it really doesn't
  matter which merge command you use to do it.   After this step, your
  tree is now equal to the latest mainline revision.

        % tla redo

  Put back the local changes.   Presumably there are conflicts -- but
  they are smaller conflicts this time.

        % tla commit


   Hopefully that solution illustrates the idea.   Now here's a
   shortcut that has the same effect, only this time we'll have the
   option of getting `diff3' style conflict markers:

                 * SECOND SOLUTION (the short form) *

        % tla get proj--mainline--1.0  otherline

   Note that we "got" from mainline, but we called the working
   directory `otherline'.


        % tla star-merge -t proj--otherline--1.0

   That will merge in the local changes on otherline, this time
   storing the (hopefully smaller) conflicts as diff3-style conflict
   markers.

        % tla set-tree-version proj--otherline--1.0

   The resulting tree, the reason we called this directory otherline,
   is because that's where we want to commit this revision.

        % tla commit




    > I really wish such scenarii would make it
    > into the tutorial (or some other piece of documentation).  Perhapsn
    > this example (of conflicts created simply by reindenting) could be
    > examined in an additional chapter.

I am trying to find the time to start formatting this and similar
messages to make "Recipe -- blah blah" or "Case study -- blah blah" 
or "Concept -- blah blah" chapters, hopefully suitable for browsing in
random order once you have the basics down.   Good coffee-break
reading, or somesuch.

-t


p.s.: historic note

  The star-merge command used to have a more complicated interface and
  could actually do this kind of merge in a single step.   In effect,
  it gave you way to say whether the merged-in or already-present
  changes should take precedence in a merge.

  I omitted that from the new star-merge for two reasons:  First, 
  by omitting it, star-merge becomes a command that always applies 
  at most one patch.   Second, I don't think anybody other than me 
  ever used that feature;  I used it only rarely; and the solutions
  illustrated above are just as good.