[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Merging in Irmin

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.