summaryrefslogtreecommitdiff
path: root/Messages.hs
Commit message (Collapse)AuthorAge
* 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.
* Improve display of newlines around error and warning messages.Gravatar Joey Hess2011-09-06
|
* avoid showing json lists of remotes when not in json modeGravatar Joey Hess2011-09-02
|
* basic json supportGravatar Joey Hess2011-09-01
| | | | | | | | | | | | | | | | | | This includes a generic JSONStream library built on top of Text.JSON (somewhat hackishly). It would be possible to stream out a single json document describing all actions, but it's probably better for consumers if they can expect one json document per line, so I did it that way instead. Output from external programs used for transferring files is not currently hidden when outputting json, which probably makes it not very useful there. This may be dealt with if there is demand for json output for --get or --move to be parsable. The version, status, and find subcommands have hand-crafted output and don't do json. The whereis subcommand needs to be modified to produce useful json.
* generalize quiet flag to output typeGravatar Joey Hess2011-09-01
| | | | This will allow adding other styles of output.
* unify elipsis handlingGravatar Joey Hess2011-07-19
| | | | | And add a simple dots-based progress display, currently only used in v2 upgrade.
* hlint tweaksGravatar Joey Hess2011-07-15
| | | | Did all sources except Remotes/* and Command/*
* better display of thrown errorsGravatar Joey Hess2011-07-05
|
* Maybe reduction pass 2Gravatar Joey Hess2011-05-15
|
* Rethink filename encoding handling for display. Since filename encoding may ↵0.23Gravatar Joey Hess2011-03-12
| | | | or may not match locale settings, any attempt to decode filenames will fail for some files. So instead, do all output in binary mode.
* put in utf8 forcing workaroundGravatar Joey Hess2011-03-08
| | | | | | | | | Haskell's IO layer crashes on characters > 255 when in a non-unicode (latin1) locale. Until Haskell gets better behavior, put in an admittedly ugly workaround for that: git-annex forces utf8 output mode no matter what locale is selected. So if you use a non-utf8 locale, your filenames with characters > 127 will not be displayed as you'd expect. But at least it won't crash.
* qualified importGravatar Joey Hess2011-02-11
|
* update unicode FilePath handlingGravatar Joey Hess2011-02-11
| | | | | | | | Based on http://hackage.haskell.org/trac/ghc/ticket/3307 , whether FilePath contains decoded unicode varies by OS. So, add a configure check for it. Also, renamed showFile to filePathToString
* fooGravatar Joey Hess2011-02-10
|