summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.gpg.bc
diff options
context:
space:
mode:
authorDmitrii Filippov <dmfilippov@google.com>2022-06-27 20:03:53 +0200
committerMatthias Sohn <matthias.sohn@sap.com>2022-11-29 10:49:27 +0100
commitcb9f058f9b260dfa0878f7b8bf42936a7e330d35 (patch)
tree44aa7dbdf036f693dc29b469a373a3a78698f276 /org.eclipse.jgit.gpg.bc
parentce0c739f214f225b144e9fe425ad2d1f93275978 (diff)
downloadjgit-cb9f058f9b260dfa0878f7b8bf42936a7e330d35.tar.gz
jgit-cb9f058f9b260dfa0878f7b8bf42936a7e330d35.zip
Fix crashes on rare combination of file names
The NameConflictTreeWalk class is used in merge for iterating over entries in commits. The class uses a separate iterator for each commit's tree. In rare cases it can incorrectly report the same entry twice. As a result, duplicated entries are added to the merge result and later jgit throws an exception when it tries to process merge result. The problem appears only when there is a directory-file conflict for the last item in trees. Example from the bug: Commit 1: * subtree - file * subtree-0 - file Commit 2: * subtree - directory * subtree-0 - file Here the names are ordered like this: "subtree" file <"subtree-0" file < "subtree" directory. The NameConflictTreeWalk handles similar cases correctly if there are other files after subtree... in commits - this is processed in the AbstractTreeIterator.min function. Existing code has a special optimization for the case, when all trees are pointed to the same entry name - it skips additional checks. However, this optimization incorrectly skips checks if one of trees reached the end. The fix processes a situation when some trees reached the end, while others are still point to an entry. bug: 535919 Change-Id: I62fde3dd89779fac282479c093400448b4ac5c86
Diffstat (limited to 'org.eclipse.jgit.gpg.bc')
0 files changed, 0 insertions, 0 deletions