This PR changes the behaviour of the gin version command with the --copy-to flag.
Old behaviour: Previously, files checked out from an old version into a new directory were added (but not committed) to the git index. Internally, we would use git annex fromkey to create a new pointer file to annexed content from an old revision. When this command is run, a new pointer file is created and added to the index, since there's no way to retrieve the data it points to if it's not a file known to the repository. Git files that were checked out from an older version would be added to the index explicitly to keep the behaviour consistent. The fromkey command fails on Windows since git-annex tries to create a symlink, regardless of OS, filesystem, or capabilities.
New behaviour: The git annex fromkey command is replaced with a straightforward file copy. The location of the content is retrieved using git annex contentlocation, which returns the file path of the annexed content. If the content isn't available, it's automatically downloaded (more on this later). Once the content is available, the object is copied from the git-annex object store to the location specified by the user. None of the new files checked out from the command are checked into git. With this new behaviour, the user can copy files from an older version of the repository to a location outside the repository's working tree, which makes the command more flexible.
Smaller changes:
Added seconds to the timestamp of files checked out using --copy-to
Runs git annex fsck after a gin version command on all paths to fix any annexed pointer files that are affected.
Changed the red FAILED message when a remote doesn't exist when running the gin add-remote command.
Notes: Automatically downloading the content might not be desirable. I would like to either add a flag that explicitly enables automatic downloading, or have the operation prompt the user for confirmation (possibly both).
This PR changes the behaviour of the
gin versioncommand with the--copy-toflag.Old behaviour: Previously, files checked out from an old version into a new directory were added (but not committed) to the git index. Internally, we would use
git annex fromkeyto create a new pointer file to annexed content from an old revision. When this command is run, a new pointer file is created and added to the index, since there's no way to retrieve the data it points to if it's not a file known to the repository. Git files that were checked out from an older version would be added to the index explicitly to keep the behaviour consistent. The fromkey command fails on Windows since git-annex tries to create a symlink, regardless of OS, filesystem, or capabilities.New behaviour: The
git annex fromkeycommand is replaced with a straightforward file copy. The location of the content is retrieved usinggit annex contentlocation, which returns the file path of the annexed content. If the content isn't available, it's automatically downloaded (more on this later). Once the content is available, the object is copied from the git-annex object store to the location specified by the user. None of the new files checked out from the command are checked into git. With this new behaviour, the user can copy files from an older version of the repository to a location outside the repository's working tree, which makes the command more flexible.Smaller changes:
--copy-togit annex fsckafter agin versioncommand on all paths to fix any annexed pointer files that are affected.gin add-remotecommand.Notes: Automatically downloading the content might not be desirable. I would like to either add a flag that explicitly enables automatic downloading, or have the operation prompt the user for confirmation (possibly both).