mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

merge: Use fast-forward merges when possible.

Browse source 
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.

While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.

It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.

Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.

The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.

Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
This commit is contained in:
Joey Hess 2011-11-06 15:18:45 -04:00
parent bf07e2c921
commit c99fb58909
3 changed files with 79 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

6
doc/bugs/making_annex-merge_try_a_fast-forward.mdwn
View file

@ -27,3 +27,9 @@ But as sometimes annex-merge takes time, it would probably be worth it
>
> Although, perhaps fast-forward merge would use slightly
> less space. --[[Joey]]
>> To avoid the ladder-merge between two repositories described at
>> <http://sprunge.us/LOMU>, seems a fast-forward should be detected and
>> written to git, even if the index is still updated the current way.
>> [[done]]
>> --[[Joey]]