summaryrefslogtreecommitdiff
path: root/Messages.hs
Commit message (Collapse)AuthorAge
* fsck: Work around bug in persistent that broke display of problematically ↵Gravatar Joey Hess2015-09-09
| | | | encoded filenames on stderr when using --incremental.
* --debug is passed along to git-annex-shell when git-annex is in debug mode.Gravatar Joey Hess2015-08-13
|
* --debug log messages are now timestamped with fractional seconds.Gravatar Joey Hess2015-08-12
|
* Merge branch 'master' into concurrentprogressGravatar Joey Hess2015-05-12
|\ | | | | | | | | | | | | | | | | | | | | | | Conflicts: Command/Fsck.hs Messages.hs Remote/Directory.hs Remote/Git.hs Remote/Helper/Special.hs Types/Remote.hs debian/changelog git-annex.cabal
| * Improve behavior when a git-annex command is told to operate on a file that ↵Gravatar Joey Hess2015-04-30
| | | | | | | | doesn't exist. It will now continue to other files specified after that on the command line, and only error out at the end.
* | reuse stringsGravatar Joey Hess2015-04-14
| |
* | use built-in progress meters for git when in parallel modeGravatar Joey Hess2015-04-10
|/
* well along the way to fully quiet --quietGravatar Joey Hess2015-04-04
| | | | | | | Came up with a generic way to filter out progress messages while keeping errors, for commands that use stderr for both. --json mode will disable command outputs too.
* WIP on making --quiet silence progress, and infra for concurrent progress barsGravatar Joey Hess2015-04-03
|
* rename showProgress -> showProgressDotsGravatar Joey Hess2015-04-03
|
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* lower case for consistencyGravatar Joey Hess2015-01-10
|
* fix build warningGravatar Joey Hess2014-12-29
| | | | strangely only OSX noticed this was imported and unused
* Promote file not found warning message to an error.Gravatar Joey Hess2014-09-11
|
* unify exception handling into Utility.ExceptionGravatar Joey Hess2014-08-07
| | | | | | | | | | | | | | | | | | | | Removed old extensible-exceptions, only needed for very old ghc. Made webdav use Utility.Exception, to work after some changes in DAV's exception handling. Removed Annex.Exception. Mostly this was trivial, but note that tryAnnex is replaced with tryNonAsync and catchAnnex replaced with catchNonAsync. In theory that could be a behavior change, since the former caught all exceptions, and the latter don't catch async exceptions. However, in practice, nothing in the Annex monad uses async exceptions. Grepping for throwTo and killThread only find stuff in the assistant, which does not seem related. Command.Add.undo is changed to accept a SomeException, and things that use it for rollback now catch non-async exceptions, rather than only IOExceptions.
* refactorGravatar Joey Hess2014-01-26
|
* annex.debug can now be set to enable debug logging by default. The webapp's ↵Gravatar Joey Hess2013-06-17
| | | | debugging check box does this.
* show one alert when bulk adding filesGravatar Joey Hess2013-04-24
| | | | | | | | | | | | Turns out that a lot of the time spent in a bulk add was just updating the add alert to rotate through each file that was added. Showing one alert makes for a significant speedup. Also, when the webapp is open, this makes it take quite a lot less cpu during bulk adds. Also, it lets the user know when a bulk add happened, which is sorta nice..
* expose Control.Monad.joinGravatar Joey Hess2013-04-22
| | | | | I think I've been looking for that function for some time. Ie, I remember wanting to collapse Just Nothing to Nothing.
* hlintGravatar Joey Hess2013-04-03
|
* webapp: Progess bar fixes for many types of special remotes.Gravatar Joey Hess2013-03-28
| | | | | | | | | | | | | There was confusion in different parts of the progress bar code about whether an update contained the total number of bytes transferred, or the number of bytes transferred since the last update. One way this bug showed up was progress bars that seemed to stick at zero for a long time. In order to fix it comprehensively, I add a new BytesProcessed data type, that is explicitly a total quantity of bytes, not a delta. Note that this doesn't necessarily fix every problem with progress bars. Particularly, buffering can now cause progress bars to seem to run ahead of transfers, reaching 100% when data is still being uploaded.
* print a warning message when garbage is received from configlistGravatar Joey Hess2013-03-04
|
* log alerts in notice mode, which is enabled by defaultGravatar Joey Hess2013-01-15
|
* Display a warning when a non-existing file or directory is specified.Gravatar Joey Hess2012-11-25
|
* avoid displaying meter before data is receivedGravatar Joey Hess2012-11-25
| | | | | | The caller may be like glacier, and be running an action that may print a message and fail. So don't start displaying the meter until data is flowing, to avoid getting in the way of such messages being displayed.
* S3: upload progress displayGravatar Joey Hess2012-11-18
|
* refactorGravatar Joey Hess2012-11-18
|
* more indentation. must stop.Gravatar Joey Hess2012-10-28
|
* indentation foo, and a new coding style page. no code changesGravatar Joey Hess2012-10-28
|
* upload progress tracking for the directory special remoteGravatar Joey Hess2012-09-21
|
* unify typesGravatar Joey Hess2012-09-21
|
* hlintGravatar Joey Hess2012-06-12
|
* suppress "(Recording state in git)" message when committing change to remote ↵Gravatar Joey Hess2012-05-20
| | | | | | | | | | | | | | | state This was shown redundantly for a tricky reason -- while it runs inside a doSideAction block that would appear to supress it, the action being run is in a different state monad; for the remote, and so the suppression doesn't work. Always suppressing the message when committing to a local remote is ok do to though -- it mirrors the /dev/nulling of the git annex shell commit output. And it turns out that any time there is a git-annex branch state change to commit on the remote, the local repo has also had a similar change made, and so the message has been shown already.
* display "Recording state in git..." when staging the journalGravatar Joey Hess2012-04-27
| | | | | | | | A bit tricky to avoid printing it twice in a row when there are queued git commands to run and journal to stage. Added a generic way to run an action that may output multiple side messages, with only the first displayed.
* noopGravatar Joey Hess2012-04-21
|
* make meter slightly widerGravatar Joey Hess2012-03-04
|
* Add progress bar display to the directory special remote.Gravatar Joey Hess2012-03-04
| | | | | | | So far I've only written progress bars for sending files, not yet receiving. No longer uses external cp at all. ByteString IO is fast enough.
* hlintGravatar Joey Hess2012-02-16
|
* wordingGravatar Joey Hess2012-02-04
|
* support all filename encodings with ghc 7.4Gravatar Joey Hess2012-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under ghc 7.4, this seems to be able to handle all filename encodings again. Including filename encodings that do not match the LANG setting. I think this will not work with earlier versions of ghc, it uses some ghc internals. Turns out that ghc 7.4 has a special filesystem encoding that it uses when reading/writing filenames (as FilePaths). This encoding is documented to allow "arbitrary undecodable bytes to be round-tripped through it". So, to get FilePaths from eg, git ls-files, set the Handle that is reading from git to use this encoding. Then things basically just work. However, I have not found a way to make Text read using this encoding. Text really does assume unicode. So I had to switch back to using String when reading/writing data to git. Which is a pity, because it's some percent slower, but at least it works. Note that stdout and stderr also have to be set to this encoding, or printing out filenames that contain undecodable bytes causes a crash. IMHO this is a misfeature in ghc, that the user can pass you a filename, which you can readFile, etc, but that default, putStr of filename may cause a crash! Git.CheckAttr gave me special trouble, because the filenames I got back from git, after feeding them in, had further encoding breakage. Rather than try to deal with that, I just zip up the input filenames with the attributes. Which must be returned in the same order queried for this to work. Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It used to forkProcess and feed git from the child process. Unfortunatly, after this forkProcess, accessing the `files` variable from the parent returns []. Not the value that was passed into the function. This screams of a bad bug, that's clobbering a variable, but for now I just avoid forkProcess there to work around it. That forkProcess was itself only added because of a ghc bug, #624389. I've confirmed that the test case for that bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc bug I have not isolated and reported. Why does this simple bit of code magnet the ghc bugs? :) Also, the symlink touching code is currently broken, when used on utf-8 filenames in a non-utf-8 locale, or probably on any filename containing undecodable bytes, and I temporarily commented it out.
* add a check for not utf-8 consoleGravatar Joey Hess2012-02-03
|
* attempt at a quick, utf-8 only fix to the ghc 7.4 problemGravatar Joey Hess2012-02-01
| | | | | If you have only utf-8 filenames, and need to build git-annex with ghc 7.4, this will work. But, it will crash on non-utf-8 filenames.
* find --jsonGravatar Joey Hess2011-12-23
|
* Flush json output, avoiding a buffering problem that could result in doubled ↵Gravatar Joey Hess2011-11-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | output. The bug was that with --json, output lines were sometimes doubled. For example, git annex init --json would output two lines, despite only running one thing. Adding to the weirdness, this only occurred when the output was redirected to a pipe or a file. Strace showed two processes outputting the same buffered output. The second process was this writer process (only needed to work around bug #624389): _ <- forkProcess $ do hPutStr toh $ unlines paths hClose toh exitSuccess The doubled output occurs when this process exits, and ghc flushes the inherited stdout buffer. Why only when piping? I don't know, but ghc may be behaving differently when stdout is not a terminal. While this is quite possibly a ghc bug, there is a nice fix in git-annex. Explicitly flushing after each chunk of json is output works around the problem, and as a side effect, json is streamed rather than being output all at the end when performing an expensive operaition. However, note that this means all uses of putStr in git-annex must be explicitly flushed. The others were, already.
* status --json now shows most thingsGravatar Joey Hess2011-11-20
| | | | | | Left out the backend usage graph for now, and bad/temp directory sizes are only displayed when present. Also, disk usage is returned as a string with units, which I can see changing later.
* better status outputGravatar Joey Hess2011-11-15
|
* status --json --fast for escGravatar Joey Hess2011-11-14
| | | | | | * status: Fix --json mode (only the repository lists are currently displayed) * status: --fast is back
* minor syntax changesGravatar Joey Hess2011-10-11
|
* factor out common importsGravatar Joey Hess2011-10-03
| | | | no code changes
* more newline fixesGravatar Joey Hess2011-09-09
| | | | | | | | | | Adds a missing newline when a longnote is followed by a endresult. Multiple longnotes in a row will now be separated by a blank line, which could be a bug or a feature depending on taste. Removed several places where newlines were explicitly displayed after longnotes.