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:
parent
36cf163321
commit
9f05be393e
3 changed files with 37 additions and 14 deletions
3
debian/changelog
vendored
3
debian/changelog
vendored
|
@ -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
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue