Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jgit-dev] Wrong values returned in MergeResult#getConflicts()

Hi everyone,


This is my first message, then i would like to ask for comprehension and recommendation if I  incur in a bad practice here. 

I am PhD student and I am using JGit to analyse merge scenarios. More specifically, I am interested in the conflicting merge chunks. I find this method  org.eclipse.jgit.api.MergeResult#getConflict() that returns the mapping of beginning lines of the conflicting chunks of each file with conflicts. 
For instance, the following method provided in the documentation does not print what it is supposed to print, but wrong values in c[i][j]. 

Map<String, int[][]> allConflicts = mResult.getConflicts();

for (String path : allConflicts.keySet()) {

   int[][] c = allConflicts.get(path);

   for (int i = 0; i < c.length; ++i) {              

       for (int j = 0; j < (c[i].length) - 1; ++j) {

           if (c[i][j] >= 0)                                               

               System.out.println("    Chunk for "

                 + mResult.getMergedCommits()[j

                         + " starts on line #"

                 + c[i][j]);

}

   }

}


While debugging this method i found that the result does match with what is said in the documentation of the method, at least not in my test case scenario (file attached). I also noticed that executing merges with only 2 commits, c[i][0] was never updated and the values
that was supposed to be in c[i][0] and c[i][1] are actually added to c[i][1] and c[i][2], respectively in the the method org.eclipse.jgit.api.MergeResult#addConflict():

public void addConflict(String path, org.eclipse.jgit.merge.MergeResult<?> lowLevelResult) {

  if (!lowLevelResult.containsConflicts())

       return;

  if (conflicts == null)

  conflicts = new HashMap<String, int[][]>();

  int nrOfConflicts = 0;

  // just counting

  for (MergeChunk mergeChunk : lowLevelResult) {

if (mergeChunk.getConflictState()

                 .equals(ConflictState.FIRST_CONFLICTING_RANGE)) {

nrOfConflicts++;

}

  }

  int currentConflict = -1;

  int[][] ret=new int[nrOfConflicts][mergedCommits.length+1];

  for (MergeChunk mergeChunk : lowLevelResult) {

// to store the end of this chunk (end of the last conflicting range)

int endOfChunk = 0;

if (mergeChunk.getConflictState().equals(ConflictState.FIRST_CONFLICTING_RANGE)) {

if (currentConflict > -1) {

// there was a previous conflicting range for which the end

// is not set yet - set it!

ret[currentConflict][mergedCommits.length] = endOfChunk;

}

currentConflict++;

endOfChunk = mergeChunk.getEnd();

ret[currentConflict][mergeChunk.getSequenceIndex()] = mergeChunk.getBegin();

}

if (mergeChunk.getConflictState().equals(ConflictState.NEXT_CONFLICTING_RANGE)) {

if (mergeChunk.getEnd() > endOfChunk)

endOfChunk = mergeChunk.getEnd();

ret[currentConflict][mergeChunk.getSequenceIndex()] = mergeChunk.getBegin();

}

  }

  conflicts.put(path, ret);

}


Additionally, my scenario the line with a red background (ret[currentConflict][mergedCommits.length] = endOfChunk;) was never executed. As far as I understand, this line is supposed to populate the c[i][2] from the ret[][] array when executing a merge with 2 commits.

I searched in Bugzilla, but couldn't find anything regarding these methods.  Am I wrong, or this is actually a bug? 


Best regards,
--
Alcemir Rodrigues Santos
.:: RiSE Labs 
.:: www.alcemirsantos.com

"Who's John Galt?"

Attachment: ConflictBasedRepositoryTestCase.java
Description: Binary data


Back to the top