From 0389a22be35a667d86c1c543fff9b26f4941f659 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 7 Sep 2020 15:12:03 -0400 Subject: [PATCH] devblog --- .../day_630__dealing_with_git_changes.mdwn | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 doc/devblog/day_630__dealing_with_git_changes.mdwn diff --git a/doc/devblog/day_630__dealing_with_git_changes.mdwn b/doc/devblog/day_630__dealing_with_git_changes.mdwn new file mode 100644 index 0000000000..4f496e96b9 --- /dev/null +++ b/doc/devblog/day_630__dealing_with_git_changes.mdwn @@ -0,0 +1,42 @@ +A stressful thing about maintaining git-annex is that sometimes changes to +git break it in some way. Since git has a high development velocity, it can +be hard to keep up with all changes and catch such problems. The git devs +are good about backwards compatibility, but can still make mistakes. Worse +is when there's an assumption about how people will use git, when git-annex +lets people use it in a rather different way. I've been dealing with one of +those today. + + CONFLICT (file location): x/foo added in refs/remotes/origin/master + inside a directory that was renamed in HEAD, suggesting it should + perhaps be moved to y/foo. + +This was a interesting new git feature when it was added back in 2.18, +especially since git doesn't really track directories, so is here +somewhat guessing if a directory was renamed. + +An example of a way git-annex is used that this does not play well with +is managing media files for consumption, where you might have an incoming +directory, and then rename files to somewhere else once they're processed. +If you renamed the last file in your incoming directory, and then a new +file was later added to it in some other clone of the repository, this git +feature could result in that new file being moved to an unexpected +location when you `git-annex sync`. + +Normally it wouldn't matter much if git guessed wrong like that about a +rename, since the merge conflict forces the user to look at it. +But, git-annex sync and the assistant automatically resolve merge +conflicts, so the user can easily not notice this happening. + +If you're worried that might have happened to you, look for files in your +repository with ".variant" in the name. If there are two with the same +base name, that's a normal merge conflict, but if there's only a single +variant file by itself, it could have been created by this rename +conflict scenario. + +git-annex will now avoid this problem, by setting merge.directoryRenames=false +when running a merge (unless you've manually configured it yourself). + +---- + +Today's work was sponsored by Martin D +[on Patreon](https://www.patreon.com/joeyh)