c99fb58909
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.)
35 lines
1.7 KiB
Markdown
35 lines
1.7 KiB
Markdown
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]]
|
|
|
|
>> 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]]
|