summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-07-10 15:37:29 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-07-10 15:37:29 -0400
commitc38dd9adc844688fb7ebdc8f41db16cf52de0939 (patch)
treef7f9fd48a47ccd36afde46b92e3f881f9ee96c6a /doc/bugs
parent7919de73af81d1788867ecbcbcc17e25b348ad1d (diff)
analysis
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/making_annex-merge_try_a_fast-forward.mdwn26
1 files changed, 26 insertions, 0 deletions
diff --git a/doc/bugs/making_annex-merge_try_a_fast-forward.mdwn b/doc/bugs/making_annex-merge_try_a_fast-forward.mdwn
index 532e771bd..a2bd8c747 100644
--- a/doc/bugs/making_annex-merge_try_a_fast-forward.mdwn
+++ b/doc/bugs/making_annex-merge_try_a_fast-forward.mdwn
@@ -1,3 +1,29 @@
While merging the git-annex branch, annex-merge does not end up in a fast-forward even when it would be possible.
But as sometimes annex-merge takes time, it would probably be worth it
(but maybe I miss something with my workflow...).
+
+> I don't think a fast-forward will make things much faster.
+>
+> git-annex needs its index file to be updated to reflect the merge.
+> With the union merge it does now, this can be accomplished by using
+> `git-diff-index` to efficiently get a list of files that have changed,
+> and only merge those changes into the index with `git-update-index`.
+> Then the index gets committed, generating the merge.
+>
+> To fast-forward, it would just reset the git-annex branch to the new
+> head of the remote it's merging to. But then the index needs to be
+> updated to reflect this new head too. To do that needs the same method
+> described above, essentially (with the difference that it can replace
+> files in the index with the version from the git-annex branch, rather
+> than merging in the changes... but only if the index is known to be
+> already committed and have no other changes, which would require both
+> an attempt to commit it first, and
+> locking).
+>
+> So will take basically the same amount of time, except
+> it would not need to commit the index at the end of the merge. The
+> most expensive work is the `git-diff-index` and `git-update-index`,
+> which are not avoided.
+>
+> Although, perhaps fast-forward merge would use slightly
+> less space. --[[Joey]]