Re: [MirageOS-devel] Merging in Irmin

[Thomas Leonard <talex5@xxxxxxxxx>]

On 30 March 2015 at 17:49, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>>> Not sure how to expose that nicely to the user though... maybe allowing to 
>>>> specify a "parent" optional argument to merge/update/rebase.
>>
>> That would be useful. I've been avoiding the "Private" API so far, but
>> maybe I should start using it.
>
> I've just open a new PR to fix that: https://github.com/mirage/irmin/pull/178
>
> I've exposed `View.parents` and `View.set_parents` to do that. I'm not very 
> happy with that API: on one hand, it would be much better to have immutable 
> views (and have `with_parents` to modify the parents), but on the other hand, 
> the current APIs is nice because it is a subset of Irmin.S so I kept exposing 
> the side-effects...

>>> You can only create a view from one store and apply it in the other: the 
>>> history of commit will be kept as expected. See:
>>>
>>> https://github.com/samoht/dog/blob/master/lib/dog.ml#L247
>>>
>>> You can try to use that to merge views from different branches, not sure 
>>> how practical this is though.
>>
>> The basic logic I have is roughly:
>>
>> 1. git checkout base
>> 2. (apply modification)
>> 3. UPDATE=$(git commit-tree -p base)
>> 4. git checkout master
>> 5. git-merge -s custom $UPDATE
>>
>> Where "custom" should be my app-specific merge logic that works on
>> whole trees rather than individual files.
>
> So now you should be able to create a view, do some stuff on it, give it the 
> parents you need and save it.

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?

>> 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

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