GeoGig Workshop

2.10. Managing conflicts

When we merged branches, we merged a single commit from one branch to another. There is no possibility of problems with such a scenario.

However, that is an oversimplified case. In the course of working with multiple branches, it is very easy to have a scenario where merging one branch onto another will create a conflict. A conflict happens when the repository exists in a contradictory state. An example of this is two commits specifying two different values for the same attribute. Another example is a commit modifying a feature with another commit deleting that feature.

When a conflict occurs, the merge is halted mid-way, and the conflict will have to be resolved before the merge can continue. Should the conflict be indicative of a larger problem, the merge itself can be aborted.

2.10.1. Ours or theirs

Recall that commits on branches are pulled in when a merge occurs. Thinking spatially, the source branch is over “there” while the target is over “here”.

Conflicts are termed in a similar way in GeoGig. The value of the conflict from the source branch is named “theirs” while the value currently on the target is named “ours”. These terms are important in that you, as manager, get to choose how to manage the conflict:

  • Choose “ours”
  • Choose “theirs”
  • Change to something different from either “ours” or “theirs”

2.10.2. Creating a conflict

Conflicts usually don’t need to be created; they will happen naturally. Nonetheless, we will create a true conflict and resolve it manually.

  1. Create a new branch called updates and switch to it.

    geogig branch -c updates
    
    Created branch refs/heads/updates

    Note

    Verify that the above command switched to the new branch by running geogig branch

  2. Export the contents of our branch to a new shapefile:

    geogig shp export bikepdx bikepdx.shp
    

    We will have a new shapefile directly in our repo directory.

  3. Start a new QGIS and load the bikepdx.shp. We don’t need to apply any styling.

  4. Open the attribute table for the layer (Layer ‣ Open Attribute Table) and find a row that corresponds to the feature with the ID number 6759.

    ../_images/conflict_tablebefore.png

    Attribute table with highlighted feature to be modifed

    ../_images/conflict_feature.png

    Feature to be modified

  5. Click the pencil on the top left of the dialog to Toggle Editing.

  6. Change the value of segmentnam for that feature to SW BOND AVE.

    ../_images/conflict_tablechange1.png

    Modifying an attribute value

  7. Click the pencil again to turn off editing. When prompted, click Save.

  8. Close the attribute table dialog.

  9. Import, add, and commit this change. See the Working with commits section for details on these commands. However, remember that we will be importing the new bikepdx.shp:

    geogig shp import --fid-attrib id bikepdx.shp
    geogig add bikepdx
    geogig commit -m "Set name of SW BOND AVE bike lane."
    
  10. Now switch back to the master branch:

    geogig checkout master
    
  11. Back in our original QGIS (with the styling), open the attribute table for the layer, and verify that the change you made is not present.

  12. Click the pencil to Toggle Editing again.

  13. Find feature 6759 again and change the value of segmentnam for that feature to BOND AVE.

    ../_images/conflict_tablechange2.png

    Modifying an attribute value to something else

  14. Turn off editing and click Save.

  15. Import, add, and commit this change to the GeoGig repository:

    geogig shp import --fid-attrib id ../data/bikepdx.shp
    geogig add bikepdx
    geogig commit -m "Set name of BOND AVE bike lane."
    
  16. With the two changes made on the two different branches, we are now ready to see what happens when we attempt a merge. Merge the updates branch onto the master branch.

    geogig merge updates
    
  17. You will see the following error:

    An unhandled error occurred: CONFLICT: Merge conflict in bikepdx/6767
    Automatic merge failed. Fix conflicts and then commit the result.

2.10.3. Resolving the conflict

The merge cannot continue until the conflict is resolved.

  1. Get more information about existing conflicts with the conflicts command:

    geogig conflicts
    
  2. The output of the above command shows much more than we care about. We can filter this output to just the differences by adding the --diff option:

    geogig conflicts --diff
    
    ---bikepdx/6759---
    Ours
    segmentnam:  -> BOND AVE
    
    Theirs
    segmentnam:  -> SW BOND AVE

    Here we see the problem: the attribute value is different for both “ours” (the master branch) and “theirs” (the updates branch.)

  3. A different way to view this is through the status command:

    geogig status
    
    # On branch master
    # Unmerged paths:
    #   (use "geogig add/rm <path/to/fid>..." as appropriate to mark resolution
    #
    #      unmerged  bikepdx/6759
    # 1 total.
    
  4. Because this situation is a simple one, we can just choose which commit we wish to use via the checkout command. We have seen this command earlier from switching between branches, but it can also be used to switch attributes from different branches, via the -p <feature> option coupled with either --ours or --theirs. Since we want to pull in the value from the updates branch, the command is as follows:

    geogig checkout -p bikepdx/6759 --theirs
    
    Objects in the working tree were updated to the specifed version.
  5. Running geogig status shows that there is a way forward out of the conflict:

    geogig status
    
    # On branch master
    # Unmerged paths:
    #   (use "geogig add/rm <path/to/fid>..." as appropriate to mark resolution
    #
    #      unmerged  bikepdx/6759
    # 1 total.
    # Changes not staged for commit:
    #   (use "geogig add <path/to/fid>..." to update what will be committed
    #   (use "geogig checkout -- <path/to/fid>..." to discard changes in working directory
    #
    #      modified  bikepdx
    #      modified  bikepdx/6759
    # 2 total.
    
  6. We now need to add the feature as if it were a normal commit:

    geogig add bikepdx
    
    Counting unstaged elements...2
    Staging changes...
    100%
    1 features and 1 trees staged for commit
    0 features and 0 trees not staged for commit
  7. And now we can commit the change. Since we’re committing manually, we’ll have to manually add the commit message in.

    geogig commit -m "Set name of SW BOND AVE bike lane."
    
    100%
    [4b6771d45949ce83530e0ff035c2f4713a8da6e3] Set name of SW BOND AVE bike lane.
    Committed, counting objects...0 features added, 1 changed, 0 deleted.
  8. The conflict has now been resolved. Delete the updates branch.

    geogig branch -d updates
    
    Deleted branch 'updates'.
  9. You may delete the bikepdx files in the repo directory now.



This Page

About Boundless

Boundless provides commercial open source software for internet mapping and geospatial application development. We are dedicated to the growth and support of open source software.

License

This work is licensed under a Creative Non Commercial-Commons Attribution-Share Alike 3.0 United States License. Feel free to use this material, but we ask that you please retain the Boundless branding, logos and style.

Creative Commons License