Re: [MirageOS-devel] Merging in Irmin

[Thomas Leonard <talex5@xxxxxxxxx>]

On 7 April 2015 at 14:19, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>> I'm not sure how to use this. It looks like parents is only used in
>> merge_path. How do I use it with update_path?
>>
>> Ideally, I think I want something like:
>>
>>  BC.make_head :
>>    Irmin.config -> ('a -> Irmin.task) -> parents:head list ->
>>    msg:'a -> View.t -> ('a -> t) Lwt.t
>>
>> to implement CueKeeper's API:
>>
>>  module Commit : sig
>>    type t
>>    val commit :
>>      parents:t list ->
>>      Staging.t ->
>>      msg:string ->
>>      t Lwt.t
>>
>> How can I take two commits, generate a view (manually) with the
>> results of my custom merge, and then add the result as a new commit
>> with both of the original parents?
>
> Something like:
>
> let commit ~parents staging ~msg =
>       match staging.Staging.commit with
>       | None -> assert false
>       | Some t ->
>       I.of_head t.c_repo.config t.c_repo.task_maker (id t) >>= fun tmp_branch 
> ->
>       (* THE ONLY CHANGE *) V.set_parents Staging.view parents;
>       V.update_path (tmp_branch msg) I.Key.empty staging.Staging.view >|= fun 
> () ->
>       {t with c_store = tmp_branch}

It doesn't seem to work. I tested with this code (on my "test_merging" branch):

https://github.com/talex5/cuekeeper/commit/4da442f91422bd6b8654922ca6955cf78cd9d83d

        Git.Commit.checkout base >>= fun stage ->
        Git.Staging.update stage ["foo"] "a" >>= fun () ->
        Git.Commit.commit ~parents:[base] ~msg:"A" stage >>= fun a ->
        Git.Staging.update stage ["foo"] "b" >>= fun () ->
        Git.Commit.commit ~parents:[base] ~msg:"B" stage >>= fun b ->
        Git.Staging.update stage ["foo"] "merged" >>= fun () ->
        Git.Commit.commit ~parents:[a; b] ~msg:"Merge" stage >>= fun result ->
        Git.Branch.fast_forward_to master result >>= function

For testing, it uses the Git backend with the directory "test_db".
Looking at the result with gitk, I have an initial commit containing
"orig" with a direct child "Merge" containing "merged".

[ I also had to expose "VIEW.head = S.head" in Irmin:
https://github.com/talex5/irmin/commit/d77f81c0786860a58a8a596bca8426d1e1f98661
and I modified your code slightly to make "parents" optional and to be
a Commit.t, but that shouldn't make any difference I think. ]

> I'll see if I can add your `make_head` function.
>
> Thomas
>
>>
>>>> Currently, I merge to create a new commit, test it, and then do a
>>>> fast-forward to update the branch to include the merge if the test
>>>> passes. But if I can use custom merge code, then it would be OK to
>>>> merge directly to the branch when my merge code returns, since it will
>>>> already have had a chance to test it.
>>>
>>> In the PR, I've also added `Irmin.fast_forward_head` (maybe it should be 
>>> `fast_forward_to_head`?) to to that. It returns "false" (and does nothing) 
>>> it the new head is not strictly in the future of the current head.
>>
>> Thanks! [ As noted elsewhere, it would be useful to distinguish the
>> case where it's already up-to-date (success; no futher action needed)
>> from the case where it's not an ancestor (failure; retry merge with
>> new head). ]
>>
>>> Let me know if you need something else (I'm still working on the right way 
>>> to fix the watch API).
>>>
>>> Best,
>>> Thomas
>>>
>>
>>
>>
>> --
>> Dr Thomas Leonard        http://0install.net/
>> GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
>> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA
>



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel