From 2c9aa367460784b32e9657e0e9de605f004a3cee Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 15 Feb 2017 16:44:10 -0400 Subject: devblog --- doc/devblog/day_447__bug_class.mdwn | 48 +++++++++++++++++ doc/todo/simpler_setup_for_post-update_merge.mdwn | 60 ---------------------- ...r_setup_for_remote_worktree_update_on_push.mdwn | 60 ++++++++++++++++++++++ 3 files changed, 108 insertions(+), 60 deletions(-) create mode 100644 doc/devblog/day_447__bug_class.mdwn delete mode 100644 doc/todo/simpler_setup_for_post-update_merge.mdwn create mode 100644 doc/todo/simpler_setup_for_remote_worktree_update_on_push.mdwn diff --git a/doc/devblog/day_447__bug_class.mdwn b/doc/devblog/day_447__bug_class.mdwn new file mode 100644 index 000000000..c7b3d386c --- /dev/null +++ b/doc/devblog/day_447__bug_class.mdwn @@ -0,0 +1,48 @@ +When you see a command like "ssh somehost rm -f file", you probably don't +think that consumes stdin. After all, the `rm -f` doesn't. But, `ssh` +can pass stdin over the network even if it's not being consumed, and it +turns out git-annex was bitten by this. + +That bug made `git-annex-checkpresentkey --batch` with remote accessed +over ssh not see all the batch-mode input that was passed into it, because +ssh sometimes consumed some of it. + +Shell scripts using git-annex could also be impacted by the bug, for +example: + + #!/bin/sh + find . -type l -atime 100 | \ + while read file; do + echo "gonna drop $file that has not been used in a while" + git annex drop "$file" + done + +Depending on what remotes `git annex drop` talks to, it might consume +parts of the output of find. + +I've fixed this in git-annex now (using `ssh -n` when running commands +that are not fed some stdin of their own), but this seems like a class of +bug that could impact lots of programs that run ssh. + +---- + +I've been thinking about [[simpler_setup_for_remote_worktree_update_on_push]]. + +One nice way to make a remote update its worktree on push is available +in recent-ish gits, receive.denyCurrentBranch=updateInstead. That could +already be used with `git annex sync`, but it hid any error messages +when pushing the master branch to the remote (since that push fails with +a large error message in default configurations). Found a way to make +the error message be displayed when the remote's receive.denyCurrentBranch +does not have the default configuration. + +The remaining problem is that direct mode and adjusted branch remotes +won't get their works trees updated even when configured that way. I am +thinking about adding a post-update hook to support those. + +---- + +Also continuing to bring up the ancient kernel arm autobuilder. It's running +its first build now. + +Today's work was sponsored by Riku Voipio. diff --git a/doc/todo/simpler_setup_for_post-update_merge.mdwn b/doc/todo/simpler_setup_for_post-update_merge.mdwn deleted file mode 100644 index 8d25f44b9..000000000 --- a/doc/todo/simpler_setup_for_post-update_merge.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -A git post-update hook can run git-annex merge and so make all pushes -into a repository update its working tree. - -But, there are some complications to writing that hook. See - -IIRC different versions of git may behave differently. - -And, such a hook can't be used on a filesystem that doesn't support -executables. (Except on Windows which has a workaround to allow -non-executable hooks.) - -Could there be a single command that sets it up? Something like -`git annex merge --run-automatically` - -That could install the hook, and also set an annex.automerge config. - -The config could be checked by git-annex sync (and assistant) when pushing -to a local remote, and they could perform a merge on the remote. This way, -it would work for repos on removable drives that don't support execute -bits. (Ssh remotes on such filesystems would not be handled, but that's a -rare configuration; the hook would handle ssh remotes on non-crippled -filesystems, and on Windows.) - ---- - -Alternatively, receive.denyCurrentBranch can be set to updateInstead. -With this configuration, `git annex sync` automatically updates the -work-tree of the remote already. - -This wouldn't work for direct mode repositories, which are often used -on removable drives, since git thinks they're bare repos. - -Nor will it work for adjusted branches, since the adjusted branch is not -updated by the push. - ---- - -Could the updateInstead configuration be made to work for direct mode and -adjusted branches? Could install a post-update hook, that runs a git-annex -command that checks for updateInstead, and emulates its behavior, handling -direct mode and adjusted branches. - ---- - -Potential least surprise violation: - -If a repository is updating when git annex pushes changes to it, -the user might also expect that the same git annex sync -would pull changes from that repository. Even though nothing has been -run on the repository to commit changes made there. - -Particularly when the assistant is being used, this seems an easy confusion -to have. In one clone the user sees every file change getting committed -and synced around, so why would that not happen in the other clone, on the -removable drive? - -Keeping this a command-line setup, and not something the assistant does, -will avoid that confusion. - ---[[Joey]] diff --git a/doc/todo/simpler_setup_for_remote_worktree_update_on_push.mdwn b/doc/todo/simpler_setup_for_remote_worktree_update_on_push.mdwn new file mode 100644 index 000000000..8d25f44b9 --- /dev/null +++ b/doc/todo/simpler_setup_for_remote_worktree_update_on_push.mdwn @@ -0,0 +1,60 @@ +A git post-update hook can run git-annex merge and so make all pushes +into a repository update its working tree. + +But, there are some complications to writing that hook. See + +IIRC different versions of git may behave differently. + +And, such a hook can't be used on a filesystem that doesn't support +executables. (Except on Windows which has a workaround to allow +non-executable hooks.) + +Could there be a single command that sets it up? Something like +`git annex merge --run-automatically` + +That could install the hook, and also set an annex.automerge config. + +The config could be checked by git-annex sync (and assistant) when pushing +to a local remote, and they could perform a merge on the remote. This way, +it would work for repos on removable drives that don't support execute +bits. (Ssh remotes on such filesystems would not be handled, but that's a +rare configuration; the hook would handle ssh remotes on non-crippled +filesystems, and on Windows.) + +--- + +Alternatively, receive.denyCurrentBranch can be set to updateInstead. +With this configuration, `git annex sync` automatically updates the +work-tree of the remote already. + +This wouldn't work for direct mode repositories, which are often used +on removable drives, since git thinks they're bare repos. + +Nor will it work for adjusted branches, since the adjusted branch is not +updated by the push. + +--- + +Could the updateInstead configuration be made to work for direct mode and +adjusted branches? Could install a post-update hook, that runs a git-annex +command that checks for updateInstead, and emulates its behavior, handling +direct mode and adjusted branches. + +--- + +Potential least surprise violation: + +If a repository is updating when git annex pushes changes to it, +the user might also expect that the same git annex sync +would pull changes from that repository. Even though nothing has been +run on the repository to commit changes made there. + +Particularly when the assistant is being used, this seems an easy confusion +to have. In one clone the user sees every file change getting committed +and synced around, so why would that not happen in the other clone, on the +removable drive? + +Keeping this a command-line setup, and not something the assistant does, +will avoid that confusion. + +--[[Joey]] -- cgit v1.2.3