From 8f9457dec8cd17ed28baf7c628aed74e1cd0c1b7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 30 Apr 2019 16:33:48 -0400 Subject: [PATCH] devblog --- .../day_585__not_matching_S3_histories.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/devblog/day_585__not_matching_S3_histories.mdwn diff --git a/doc/devblog/day_585__not_matching_S3_histories.mdwn b/doc/devblog/day_585__not_matching_S3_histories.mdwn new file mode 100644 index 0000000000..b025257f71 --- /dev/null +++ b/doc/devblog/day_585__not_matching_S3_histories.mdwn @@ -0,0 +1,16 @@ +I could not find a good solution to the S3 history matching problem, so I +think that was the wrong approach. Now I have what seems to be a better +approach implemented: When an import of history from S3 contains some trees +that differ from the trees that were exported to S3, all git-annex needs to +do is make git aware of that, and it can do so by making the remote +tracking branch contain a merge between what was exported to S3 and what +was imported from it. + +That does mean that there can be some extra commits generated form an +import, with the same trees as commits that the user made, but a different +message. That seems acceptable. Less so is that repeated imports generate +different commits each time; I need to make it generate stable commits. I +should also add back detection of the simple fast-forward case which was +working but got broken today. + +So still not done with this, but the end is in sight!