Browse Source
Several problems: * The command didn't specify whether it expected short or full names. * For the new name, it expected a short name, but then got confused if tags or both local and remote branches with the same name existed. * For the old name, it accepted either a short or a full name, but again got confused if a short name was given and a tag with the same name existed. With such an interface, one cannot use Repository.findRef() to reliably find the branch to rename. Use exactRef() for the new name as by the time the Ref is needed its full name is known. For determining the old Ref from the name, do the resolution explicitly: first try exactRef (assuming the old name is a full name); if that doesn't find anything, try "refs/heads/<old>" and "refs/remotes/<old>" explicitly. Throw an exception if the name is ambiguous, or if exactRef returned something that is not a branch (refs/tags/... or also refs/notes/...). Document in the javadoc what kind of names are valid, and add tests. A user can still shoot himself in the foot if he chooses exceptionally stupid branch names. For instance, it is still possible to rename a branch to "refs/heads/foo" (full name "refs/heads/refs/heads/foo"), but it cannot be renamed further using the new short name if a branch with the full name "refs/heads/foo" exists. Similar edge cases exist for other dumb branch names, like a branch with the short name "refs/tags/foo". Renaming using the full name is always possible. Bug: 542446 Change-Id: I34ac91c80c0a00c79a384d16ce1e727c550d54e9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>stable-5.4
Thomas Wolf
6 years ago
5 changed files with 110 additions and 29 deletions
Loading…
Reference in new issue