diff options
author | Dmitrii Filippov <dmfilippov@google.com> | 2022-06-27 20:03:53 +0200 |
---|---|---|
committer | Matthias Sohn <matthias.sohn@sap.com> | 2022-11-29 10:49:27 +0100 |
commit | cb9f058f9b260dfa0878f7b8bf42936a7e330d35 (patch) | |
tree | 44aa7dbdf036f693dc29b469a373a3a78698f276 /org.eclipse.jgit.gpg.bc | |
parent | ce0c739f214f225b144e9fe425ad2d1f93275978 (diff) | |
download | jgit-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