| commit | 3ff4c5d52dee6983538bb1d04f759e4a3d40a7f0 | |
| author | Shawn O. Pearce <spearce@spearce.org> | |
| Thu, 22 Jan 2009 23:28:01 +0000 (22 15:28 -0800) | ||
| committer | Robin Rosenberg <robin.rosenberg@dewire.com> | |
| Fri, 23 Jan 2009 22:27:18 +0000 (23 23:27 +0100) | ||
| tree | 2d6ca52f6b5d8a5471b32d653d8c8f798a21edb9 | treesnapshot (tar.gz zip) |
| parent | 925c8628a45d2e98470607c7f482a506438d8a62 | commitdiff |
Fix TreeWalk.idEqual when both trees are missing the path
The Javadoc of idEqual() says its simply a faster form of
getObjectId(nthA).equals(getObjectId(nthB)), but its code
didn't match that definition when both trees didn't exist
at the current path.
If a tree doesn't exist for the current path getObjectId() returns
ObjectId.zero(), indicating the "magic" 0{40} SHA-1 for the current
path. If both tree entries don't exist for the current path, we
should be doing a compare of ObjectId.zero() against ObjectId.zero(),
which must be true as the values are the same.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
The Javadoc of idEqual() says its simply a faster form of
getObjectId(nthA).equals(getObjectId(nthB)), but its code
didn't match that definition when both trees didn't exist
at the current path.
If a tree doesn't exist for the current path getObjectId() returns
ObjectId.zero(), indicating the "magic" 0{40} SHA-1 for the current
path. If both tree entries don't exist for the current path, we
should be doing a compare of ObjectId.zero() against ObjectId.zero(),
which must be true as the values are the same.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
| org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java | diffblobblamehistory |