This function (and the helpers ancestry and find_and_peel) are
eagerly peeling to commits, leading to updates of tags that target the
same commit to be missed.
For example, there could be tag two tag objects with different OIDs A and B, from different authors, using different tag names, signed with different secret keys, and both pointing to the same commit C.
The implementation would consider A and B to be the same, just becuase A and B both peel to C, skipping the update.
This is counterintuitive, and when combined with canonical references can be quite confusing.
Change this to only reason about an ancestry if the two objects in question really both are commits directly. Otherwise, treat cases where no structure can be used as ancestry similarly to non-fast-forward updates.
This function (and the helpers ancestry and find_and_peel) are
eagerly peeling to commits, leading to updates of tags that target the
same commit to be missed.
For example, there could be tag two tag objects with different OIDs A and B, from different authors, using different tag names, signed with different secret keys, and both pointing to the same commit C.
The implementation would consider A and B to be the same, just becuase A and B both peel to C, skipping the update.
This is counterintuitive, and when combined with canonical references can be quite confusing.
Change this to only reason about an ancestry if the two objects in question really both are commits directly. Otherwise, treat cases where no structure can be used as ancestry similarly to non-fast-forward updates.
Fix formatting.
Rebase
REVIEW: can move Oid equality check earlier
I believe we can move the check to see if the objects are the same before we
even resolve the target object.
Minor change, but saves one trip to the ODB if they are equal.
Squash review and rebase.