summaryrefslogtreecommitdiff
path: root/Git/Branch.hs
Commit message (Collapse)AuthorAge
* XMPP: Avoid redundant and unncessary pushes. Note that this breaks ↵Gravatar Joey Hess2013-05-21
| | | | compatibility with previous versions of git-annex, which will refuse to accept any XMPP pushes from this version.
* 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.
* finished where indentation changesGravatar Joey Hess2012-12-13
|
* 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.
* handle case of adding populated drive to just created repoGravatar Joey Hess2012-08-05
| | | | | The just created repo has no master branch commits yet. This is now handled, merging in the master branch from the populated drive.
* fix crashes when run in a git repo that has been initted but has no master ↵Gravatar Joey Hess2012-08-05
| | | | branch yet
* 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
|
* removed another 10 lines via ifMGravatar Joey Hess2012-03-16
|
* 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.
* refactor and check for a detached HEADGravatar Joey Hess2011-12-31
|
* split out Git/Command.hsGravatar Joey Hess2011-12-14
|
* split more stuff out of Git.hsGravatar Joey Hess2011-12-14
|
* move commit to Git.BranchGravatar Joey Hess2011-12-13
|
* broke out Git/Branch.hs and reorganizedGravatar Joey Hess2011-12-12