correct spelling mistakes
This commit is contained in:
Edward Betts
Joey Hess
parent
5e6ced7d0f
commit
0750913136
52 changed files with 69 additions and 69 deletions
|
|
@ -574,7 +574,7 @@ checkBranchDifferences ref = do
|
|||
<$> catFile ref differenceLog
|
||||
mydiffs <- annexDifferences <$> Annex.getGitConfig
|
||||
when (theirdiffs /= mydiffs) $
|
||||
giveup "Remote repository is tuned in incompatable way; cannot be merged with local repository."
|
||||
giveup "Remote repository is tuned in incompatible way; cannot be merged with local repository."
|
||||
|
||||
ignoreRefs :: [Git.Sha] -> Annex ()
|
||||
ignoreRefs rs = do
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ uninitialize = do
|
|||
|
||||
{- Will automatically initialize if there is already a git-annex
|
||||
- branch from somewhere. Otherwise, require a manual init
|
||||
- to avoid git-annex accidentially being run in git
|
||||
- to avoid git-annex accidentally being run in git
|
||||
- repos that did not intend to use it.
|
||||
-
|
||||
- Checks repository version and handles upgrades too.
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ thawPerms a = ifM crippledFileSystem
|
|||
)
|
||||
|
||||
{- Blocks writing to the directory an annexed file is in, to prevent the
|
||||
- file accidentially being deleted. However, if core.sharedRepository
|
||||
- file accidentally being deleted. However, if core.sharedRepository
|
||||
- is set, this is not done, since the group must be allowed to delete the
|
||||
- file.
|
||||
-}
|
||||
|
|
|
|||
12
CHANGELOG
12
CHANGELOG
|
|
@ -1048,7 +1048,7 @@ git-annex (5.20150731) unstable; urgency=medium
|
|||
* webapp: Support enabling known gitlab.com remotes.
|
||||
* Fix rsync special remote to work when -Jn is used for concurrent
|
||||
uploads.
|
||||
* The last release accidentially removed a number of options from the
|
||||
* The last release accidentally removed a number of options from the
|
||||
copy command. (-J, file matching options, etc). These have been added
|
||||
back.
|
||||
* init: Detect when the filesystem is crippled such that it ignores
|
||||
|
|
@ -1258,7 +1258,7 @@ git-annex (5.20150508) unstable; urgency=medium
|
|||
(endpoint, port, storage class)
|
||||
* S3: Let git annex enableremote be used, without trying to recreate
|
||||
a bucket that should already exist.
|
||||
* S3: Fix incompatability with bucket names used by hS3; the aws library
|
||||
* S3: Fix incompatibility with bucket names used by hS3; the aws library
|
||||
cannot handle upper-case bucket names. git-annex now converts them to
|
||||
lower case automatically.
|
||||
* import: Check for gitignored files before moving them into the tree.
|
||||
|
|
@ -1655,7 +1655,7 @@ git-annex (5.20141125) unstable; urgency=medium
|
|||
|
||||
* Remove fixup code for bad bare repositories created by
|
||||
versions 5.20131118 through 5.20131127. That fixup code would
|
||||
accidentially fire when --git-dir was incorrectly
|
||||
accidentally fire when --git-dir was incorrectly
|
||||
pointed at the working tree of a git-annex repository,
|
||||
possibly resulting in data loss. Closes: #768093
|
||||
* Windows: Fix crash when user.name is not set in git config.
|
||||
|
|
@ -3441,7 +3441,7 @@ git-annex (3.20130124) unstable; urgency=low
|
|||
* webapp: Has a page to view the log, accessed from the control menu.
|
||||
* webapp: Fix crash adding removable drive that has an annex directory
|
||||
in it that is not a git repository.
|
||||
* Deal with incompatability in gpg2, which caused prompts for encryption
|
||||
* Deal with incompatibility in gpg2, which caused prompts for encryption
|
||||
passphrases rather than using the supplied --passphrase-fd.
|
||||
* bugfix: Union merges involving two or more repositories could sometimes
|
||||
result in data from one repository getting lost. This could result
|
||||
|
|
@ -3541,7 +3541,7 @@ git-annex (3.20121211) unstable; urgency=low
|
|||
associated with a file.
|
||||
* webapp: S3 and Glacier forms now have a select list of all
|
||||
currently-supported AWS regions.
|
||||
* webdav: Avoid trying to set props, avoiding incompatability with
|
||||
* webdav: Avoid trying to set props, avoiding incompatibility with
|
||||
livedrive.com. Needs DAV version 0.3.
|
||||
* webapp: Prettify error display.
|
||||
* webapp: Fix bad interaction between required fields and modals.
|
||||
|
|
@ -4970,7 +4970,7 @@ git-annex (0.04) unstable; urgency=low
|
|||
* Note that git-annex 0.04 cannot transfer content from old repositories
|
||||
that have not yet been upgraded.
|
||||
* Annexed file contents are now made unwritable and put in unwriteable
|
||||
directories, to avoid them accidentially being removed or modified.
|
||||
directories, to avoid them accidentally being removed or modified.
|
||||
(Thanks Josh Triplett for the idea.)
|
||||
* Add build dep on libghc6-testpack-dev. Closes: #603016
|
||||
* Avoid using runghc to run test suite as it is not available on all
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ seek = withNothing start
|
|||
start :: CommandStart
|
||||
start = ifM versionSupportsDirectMode
|
||||
( ifM isDirect ( stop , next perform )
|
||||
, giveup "Direct mode is not suppported by this repository version. Use git-annex unlock instead."
|
||||
, giveup "Direct mode is not supported by this repository version. Use git-annex unlock instead."
|
||||
)
|
||||
|
||||
perform :: CommandPerform
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ import Git.FilePath
|
|||
cmd :: Command
|
||||
cmd = withGlobalOptions annexedMatchingOptions $
|
||||
command "unannex" SectionUtility
|
||||
"undo accidential add command"
|
||||
"undo accidental add command"
|
||||
paramPaths (withParams seek)
|
||||
|
||||
seek :: CmdParams -> CommandSeek
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ encryptionSetup c gc = do
|
|||
(map ("encryption=" ++)
|
||||
["none","shared","hybrid","pubkey", "sharedpubkey"])
|
||||
++ "."
|
||||
key = fromMaybe (giveup "Specifiy keyid=...") $ M.lookup "keyid" c
|
||||
key = fromMaybe (giveup "Specify keyid=...") $ M.lookup "keyid" c
|
||||
newkeys = maybe [] (\k -> [(True,k)]) (M.lookup "keyid+" c) ++
|
||||
maybe [] (\k -> [(False,k)]) (M.lookup "keyid-" c)
|
||||
cannotchange = giveup "Cannot set encryption type of existing remotes."
|
||||
|
|
|
|||
4
Test.hs
4
Test.hs
|
|
@ -122,7 +122,7 @@ runner = Just $ \opts -> isolateGitConfig $ do
|
|||
Just act -> ifM act
|
||||
( exitSuccess
|
||||
, do
|
||||
putStrLn " (This could be due to a bug in git-annex, or an incompatability"
|
||||
putStrLn " (This could be due to a bug in git-annex, or an incompatibility"
|
||||
putStrLn " with utilities, such as git, installed on this system.)"
|
||||
exitFailure
|
||||
)
|
||||
|
|
@ -452,7 +452,7 @@ test_drop_untrustedremote = intmpclonerepo $ do
|
|||
git_annex "untrust" ["origin"] @? "untrust of origin failed"
|
||||
git_annex "get" [annexedfile] @? "get failed"
|
||||
annexed_present annexedfile
|
||||
not <$> git_annex "drop" [annexedfile] @? "drop wrongly suceeded with only an untrusted copy of the file"
|
||||
not <$> git_annex "drop" [annexedfile] @? "drop wrongly succeeded with only an untrusted copy of the file"
|
||||
annexed_present annexedfile
|
||||
inmainrepo $ annexed_present annexedfile
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ lockExclusive = openLock fILE_SHARE_NONE
|
|||
{- Windows considers just opening a file enough to lock it. This will
|
||||
- create the LockFile if it does not already exist.
|
||||
-
|
||||
- Will fail if the file is already open with an incompatable ShareMode.
|
||||
- Will fail if the file is already open with an incompatible ShareMode.
|
||||
- Note that this may happen if an unrelated process, such as a virus
|
||||
- scanner, even looks at the file. See http://support.microsoft.com/kb/316609
|
||||
-
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
- bugs.
|
||||
-
|
||||
- This exports functions that conflict with the prelude, which avoids
|
||||
- them being accidentially used.
|
||||
- them being accidentally used.
|
||||
-}
|
||||
|
||||
{-# OPTIONS_GHC -fno-warn-tabs #-}
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ FAIL (0.29s)
|
|||
addurl failed on file:///private/var/folders/4j/br7bdhjx4b384_snb2087gt00000gn/T/nix-build-git-annex-5.20151116.drv-0/git-annex-5.20151116/.t/tmprepo0/myurl
|
||||
|
||||
2 out of 150 tests failed (126.13s)
|
||||
(This could be due to a bug in git-annex, or an incompatability
|
||||
(This could be due to a bug in git-annex, or an incompatibility
|
||||
with utilities, such as git, installed on this system.)
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Hi,
|
||||
|
||||
some time ago, I accidentially copied some files from the archive to the non-archive part of my (indirect, type 'client') repository (instead of moving), with the effect that assistant always kept downloading and afterwards immediately dropping the files. Now this was not really suprising once I found the duplicate folder, but maybe git annex could detect this case and refuse to run in circles or at least complain about it.
|
||||
some time ago, I accidentally copied some files from the archive to the non-archive part of my (indirect, type 'client') repository (instead of moving), with the effect that assistant always kept downloading and afterwards immediately dropping the files. Now this was not really surprising once I found the duplicate folder, but maybe git annex could detect this case and refuse to run in circles or at least complain about it.
|
||||
|
||||
Best
|
||||
Karsten
|
||||
|
|
|
|||
|
|
@ -18,10 +18,10 @@ content of objects when in sharedRepository mode, like it normally does.
|
|||
|
||||
Since that's a belt and suspenders protection, and since the object
|
||||
directory permissions weakening already lost a similar protection against
|
||||
accidential deletion of object files, shrug, I guess we'll do that.
|
||||
accidental deletion of object files, shrug, I guess we'll do that.
|
||||
|
||||
I do feel that sharedRepository mode rarely ever makes sense to use. It's
|
||||
very fiddely to get the permissions set up right and keep them right, and
|
||||
very fiddly to get the permissions set up right and keep them right, and
|
||||
there are much better ways to share a centralized repo between users, eg
|
||||
use gitolite or a dedicated account that's locked down to only let
|
||||
git/git-annex commands be run.
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@ building all libraries again. So, it would be a lot of CPU on an ongoing basis,
|
|||
or a source of unfixed security bugs.
|
||||
|
||||
And, I think it would not be entirely non-fragile. It's not exactly unheard
|
||||
of for a new version of a haskell library to accidentially break
|
||||
compatability with the old version of ghc which is generally unused in the
|
||||
of for a new version of a haskell library to accidentally break
|
||||
compatibility with the old version of ghc which is generally unused in the
|
||||
haskell community outside of debian stable. Or, to need a newer version of
|
||||
some C library headers than is in stable, or ...
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ OK (0.78s)
|
|||
[Removed 1667 lines]
|
||||
|
||||
3 out of 269 tests failed (640.58s)
|
||||
(This could be due to a bug in git-annex, or an incompatability
|
||||
(This could be due to a bug in git-annex, or an incompatibility
|
||||
with utilities, such as git, installed on this system.)
|
||||
$
|
||||
|
||||
|
|
|
|||
|
|
@ -1222,7 +1222,7 @@ crypto
|
|||
preferred content
|
||||
----------------------------------------------------------------------
|
||||
Some tests failed!
|
||||
(This could be due to a bug in git-annex, or an incompatability
|
||||
(This could be due to a bug in git-annex, or an incompatibility
|
||||
with utilities, such as git, installed on this system.)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ FAIL (7.16s)
|
|||
addurl failed on file:///Users/born/.t/tmprepo0/myurl
|
||||
|
||||
1 out of 1 tests failed (28.13s)
|
||||
(This could be due to a bug in git-annex, or an incompatability
|
||||
(This could be due to a bug in git-annex, or an incompatibility
|
||||
with utilities, such as git, installed on this system.)
|
||||
"""]]
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ I use git v1.9.1 on Ubuntu 14.04 LTS, and git-annex version: 5.20150406-gb2814bc
|
|||
|
||||
OK, in all honesty, I did a 'git annex sync' between the 'add' and the 'commit' above. But I synced with a clone of the repository that I keep on an external drive, which is less updated than my laptop. It is less updated because I always add content on my laptop and then sync/get from the external disk. So the sync did no harm, apparently.
|
||||
|
||||
> Since this seems to be only a problem with messaging about accidentially
|
||||
> Since this seems to be only a problem with messaging about accidentally
|
||||
> marked dead repositories, I've made fsck mention when a file is only
|
||||
> located in a dead repo, and I've made info tell when it's run in a
|
||||
> supposedly-dead repo. [[done]] --[[Joey]]
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ update the whole work tree, and only after it's updated should it update
|
|||
the index and the current branch to reflect the merge.
|
||||
|
||||
This way, if the merge is interrupted, the work tree may have uncommitted
|
||||
changed -- but it's fine if they get accidentially committed, since when
|
||||
changed -- but it's fine if they get accidentally committed, since when
|
||||
the merge is re-done, those changes will by the same ones made by the
|
||||
merge. (I assume this is how `git merge` normally works.) --[[Joey]]
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
date="2015-09-09T21:12:01Z"
|
||||
content="""
|
||||
git-annex should work ok with gpg version 2; there was one minor
|
||||
incompatability vs gpg version 1, but it was ironed out in 2013.
|
||||
incompatibility vs gpg version 1, but it was ironed out in 2013.
|
||||
|
||||
If you build it from source, and have only gpg2 in PATH, and not gpg, it
|
||||
will build a git-annex that runs gpg2.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
### Please describe the problem.
|
||||
|
||||
The shim for the standalone version of git annex invokes the dynamic linker with --library-path set appropriatly. glibc's parsing of library-path treats : and ; as seperaters and has no quoting syntax for those characters. Also path items have to be absolute paths so you can't avoid having the whole path.
|
||||
The shim for the standalone version of git annex invokes the dynamic linker with --library-path set appropriately. glibc's parsing of library-path treats : and ; as separators and has no quoting syntax for those characters. Also path items have to be absolute paths so you can't avoid having the whole path.
|
||||
|
||||
As a result if you install the standalone version in a directory whose path includes either of those characters it will produce a library-path that's interpreted incorrectly leading to it looking for the libraries in the wrong place and potentially eventually using the system's installed versions if they are available.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ This bug applies to any version. with a ':' it will probably occur on any unix,
|
|||
|
||||
### Please provide any additional information below.
|
||||
|
||||
This bug can't be fixed. It's unlikely to trip people up but might with a bad combination of label-based drive mounting and odd drive labels. The worst case would be incompatable libraries on the system install which could lead to data corruption.
|
||||
This bug can't be fixed. It's unlikely to trip people up but might with a bad combination of label-based drive mounting and odd drive labels. The worst case would be incompatible libraries on the system install which could lead to data corruption.
|
||||
|
||||
I recommend that the git annex shim should check for ':' or ';' in the path and exit non-zero if they are found.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ that the other side fails to deal with. We can see in your log that the
|
|||
two rsync are communicating successfully over the ssh connection
|
||||
at first.
|
||||
|
||||
This could be something not clean about your ssh connection, or some incompatability
|
||||
This could be something not clean about your ssh connection, or some incompatibility
|
||||
in the versions of rsync or git-annex between the client and the server.
|
||||
It probably wouldn't hurt to make sure client and server have the same rsync
|
||||
version, and perhaps upgrade them both to the newest git-annex in case this
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
### Please describe the problem.
|
||||
|
||||
I understand that `git annex unannex` is essentially there for undoing an accidential `git annex add`. Unfortunately it doesn't do that.
|
||||
I understand that `git annex unannex` is essentially there for undoing an accidental `git annex add`. Unfortunately it doesn't do that.
|
||||
|
||||
If I have uncommited changes, which is the case after a `git annex add`, it tells me:
|
||||
If I have uncommitted changes, which is the case after a `git annex add`, it tells me:
|
||||
|
||||
git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
|
||||
CallStack (from HasCallStack):
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ at debugging output to find:
|
|||
messages.
|
||||
2. The git-receive-pack side waited on the wrong thread, so didn't
|
||||
notice when the program was done.
|
||||
3. I accidentially used the wrong attribute name when sending a ReceivePackDone
|
||||
3. I accidentally used the wrong attribute name when sending a ReceivePackDone
|
||||
message.
|
||||
|
||||
But all in all, it just worked.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Only one bug fix today, but it was a doozie. It seems that gpg2 has an
|
||||
incompatability with the gpg 1.x that git-annex was written for, that
|
||||
incompatibility with the gpg 1.x that git-annex was written for, that
|
||||
causes large numbers of excess passphrase prompts, when it's supposed to be
|
||||
using a remote's symmetric encryption key. Adding the --batch parameter
|
||||
fixed this.
|
||||
|
|
|
|||
|
|
@ -6,5 +6,5 @@
|
|||
content="""
|
||||
@Karsten does KBOX work on this version of Android? <http://kevinboone.net/Term-debug.apk>
|
||||
|
||||
It may well be that this is just too old and incompatable for the terminal to work.
|
||||
It may well be that this is just too old and incompatible for the terminal to work.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ restarts itself.
|
|||
|
||||
To clean up the old installation, a git-annex.MANIFEST file is looked for
|
||||
in it, and the files listed, as well as empty directories, are deleted.
|
||||
I don't want to accidentially delete something I didn't ship!
|
||||
I don't want to accidentally delete something I didn't ship!
|
||||
|
||||
## restart on upgrade
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ MVars.)
|
|||
|
||||
(Note that if the database is a cache, there is no need to perform migrations
|
||||
when querying it. My benchmarks skip `runMigration`. Instead, if the query
|
||||
fails, the database doesn't exist, or uses an incompatable schema, and the
|
||||
fails, the database doesn't exist, or uses an incompatible schema, and the
|
||||
cache can be rebuilt then. This avoids the problem that persistent's migrations
|
||||
can sometimes fail.)
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ That fixed one last Windows bug that was disabled in the test suite:
|
|||
`git annex add ..\subdir\file` will now work.
|
||||
|
||||
I am re-installing the Android autobuilder for 2 reasons: I noticed I had
|
||||
accidentially lost a patch to make a library use the Android SSL cert directory,
|
||||
accidentally lost a patch to make a library use the Android SSL cert directory,
|
||||
and also a new version of GHC is very near to release and so it makes sense
|
||||
to update.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Today I put together a lot of things I've been thinking about:
|
|||
git-annex user to upgrade their repository, and would be very painful.
|
||||
It's hard to imagine a change that is worth that amount of pain.
|
||||
* There are other changes some would like to see (like lower-case object
|
||||
hash directory names) that are certianly not enough to warrant a flag
|
||||
hash directory names) that are certainly not enough to warrant a flag
|
||||
day repo format upgrade.
|
||||
* It would be nice to let people who want to have some flexibility to play
|
||||
around with changes, in their own repos, as long as they don't a)
|
||||
|
|
@ -32,7 +32,7 @@ The main limitations are:
|
|||
|
||||
I built all the infrastructure for this today. Basically, the git-annex
|
||||
branch gets a record of all tunings that have been applied, and they're
|
||||
automatically propigated to new clones of a repository.
|
||||
automatically propagated to new clones of a repository.
|
||||
|
||||
And I implemented the first tunable setting:
|
||||
|
||||
|
|
@ -40,10 +40,10 @@ And I implemented the first tunable setting:
|
|||
|
||||
This is definitely an experimental feature for now.
|
||||
`git-annex merge` and similar commands will detect attempts to merge
|
||||
between incompatably tuned repositories, and error out. But, there are a
|
||||
between incompatibly tuned repositories, and error out. But, there are a
|
||||
lot of ways to shoot yourself in the foot if you use this feature:
|
||||
|
||||
* Nothing stops `git merge` from merging two incompatable repositories.
|
||||
* Nothing stops `git merge` from merging two incompatible repositories.
|
||||
* Nothing stops any version of git-annex older from today from merging
|
||||
either.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Reduced activity this week (didn't work on the assistant after all),
|
|||
but several things got done:
|
||||
|
||||
Monday: Fixed `fsck --fast --from remote` to not fail when the remote
|
||||
didn't support fast copy mode. And dealt with an incompatability in S3 bucket
|
||||
didn't support fast copy mode. And dealt with an incompatibility in S3 bucket
|
||||
names; the old hS3 library supported upper-case bucket names but the new
|
||||
one needs them all in lower case.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ and so lets a lot of queries be done much faster. The implementation
|
|||
should make it easy to add --batch to more plumbing commands as needed,
|
||||
and could probably extend to non-plumbing commands too.
|
||||
|
||||
Today: The first 5 hours involved an incompatable mess of ssh and rsync
|
||||
versions on Windows. A gordian knot of brokenness and depedency hell.
|
||||
Today: The first 5 hours involved an incompatible mess of ssh and rsync
|
||||
versions on Windows. A Gordian knot of brokenness and dependency hell.
|
||||
I finally found a solution which involves downgrading the cygwin rsync
|
||||
to an older version, and using msysgit's ssh rather than cygwin's.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Made a release this morning, mostly because the release earlier this week
|
||||
turns out to have accidentially removed several options from `git annex copy`.
|
||||
turns out to have accidentally removed several options from `git annex copy`.
|
||||
|
||||
Spent some time this afternoon improving how git-annex shuts down when
|
||||
--time-limit is used. This used to be a quick and dirty shutdown, similar
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@ one more feature to it today: Full anacron style scheduling. So a fsck can
|
|||
be scheduled to run once per week, or month, or year, and it'll run the
|
||||
fsck the next time it's available after that much time has passed. The nice
|
||||
thing about this is I didn't have to change Cronner *at all* to add this,
|
||||
just improved the Recurrance data type and the code that calculates when
|
||||
just improved the Recurrence data type and the code that calculates when
|
||||
to run events.
|
||||
|
||||
Rest of the day I've been catching up on some bug reports. The main bug I
|
||||
fixed caused git-annex on Android to hang when adding files. This turns out
|
||||
to be because it's using a new (unreleased) version of git, and
|
||||
`git check-attr -z` output format has changed in an incompatable way.
|
||||
`git check-attr -z` output format has changed in an incompatible way.
|
||||
|
||||
I am currently 70 messages behind, which includes some ugly looking bug
|
||||
reports, so I will probably continue with this over the next couple days.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
git-annex 6.20160419 has a rare security fix.
|
||||
A [bug](http://git-annex.branchable.com/bugs/External_special_remote_broken__63__/) made encrypted special
|
||||
remotes that are configured to use chunks accidentially expose the checksums
|
||||
remotes that are configured to use chunks accidentally expose the checksums
|
||||
of content that is uploaded to the remote. Such information is supposed to
|
||||
be hidden from the remote's view by the encryption. The same bug also made
|
||||
resuming interrupted uploads to such remotes start over from the beginning.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
subject="comment 1"
|
||||
date="2016-04-29T10:26:22Z"
|
||||
content="""
|
||||
> A bug made encrypted special remotes that are configured to use chunks accidentially expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption.
|
||||
> A bug made encrypted special remotes that are configured to use chunks accidentally expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption.
|
||||
|
||||
What should the users do to repair this situation? How can the exposed checksums be removed from the remote? Is a `git annex sync` enough?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
A productive day of small fixes. Including a change to deal with an
|
||||
incompatability in git 2.9's commit.gpgsign, and couple of fixes
|
||||
incompatibility in git 2.9's commit.gpgsign, and couple of fixes
|
||||
involving gcrypt repositories.
|
||||
|
||||
Also several improvements to cloning from repositories where an adjusted
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
content="""
|
||||
\"Checking out files\" is a message printed by git (not by git-annex) when it is updating the work tree.
|
||||
|
||||
It still seems that you have somehow committed large files directly to git. Perhaps you accidentially ran \"git add\" on a large file.
|
||||
It still seems that you have somehow committed large files directly to git. Perhaps you accidentally ran \"git add\" on a large file.
|
||||
|
||||
git annex sync is probably merging this commit from one of your other repositories.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ A few likely reasons:
|
|||
* If a 4th client repository had popped up.
|
||||
* If you have configured a high number of copies, it might only be able to be met by keeping files on the transfer repository.
|
||||
* Similarly, if a repository that used to have the files has been marked as dead or deleted, more copies might be needed to make up for that.
|
||||
* For completeness, if the transfer repository accidentially had its type changed to some other kind of repository, like a full backup.
|
||||
* For completeness, if the transfer repository accidentally had its type changed to some other kind of repository, like a full backup.
|
||||
|
||||
You can enable debugging (start with --debug or go into the webapp's preferences) and it might say a little more, but the debugging info is not very good.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,5 +16,5 @@ too many files to look at.
|
|||
|
||||
Another approach is to look at the git log, find the commit that merged
|
||||
the unwanted changed (and created these variant files), and `git revert` that
|
||||
merge, and the earlier commit that was made accidentially.
|
||||
merge, and the earlier commit that was made accidentally.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
subject="""comment 2"""
|
||||
date="2015-09-09T18:18:17Z"
|
||||
content="""
|
||||
I wish this incompatability didn't exist either, but the transition to use
|
||||
I wish this incompatibility didn't exist either, but the transition to use
|
||||
consistently 3 letter hash directories would be too much to ask of all the
|
||||
users. And there are ways to convert a bare to non-bare that don't have
|
||||
this problem, like making a clone and using `git annex move --all --from
|
||||
|
|
|
|||
|
|
@ -26,5 +26,5 @@ And here for a binary file stored in git:
|
|||
|
||||
If you find the latter in the log, then the author and commit message of the commit adding it would be interesting.
|
||||
|
||||
Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentially committed it directly to git.
|
||||
Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentally committed it directly to git.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@
|
|||
From the man page:
|
||||
|
||||
> Until a repository (**or one of its remotes**) has been initialized
|
||||
> git-annex will refuse to operate on it, to avoid accidentially
|
||||
> using it in a repository that was not intended tohave an annex.
|
||||
> git-annex will refuse to operate on it, to avoid accidentally
|
||||
> using it in a repository that was not intended to have an annex.
|
||||
|
||||
So, yes, it assumes that if a repository has a git-annex branch already, git-annex is being used, and no explicit init is necessary. You can still run `git annex init` after the fact if you like.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ EDIT:
|
|||
Exception: .t/tmprepo9/.git/annex/journal: getDirectoryContents: permission denied (Access is denied.)
|
||||
|
||||
2 out of 83 tests failed
|
||||
(This could be due to a bug in git-annex, or an incompatability
|
||||
(This could be due to a bug in git-annex, or an incompatibility
|
||||
with utilities, such as git, installed on this system.)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Object files stored in `.git/annex/objects` are each put in their own directory.
|
||||
This allows the write bit to be removed from both the file, and its directory,
|
||||
which prevents accidentially deleting or changing the file contents.
|
||||
which prevents accidentally deleting or changing the file contents.
|
||||
|
||||
The reasoning for doing this follows:
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ But git-annex does not make a local copy of a file added to it, because
|
|||
the file could be very large.
|
||||
|
||||
So, it's important for git-annex to find another way to preserve the expected
|
||||
property that once committed, you cannot accidentially lose a file.
|
||||
property that once committed, you cannot accidentally lose a file.
|
||||
The most important protection it makes is just to remove the write bit of
|
||||
the file. Thus preventing programs from modifying it.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,5 +4,5 @@
|
|||
subject="comment 12"
|
||||
date="2013-05-24T15:33:12Z"
|
||||
content="""
|
||||
Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentially publishing their AWS creds to their friends, since that could cost them a lot of money.
|
||||
Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentally publishing their AWS creds to their friends, since that could cost them a lot of money.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ data out of your encrypted backup. You need to find a secure way to store a
|
|||
backup of your gpg key. Printing it out and storing it in a safe deposit box,
|
||||
for example.
|
||||
|
||||
You can actually specifiy keyid= as many times as you like to allow any one
|
||||
You can actually specify keyid= as many times as you like to allow any one
|
||||
of a set of gpg keys to access this repository. So you could add a friend's
|
||||
key, or another gpg key you have.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
Restarting the daemon should just take a second and the web browser should
|
||||
redirect to the new instance. I guess it does move away from the current
|
||||
page to the dashboard, and in a way that the back button can't undo, but I
|
||||
see no other harm in accidentially restarting the daemon.
|
||||
see no other harm in accidentally restarting the daemon.
|
||||
|
||||
So, I think I'll just add a spacer to separate the repository part of that
|
||||
menu from the daemon part.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ out of the user's view, because it's a complication that should not
|
|||
need to worry about.
|
||||
|
||||
Keeping it in an env var does avoid complicating the discoverable
|
||||
interface with some parameter to specifiy the commit message. Another
|
||||
interface with some parameter to specify the commit message. Another
|
||||
way would be to make the commit message configurable in git config.
|
||||
Then it could be overridden with -c. Seems like the user of this
|
||||
feature is likely going to also use annex.alwayscommit=false sometimes
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
subject="comment 3"
|
||||
date="2012-11-04T19:58:28Z"
|
||||
content="""
|
||||
I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Or the user accidentially doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.)
|
||||
I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentally git committing a bad symlink. Or the user accidentally doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.)
|
||||
|
||||
However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`.
|
||||
"""]]
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ if [ -z "$GIT_ANNEX_PACKAGE_INSTALL" ]; then
|
|||
fi
|
||||
fi
|
||||
|
||||
# Put our binaries first, to avoid issues with out of date or incompatable
|
||||
# Put our binaries first, to avoid issues with out of date or incompatible
|
||||
# system binaries. Extra binaries come after system path.
|
||||
ORIG_PATH="$PATH"
|
||||
export ORIG_PATH
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ if [ ! -e "$HOME/.ssh/git-annex-wrapper" ]; then
|
|||
fi
|
||||
fi
|
||||
|
||||
# Put our binaries first, to avoid issues with out of date or incompatable
|
||||
# Put our binaries first, to avoid issues with out of date or incompatible
|
||||
# system binaries. Extra binaries come after system path.
|
||||
ORIG_PATH="$PATH"
|
||||
export ORIG_PATH
|
||||
|
|
|
|||
Loading…
Reference in a new issue