Your message dated Wed, 10 Sep 2014 18:18:14 -0400
with message-id <[email protected]>
and subject line Re: Bug#761116: git-annex webapp makes an annex repo out of
home directory
has caused the Debian Bug report #761116,
regarding git-annex webapp makes an annex repo out of home directory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
761116: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761116
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: git-annex
Version: 5.20140831+b1
Severity: important
Tags: upstream
It is not really a common nor good practice, but sometimes users have
their $HOME (dotfiles mostly) directly under git version control,
i.e. ~/.git exists and ~ is the git working directory. Usually most
files are untracked.
In this scenario, if the user starts the git-annex webapp, it
immediately initializes the ~/.git repo as a git-annex repo and starts
adding untracked files there. Before the user even realizes what just
happened and stops the process, hunders or thousands of files are
moved and symlinked to the .git/annex/objects directory.
Of course this does not cause irreversible data loss - the files are
still there and can be restored back to normal files with some
scripting, but it is not an easy task for non-advanced GNU/Linux
users. I think this is very unexpected behaviour - the webapp really
should not do any changes to your files when you start it the first
time.
Happy hacking!
Henrik
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages git-annex depends on:
ii curl 7.37.1-1
ii git 1:2.1.0-1
ii libc6 2.19-10
ii libffi6 3.1-2
ii libgmp10 2:6.0.0+dfsg-6
ii libgnutls-deb0-28 3.3.7-2
ii libgsasl7 1.8.0-3
ii libicu52 52.1-5
ii libidn11 1.29-1
ii libxml2 2.9.1+dfsg1-4
ii libyaml-0-2 0.1.6-2
ii openssh-client 1:6.6p1-7
ii rsync 3.1.1-2
ii wget 1.15-1+b1
ii zlib1g 1:1.2.8.dfsg-1
Versions of packages git-annex recommends:
ii bind9-host 1:9.9.5.dfsg-4
ii git-remote-gcrypt 0.20130908-7
ii gnupg 1.4.18-4
ii lsof 4.86+dfsg-1
ii nocache 0.9-2
ii quvi 0.4.2-2
Versions of packages git-annex suggests:
pn bup <none>
pn graphviz <none>
ii libnss-mdns 0.10-6
pn tahoe-lafs <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Henrik Ahlgren wrote:
> In this scenario, if the user starts the git-annex webapp, it
> immediately initializes the ~/.git repo as a git-annex repo and starts
> adding untracked files there. Before the user even realizes what just
> happened and stops the process, hunders or thousands of files are
> moved and symlinked to the .git/annex/objects directory.
No, it does not. git-annex refuses to operate in a git repository until
git-annex init has been manually run. When I start the webapp from
within my $HOME, I get a prompt to make a new reposotory, since my
$HOME/.git does not have annex.version set.
Additionally, the webapp explicitly detects if the user tells it to
use $HOME, and refuses to do so. "Sorry, using git-annex for your whole
home directory is not currently supported."
The only way you can get git-annex operating in your $HOME git
repository is if you manually run git-annex init there (or merge from
another git repository which has a git-annex branch).
--
see shy jo
signature.asc
Description: Digital signature
--- End Message ---
