Commit message (Collapse) | Author | Age | |
---|---|---|---|
* | move keys db closure to AutoMerge | Joey Hess | 2016-05-16 |
| | | | | | This makes git-annex sync also do it, which makes sure that the keys db info is fresh when doing a sync --content. | ||
* | reorder associated file db update | Joey Hess | 2016-05-16 |
| | | | | | | | | | | | | | | | There's a potential race where the smudge filter is run at the same time an object is being downloaded. If the download finished after the inAnnex check, and before the keys db was updated, the associated file would not get updated with the downloaded content. I'm not sure this closes the race; it may only narrow the window. Problem is, the keys database needs to communicate between two different processes. In the case of the assistant, the transferkeys command is the other process, and it closes the db handle after getting the file. So, it should re-open the database and so see the update that the smudge filter has written to it. But, what if the smudge filter takes a while to update the database? | ||
* | Merge branch 'master' of ssh://git-annex.branchable.com | Joey Hess | 2016-05-16 |
|\ | |||
* | | assistant: Fix race in v6 mode that caused downloaded file content to ↵ | Joey Hess | 2016-05-16 |
| | | | | | | | | | | | | | | | | | | | | | | | | sometimes not replace pointer files. The keys database handle needs to be closed after merging, because the smudge filter, in another process, updates the database. Old cached info can be read for a while from the open database handle; closing it ensures that the info written by the smudge filter is available. This is pretty horribly ad-hoc, and it's especially nasty that the transferrer closes the database every time. | ||
* | | assistant: Fix bug that caused v6 pointer files to be annexed by the assistant. | Joey Hess | 2016-05-16 |
| | | |||
* | | stage pointer file not annex link | Joey Hess | 2016-05-16 |
| | | |||
| * | Added a comment | CandyAngel | 2016-05-16 |
| | | |||
| * | Added a comment: timings | midfield | 2016-05-15 |
| | | |||
| * | Added a comment | openmedi | 2016-05-14 |
| | | |||
| * | Added a comment | openmedi | 2016-05-14 |
| | | |||
| * | Added a comment: The problem was path length | drunken_sapo | 2016-05-14 |
| | | |||
| * | Added a comment: layout reasoning | aslkdjasd@656d48eb766881455ee14c8cd4adabdd14aad892 | 2016-05-14 |
| | | |||
| * | Added a comment: adjusting symlink paths | thowz | 2016-05-13 |
| | | |||
| * | Added a comment | drunken_sapo | 2016-05-13 |
|/ | |||
* | adjust: If the adjusted branch already exists, avoid overwriting it, since ↵ | Joey Hess | 2016-05-13 |
| | | | | | | | | | | | | | | | | | 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. | ||
* | found a bad memory use in git | Joey Hess | 2016-05-12 |
| | |||
* | Merge branch 'master' of ssh://git-annex.branchable.com | Joey Hess | 2016-05-12 |
|\ | |||
* | | devblog | Joey Hess | 2016-05-12 |
| | | |||
| * | Added a comment: v6 mode | midfield | 2016-05-12 |
| | | |||
| * | (no commit message) | midfield | 2016-05-12 |
|/ | |||
* | webapp: Avoid confusing display of dead remotes. | Joey Hess | 2016-05-12 |
| | |||
* | followup | Joey Hess | 2016-05-12 |
| | |||
* | response | Joey Hess | 2016-05-12 |
| | |||
* | comment | Joey Hess | 2016-05-12 |
| | |||
* | open bug from forum post | Joey Hess | 2016-05-12 |
| | |||
* | response | Joey Hess | 2016-05-12 |
| | |||
* | response | Joey Hess | 2016-05-12 |
| | |||
* | response | Joey Hess | 2016-05-12 |
| | |||
* | Merge branch 'master' of ssh://git-annex.branchable.com | Joey Hess | 2016-05-12 |
|\ | |||
* | | link to my post "proposal for extending smudge/clean filters with raw file ↵ | Joey Hess | 2016-05-12 |
| | | | | | | | | access" | ||
| * | Added a comment | openmedi | 2016-05-12 |
| | | |||
| * | Added a comment | openmedi | 2016-05-12 |
| | | |||
| * | Added a comment | openmedi | 2016-05-12 |
| | | |||
| * | (no commit message) | midfield | 2016-05-12 |
| | | |||
| * | (no commit message) | paulK | 2016-05-11 |
| | | |||
| * | Added a comment | annexuser | 2016-05-11 |
|/ | |||
* | Merge branch 'master' of ssh://git-annex.branchable.com | Joey Hess | 2016-05-11 |
|\ | |||
* | | Change git annex info remote encryption description to use wording closer to ↵ | Joey Hess | 2016-05-11 |
| | | | | | | | | what's used in initremote. | ||
* | | clarify some things | Joey Hess | 2016-05-11 |
| | | | | | | | | | | | | | | In particular, specifying multiple keyid= in enableremote/initremote doesn't work, and never has AFAICS, so don't suggest using it. Also, there was some public/private key wording confusion. | ||
| * | (no commit message) | midfield | 2016-05-11 |
|/ | |||
* | add news item for git-annex 6.20160511 | Joey Hess | 2016-05-11 |
| | |||
* | prep release6.20160511 | Joey Hess | 2016-05-11 |
| | |||
* | rename ↵ | openmedi | 2016-05-11 |
| | | | | forum/__34__git_annex_assitant_--stop__34___doesn__39__t_work_in_OSX_10.11.4.mdwn to forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4.mdwn | ||
* | (no commit message) | openmedi | 2016-05-11 |
| | |||
* | Fix typo | cmt.miniBill@1ee673129c276f72c8d7c2974091af7618a22c2a | 2016-05-11 |
| | |||
* | Bug report. | paulK | 2016-05-11 |
| | |||
* | Added a comment: git-annex on windows additional | browneej@96fb43ae83ff25c968e65939805b60f3e42f1e06 | 2016-05-10 |
| | |||
* | git-annex visibility on windows | browneej@96fb43ae83ff25c968e65939805b60f3e42f1e06 | 2016-05-10 |
| | |||
* | Added a comment | browneej@96fb43ae83ff25c968e65939805b60f3e42f1e06 | 2016-05-10 |
| | |||
* | typo | Joey Hess | 2016-05-10 |
| |