diff options
author | Joey Hess <joeyh@joeyh.name> | 2015-01-20 17:35:48 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2015-01-20 17:35:48 -0400 |
commit | 745525e80bb6915f3eb63554de9b735b75991f7d (patch) | |
tree | 1e3de87028105902b20b1e232807b2348d78fefe /doc | |
parent | 91db5dfb006070a4875da133db8e8e386416c16e (diff) |
devblog
Diffstat (limited to 'doc')
-rw-r--r-- | doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn | 30 |
1 files changed, 30 insertions, 0 deletions
diff --git a/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn b/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn new file mode 100644 index 000000000..59865b36b --- /dev/null +++ b/doc/devblog/day_247__hooks_and_large_files_on_windows.mdwn @@ -0,0 +1,30 @@ +Today I got The pre-commit-annex hook working on Windows. It turns out that +msysgit runs hook scripts even when they're not executable, and it parses +the #! line itself. Now git-annex does too, on Windows. + +Also, added a new chapter to the walkthrough, +[[walkthrough/using_special_remotes]]. They clearly needed to be mentioned, +especially to show the workflow of running initremote in one repository, +then syncing another repository and running enableremote to enable the same +special remote there. + +Then more fun Windows porting! Turns out git-annex on Windows didn't handle +files > 2 gb correctly; the way it was getting file size +[uses a too small data type on Windows](https://github.com/jystic/unix-compat/issues/16). +Luckily git-annex itself treats all file sizes as unbounded Integers, +so I was easily able to swap in a `getFileSize` that returns correct +values for large files. + +While I haven't blogged since the 13th and have not been too active until +today, there are still a number of little improvements that have been done +here and there. + +Including a fix for an interesting bug where the assistant would tell +the remotedaemon that the network connection has been lost, twice in a row, +and this would make the remotedeamon fail to reconnect to the remote when +the network came up. I'm not sure what situation triggers this bug (Maybe +machines with 2 interfaces? Or maybe a double disconnection event for 1 +interface?), but I was able to reproduce it by sending messages to the +remotedaemon, and so fixed it. + +Backlog is down to 118 messages. |