git-annex/doc/bugs/Weird_directories_appearing.mdwn
Joey Hess e213ef310f git-annex (5.20140717) unstable; urgency=high
* Fix minor FD leak in journal code. Closes: #754608
  * direct: Fix handling of case where a work tree subdirectory cannot
    be written to due to permissions.
  * migrate: Avoid re-checksumming when migrating from hashE to hash backend.
  * uninit: Avoid failing final removal in some direct mode repositories
    due to file modes.
  * S3: Deal with AWS ACL configurations that do not allow creating or
    checking the location of a bucket, but only reading and writing content to
    it.
  * resolvemerge: New plumbing command that runs the automatic merge conflict
    resolver.
  * Deal with change in git 2.0 that made indirect mode merge conflict
    resolution leave behind old files.
  * sync: Fix git sync with local git remotes even when they don't have an
    annex.uuid set. (The assistant already did so.)
  * Set gcrypt-publish-participants when setting up a gcrypt repository,
    to avoid unncessary passphrase prompts.
    This is a security/usability tradeoff. To avoid exposing the gpg key
    ids who can decrypt the repository, users can unset
    gcrypt-publish-participants.
  * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet
    exist, since it is not automatically created for Gnome 3 users.
  * Windows: Move .vbs files out of git\bin, to avoid that being in the
    PATH, which caused some weird breakage. (Thanks, divB)
  * Windows: Fix locking issue that prevented the webapp starting
    (since 5.20140707).

# imported from the archive
2014-07-17 11:27:25 -04:00

82 lines
2.9 KiB
Markdown

Hello!
Can someone explain this behavior to me? System is ArchLinux with the newest prebuilt tarballs as of Jan 12th.
~ % mkdir GA1
~ % cd GA1
~/GA1 % git init
Initialized empty Git repository in /home/florian/GA1/.git/
~/GA1 (git)-[master] % git annex init
init ok
(Recording state in git...)
~/GA1 (git)-[master] % echo "GA1" > testfile
~/GA1 (git)-[master] % git annex add .
add testfile ok
(Recording state in git...)
~/GA1 (git)-[master] % git annex sync
commit ok
~/GA1 (git)-[master] % cd ..
~ % git clone GA1 GA2
Cloning into 'GA2'...
done.
~ % cd GA2
~/GA2 (git)-[master] % git annex init
init ok
(Recording state in git...)
~/GA2 (git)-[master] % git annex get .
get testfile (merging origin/git-annex into git-annex...)
(Recording state in git...)
(from origin...) ok
(Recording state in git...)
~/GA2 (git)-[master] % git annex unlock testfile
unlock testfile (copying...) ok
~/GA2 (git)-[master] % echo "GA2" > testfile
commit ok
pull origin
ok
push origin
Counting objects: 27, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (20/20), 1.88 KiB | 0 bytes/s, done.
Total 20 (delta 2), reused 0 (delta 0)
To /home/florian/GA1
f0654aa..8d0bdf9 master -> synced/master
* [new branch] git-annex -> synced/git-annex
ok
~/GA2 (git)-[master] % cd ../GA1
~/GA1 (git)-[master] % git annex sync
(merging synced/git-annex into git-annex...)
commit ok
merge synced/master
Updating f0654aa..8d0bdf9
Fast-forward
e6a/e57/SHA256E-s4--241dca52164d30bee7a0be8c097f02e382acff765a9d4136718a37abd437a57c.log | 1 +
testfile | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 e6a/e57/SHA256E-s4--241dca52164d30bee7a0be8c097f02e382acff765a9d4136718a37abd437a57c.log
ok
~/GA1 (git)-[master] % ll
total 4
drwxr-x--- 1 florian florian 6 Jan 12 13:59 e6a/
lrwxrwxrwx 1 florian florian 178 Jan 12 13:59 testfile -> .git/annex/objects/V6/ZM/SHA256E-s4--241dca52164d30bee7a0be8c097f02e382acff765a9d4136718a37abd437a57c/SHA256E-s4--241dca52164d30bee7a0be8c097f02e382acff765a9d4136718a37abd437a57c
~/GA1 (git)-[master] % cat e6a/e57/SHA256E-s4--241dca52164d30bee7a0be8c097f02e382acff765a9d4136718a37abd437a57c.log
1389531554.951523s 1 dedf9799-0131-4773-8939-8f76294fa8e9
Where does the e6a directory comes from? I don't suspect a bug there, but in my conception of git-annex.
Thanks!
Florian
> [[fixed|done]]
>
> I know someone reported this a looong time ago (years), and I cannot find
> that bug report. Probably I closed it because I was unable to find a way
> to reproduce it.
>
> The spurious log files can be safely removed from your working tree.
> --[[Joey]]