summaryrefslogtreecommitdiff
path: root/Git/Command.hs
Commit message (Collapse)AuthorAge
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* Switch to using relative paths to the git repository.Gravatar Joey Hess2015-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the git repository to be moved while git-annex is running in it, with fewer problems. On Windows, this avoids some of the problems with the absurdly small MAX_PATH of 260 bytes. In particular, git-annex repositories should work in deeper/longer directory structures than before. See http://git-annex.branchable.com/bugs/__34__git-annex:_direct:_1_failed__34___on_Windows/ There are several possible ways this change could break git-annex: 1. If it changes its working directory while it's running, that would be Bad News. Good news everyone! git-annex never does so. It would also break thread safety, so all such things were stomped out long ago. 2. parentDir "." -> "" which is not a valid path. I had to fix one instace of this, and I should probably wipe all calls to parentDir out of the git-annex code base; it was never a good idea. 3. Things like relPathDirToFile require absolute input paths, and code assumes that the git repo path is absolute and passes it to it as-is. In the case of relPathDirToFile, I converted it to not make this assumption. Currently, the test suite has 16 failures.
* fix some mixed space+tab indentationGravatar Joey Hess2014-10-09
| | | | | | | | | This fixes all instances of " \t" in the code base. Most common case seems to be after a "where" line; probably vim copied the two space layout of that line. Done as a background task while listening to episode 2 of the Type Theory podcast.
* reorgGravatar Joey Hess2014-07-04
| | | | | | avoid Git.Command needing Utility.Batch which needs async For github-backup etc
* export CreateProcess fields from Utility.ProcessGravatar Joey Hess2014-06-10
| | | | update code to avoid cwd and env redefinition warnings
* fix all remaining -Wall warnings on WindowsGravatar Joey Hess2014-02-25
|
* unbreak the buildGravatar Joey Hess2014-02-12
|
* remove windows --git-dir unix style path hackGravatar Joey Hess2014-02-11
| | | | | | This is no longer necessary, at least with msysgit 1.8.5.2.msysgit.0. Its root cause may have been fixed by other recent git path fixes. It was causing the webapp to fail to make repos on other drives.
* Windows: Fix handling of absolute unix-style git repository paths.Gravatar Joey Hess2014-02-08
| | | | | | | | | | | | | Note that on Windows a remote with a path like /home/foo/bar is interpreted by git as being some screwy relative path (relative to what exactly seems ill-defined -- it seemed relative to C:\Program Files\Git\ in my tests!) So no attempt has been made to handle such a path sanely, just not to crash when encountering it. Note that "C:\\foo" </> "/home/foo/bar" yields /home/foo/bar even though that is not absolute! I don't know what to make of all this, except that I will be very happy when this crock of **** vanishes from the face of the earth.
* assistant: Run the periodic git gc in batch mode.Gravatar Joey Hess2014-01-22
|
* Avoid looping if long-running git cat-file or git hash-object crashes and ↵Gravatar Joey Hess2014-01-01
| | | | keeps crashing when restarted.
* pass -c option on to all git commands runGravatar Joey Hess2013-11-05
| | | | | | | | The -c option now not only modifies the git configuration seen by git-annex, but it is passed along to every git command git-annex runs. This was easy to plumb through because gitCommandLine is already used to construct every git command line, to add --git-dir and --work-tree
* git-recover-repository 1/2 doneGravatar Joey Hess2013-10-20
|
* fixGravatar Joey Hess2013-10-17
|
* fixGravatar Joey Hess2013-10-17
|
* fixGravatar Joey Hess2013-10-17
|
* missing importGravatar Joey Hess2013-10-17
|
* Windows: Deal with strange msysgit 1.8.4 behavior of not understanding DOS ↵Gravatar Joey Hess2013-10-17
| | | | formatted paths for --git-dir and --work-tree.
* avoid newline translation when writing to git hash-objectGravatar Joey Hess2013-06-18
| | | | They're like mushrooms, just keep popping up.
* Can now restart certain long-running git processes if they crash, and ↵Gravatar Joey Hess2013-05-31
| | | | | | | | | | | | | | | | | | | continue working. Fuzz tests have shown that git cat-file --batch sometimes stops running. It's not yet known why (no error message; repo seems ok). But this is something we can deal with in the CoProcess framework, since all 3 types of long-running git processes should be restartable if they fail. Note that, as implemented, only IO errors are caught. So an error thrown by the reveiver, when it sees something that is not valid output from git cat-file (etc) will not cause a restart. I don't want it to retry if git commands change their output or are just outputting garbage. This does mean that if the command did a partial output and crashed in the middle, it would still not be restarted. There is currently no guard against restarting a command repeatedly, if, for example, it crashes repeatedly on startup.
* assistant: The ConfigMonitor left one zombie behind each time it checked for ↵Gravatar Joey Hess2013-03-18
| | | | changes, now fixed.
* git subcommand cleanupGravatar Joey Hess2013-03-03
| | | | | | Pass subcommand as a regular param, which allows passing git parameters like -c before it. This was already done in the pipeing set of functions, but not the command running set.
* assistant: Avoid noise in logs from git commit about typechanged files in ↵Gravatar Joey Hess2013-03-01
| | | | direct mode repositories.
* finished where indentation changesGravatar Joey Hess2012-12-13
|
* 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>
* Fix a crash when merging files in the git-annex branch that contain invalid ↵Gravatar Joey Hess2012-10-12
| | | | | | | utf8. The crash actually occurred when writing out the file, which was done to a handle that had not had fileSystemEncoding applied to it.
* fix last zombies in the assistantGravatar Joey Hess2012-10-04
| | | | | Made Git.LsFiles return cleanup actions, and everything waits on processes now, except of course for Seek.
* bugfixGravatar Joey Hess2012-10-04
|
* 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..)
* make a pipeReadStrict, that properly waits on the processGravatar Joey Hess2012-10-04
| | | | | | Nearly everything that's reading from git is operating on a small amount of output and has been switched to use that. Only pipeNullSplit stuff continues using the lazy version that yields zombies.
* flip catchDefaultIOGravatar Joey Hess2012-09-17
|
* run git coprocesses with gitEnvGravatar Joey Hess2012-09-15
|
* thread safe git-annex index file useGravatar Joey Hess2012-08-24
|
* better readProcessGravatar Joey Hess2012-07-19
|
* add back debug loggingGravatar Joey Hess2012-07-19
| | | | | | | | | | | | | Make Utility.Process wrap the parts of System.Process that I use, and add debug logging to them. Also wrote some higher-level code that allows running an action with handles to a processes stdin or stdout (or both), and checking its exit status, all in a single function call. As a bonus, the debug logging now indicates whether the process is being run to read from it, feed it data, chat with it (writing and reading), or just call it for its side effect.
* switch from System.Cmd.Utils to System.ProcessGravatar Joey Hess2012-07-18
| | | | | | | | | | | | | | | | | | Test suite now passes with -threaded! I traced back all the hangs with -threaded to System.Cmd.Utils. It seems it's just crappy/unsafe/outdated, and should not be used. System.Process seems to be the cool new thing, so converted all the code to use it instead. In the process, --debug stopped printing commands it runs. I may try to bring that back later. Note that even SafeSystem was switched to use System.Process. Since that was a modified version of code from System.Cmd.Utils, it needed to be converted too. I also got rid of nearly all calls to forkProcess, and all calls to executeFile, which I'm also doubtful about working well with -threaded.
* add debuggingGravatar Joey Hess2012-07-17
|
* 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.
* noopGravatar Joey Hess2012-04-21
|
* another place hGetBoth was used without a writer threadGravatar Joey Hess2012-02-13
|
* 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.
* 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.
* fix error messageGravatar Joey Hess2012-01-25
|
* remove Utility.Conditional and use IfElseGravatar Joey Hess2012-01-24
| | | | | | | This drops the >>! and >>? with the nice low fixity. IfElse does have undocumented >>=>>! and >>=>>? operators, but I deem that too fishy. Anyway, using whenM and unlessM is easier; I sometimes mixed the operators up.
* split out Git/Command.hsGravatar Joey Hess2011-12-14