adjust: If the adjusted branch already exists, avoid overwriting it, since it might contain changes that have not yet been propigated to the original branch.

Could not think of a foolproof way to detect if the old adjusted branch was
just behind the current branch. It's possible that the user amended the
adjusting commit at the head of the adjusted branch, for example.

I decided to bail in this situation, instead of just entering the old
branch, so that if git annex adjust succeeds the user is always in a
*current* adjusted branch, not some old and out of date one.

What could perhaps be done is enter the old branch and then update it. But
that seems too magical; the user may have rebased master or something or
may not want to propigate the changes from the old branch. Best to error
out.
This commit is contained in:
Joey Hess 2016-05-13 14:04:22 -04:00
parent 36cf163321
commit 9f05be393e
Failed to extract signature
3 changed files with 37 additions and 14 deletions

3
debian/changelog vendored
View file

@ -3,6 +3,9 @@ git-annex (6.20160512) UNRELEASED; urgency=medium
* Change git annex info remote encryption description to use wording
closer to what's used in initremote.
* webapp: Avoid confusing display of dead remotes.
* adjust: If the adjusted branch already exists, avoid overwriting it,
since it might contain changes that have not yet been propigated to the
original branch.
-- Joey Hess <id@joeyh.name> Wed, 11 May 2016 16:08:38 -0400