Because Reason is just a syntax layer over the OCaml syntax, you should write an MirageOS unikernel with Reason. However, because MirageOS needs lot of works, lot of people of this community don't have a plan to switch to Reason - but feel free :) !

After, it's about a convenience easy way to compile your Reason code with an OCaml code. Reason is just a preprocessing, you should use the `-pp` option with /your favorite build system in OCaml/ and, I think, it's enough.

I won't be switching to Reason, it's a small greenfield project :) The security model of Mirage will really suit this small app and Reason has piqued my interest for being a little more productive with dev tools and stuff. Also being able to build a frontend in the same language is appealing.

Thanks for the answer; the other comment alluding to support being recent and the lack of information had me a bit worried. I guess the lack of information is because it just works ;)

But if you are a better opinion about the implementation of Git in OCaml, you can comment my PR. Then, we can talk technically about your point :) !

I'm not saying that your implementation of Git is bad. I didn't look at your code at all; it could be perfect, for all I know.

What I'm saying is you are not using git effectively. It is much easier to read and understand merge requests the smaller they are. Someone who didn't write the code should be able to go through your merge request in one sitting and understand all of its implications.

You may have written a good "implementation of Git," but you have also demonstrated that you don't know how to use it effectively.

> It is much easier to read and understand merge requests the smaller they are.

I'm always amused by people telling others what is more readable and understandable as if it was a hard fact and applied universally to all situations.

In reality, you can have a +19k diff which is easier to understand than a +100/-100 diff, and it happens quite often. Have you ever read a PR and clicked the "view" button to see the whole file? Have you ever clicked on the arrows to expand the context of a particular diff line to learn what the heck a given name is? Consider that you wouldn't have to do this if it was all in the diff in the first place.

The readability of the code is an elusive quality, with largely inconclusive research. There's very little in terms of facts to rely on. The best you can say is that a particular way of presenting the code, or changes, feels better to you. Good for you, but don't try to force that way on others, as you're guaranteed not to improve the readability and instead encounter a violent pushback.

Your personal preference for how a tool should be used is not the same as using the tool effectively. Pull requests aren't even an inherent part of the Git workflow, and not all projects prefer short-lived topic branches.

From the OP's other comment, it sounds like this merge strategy was the preference of the repository owner. Why substitute your own preferences for theirs?

ETA: Also note that the PR was reviewed several times over the summer. GitHub has a feature that allows you to only review changes to a PR since the last time you reviewed. You can also manually use `git diff` to review that difference.

What you are saying is bullshit, OP clearly explained the situation. You just had no idea about the constraint he was facing, but even after he gave you a detailed answer you still not bother.

OP of this PR here. When Thomas Gazagnaire started ocaml-git, it's like a PoC for Irmin and a MirageOS system. He did not think about the memory consumption of an implementation of any Git operation for example.

In this case, he saw a limitation about the Garbage Collector of git (which can use a lot of your memory) and the push command. It's like just: "I want to understand what is Git (in the specification) and I will do". So, the big goal of my work (payed by the MirageOS team) was to switch to a non-blocking (memory predicted) implementation of Git.

I did not have any criticism about this approach. Sometimes you just want a project to work and ocaml-git was developed in this mind.

However, ocaml-git is used now by some big companies (like Docker, Tezos, etc.) and need a strong prediction about the memory consumption first. Then, the push command is a big lack of the last implementation. And, finally, the GC and encoding of the PACK file is the key to solve all of these problems.

As I said in this PR, I worked with Thomas Gazagnaire and some others peoples of the MirageOS eco-system to improve ocaml-git, implemented the Git GC, Git push and tried to avoid any problem about the memory consumption in a server context in the low-level API.

So, yeah, it's a +19k -8k PR, of course. But it's not like a OCaml's noob and tries to restart the world like: yeah, I recoded Git in OCaml in my only opinion and don't care about what was it happens in the OCaml world, Haskell world and industrial world, like just for fun.

In this PR, I explained IRL and in comments what happens. Why I did this choice compared to something else. The point of Thomas Gazagnaire (who reviewed my PR) and my point. What the MirageOS team expect and what I did.

So, clearly, yeah you did not read my comments and just see a big PR like a noob to try to strike all of this project but this is not what happened unfortunately for you. It's a result of a big discussion between Thomas Gazagnaire (specifically), others peoples and me to find the best for all (in the implementation and in the API).

Now, I can say this PR will be merge. I need to polish some details, improve the API and test it. So, yeah this big PR will be merge because it's what expect the creator of ocaml-git, what expect the MirageOS team, what expect my boss and what expect others users of this library if you just interest by the issues.