aboutsummaryrefslogtreecommitdiff
path: root/Command/Log.hs
Commit message (Collapse)AuthorAge
* refactor git-annex branch log filename code into central locationGravatar Joey Hess2013-08-29
| | | | | | | Having one module that knows about all the filenames used on the branch allows working back from an arbitrary filename to enough information about it to implement dropping dead remotes and doing other log file compacting as part of a forget transition.
* add section metadata to all commandsGravatar Joey Hess2013-03-24
| | | | Not yet used .. mindless train work.
* More commands work in direct mode repositories: find, whereis, move, copy, ↵Gravatar Joey Hess2013-01-05
| | | | | | | | drop, log. These started working, for free, once lookupFile supported direct mode. yay!!
* block all commands that don't work in direct modeGravatar Joey Hess2012-12-29
| | | | | I left status working in direct mode, although it doesn't show correct stats for known annex keys.
* where indentationGravatar Joey Hess2012-11-12
|
* remove some more !!Gravatar Joey Hess2012-10-20
|
* better fix for zombie problem, which turns out to be a zombie ssh started by ↵Gravatar Joey Hess2012-10-17
| | | | | | | | | | | | | | | | | | | | | rsync When rsyncProgress pipes rsync's stdout, this turns out to cause a ssh process started by rsync to be left behind as a zombie. I don't know why, but my recent zombie reaping cleanup was correct, it's just that this other zombie, that's not directly started by git-annex, was no longer reaped due to changes in the cleanup. Make rsyncProgress reap the zombie started by rsync, as a workaround. FWIW, the process tree looks like this. It seems like the rsync child is for some reason starting but not waiting on this extra ssh process. Ssh connection caching may be involved -- disabling it seemed to change the shape of the tree, but did not eliminate the zombie. 9378 pts/14 S+ 0:00 | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ... 9379 pts/14 S+ 0:00 | | \_ ssh ... 9380 pts/14 S+ 0:00 | | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ... 9381 pts/14 Z+ 0:00 | \_ [ssh] <defunct>
* remove now-unnecessary manual reapsGravatar Joey Hess2012-10-04
|
* more zombie fightingGravatar Joey Hess2012-10-04
| | | | | | | | | | | | | | | | | | | | I'm down to 9 places in the code that can produce unwaited for zombies. Most of these are pretty innocuous, at least for now, are only used in short-running commands, or commands that run a set of actions and explicitly reap zombies after each one. The one from Annex.Branch.files could be trouble later, since both Command.Fsck and Command.Unused can trigger it, and the assistant will be doing those eventally. Ditto the one in Git.LsTree.lsTree, which Command.Unused uses. The only ones currently affecting the assistant though, are in Git.LsFiles. Several threads use several of those. (And yeah, using pipes or ResourceT would be a less ad-hoc approach, but I don't really feel like ripping my entire code base apart right now to change a foundation monad. Maybe one of these days..)
* Clean up handling of git directory and git worktree.Gravatar Joey Hess2012-05-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Baked into the code was an assumption that a repository's git directory could be determined by adding ".git" to its work tree (or nothing for bare repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are used to separate the two. This was attacked at the type level, by storing the gitdir and worktree separately, so Nothing for the worktree means a bare repo. A complication arose because we don't learn where a repository is bare until its configuration is read. So another Location type handles repositories that have not had their config read yet. I am not entirely happy with this being a Location type, rather than representing them entirely separate from the Git type. The new code is not worse than the old, but better types could enforce more safety. Added support for core.worktree. Overriding it with -c isn't supported because it's not really clear what to do if a git repo's config is read, is not bare, and is then overridden to bare. What is the right git directory in this case? I will worry about this if/when someone has a use case for overriding core.worktree with -c. (See Git.Config.updateLocation) Also removed and renamed some functions like gitDir and workTree that misused git's terminology. One minor regression is known: git annex add in a bare repository does not print a nice error message, but runs git ls-files in a way that fails earlier with a less nice error message. This is because before --work-tree was always passed to git commands, even in a bare repo, while now it's not.
* hlintGravatar Joey Hess2012-02-16
|
* log: Add --gource mode, which generates output usable by gource.Gravatar Joey Hess2012-01-07
| | | | | As part of this, I fixed up how log was getting the descriptions of remotes.
* typoGravatar Joey Hess2012-01-07
|
* reap zombiesGravatar Joey Hess2012-01-07
|
* sped up git annex log rather a lotGravatar Joey Hess2012-01-07
| | | | | See comment! Isn't git fun, always interesting approaches to optimise things that seemed unfixably slow.
* cleanupGravatar Joey Hess2012-01-07
| | | | Broke out pure general functions etc.
* tweakGravatar Joey Hess2012-01-06
|
* tweakGravatar Joey Hess2012-01-06
|
* complete set of log optionsGravatar Joey Hess2012-01-06
|
* log --before=dateGravatar Joey Hess2012-01-06
|
* --boundry was not neededGravatar Joey Hess2012-01-06
|
* better data typeGravatar Joey Hess2012-01-06
|
* log --max-count=nGravatar Joey Hess2012-01-06
|
* change log displayGravatar Joey Hess2012-01-06
| | | | | | | | Including the file in the lines behaves better when limiting with --after, since only files that changed in the time period are shown. Still not fully happy with the line layout, but putting the +/- first followed by the date seems a good change.
* log --after=dateGravatar Joey Hess2012-01-06
|
* use a zipperGravatar Joey Hess2012-01-06
|
* log: New command that displays the location log for file, showing each ↵Gravatar Joey Hess2012-01-06
repository they were added to and removed from. This needs to run git log on the location log files to get at all past versions of the file, which tends to be a bit slow. It would be possible to make a version optimised for showing the location logs for every key. That would only need to run git log once, so would be faster, but it would need to process an enormous amount of data, so would not speed up the individual file case. In the future it would be nice to support log --format. log --json also doesn't work right yet.