[ocaml-infra] New Git repository in ocaml GitHub org

Gabriel Scherer gabriel.scherer at gmail.com
Wed Jan 25 14:38:20 GMT 2017


The git sub-module is an optimization. The change that is being
discussed is to each changelog entry in a separate file, to reduce
Changes-related merge conflicts. David wrote a script to rebuild a
complete Changelog from an exploded representation (sections are
directories, entries are files).

Several developers have argued that keeping too many small files in
the repository could make it inconvenient to work with on some
OS/filesystem combinations (mostly Windows, I suppose). There can be
several hundred entries per release, so it is not an unreasonable
concern I think.
David's idea is to only keep the small files in the main repository
for the in-development versions, and at release time move them to a
separate repository, so that they are not pulled in by default.
Ideally we want each commit in the main repository to point to a
specific commit in the Changes-repository (the commit of the last
release-time move), so using a submodule makes more sense than a
separate branch -- with a separate branch there would be no link
between the versions in the two branches.

I agree that in general submodules can be a pain to use, but in this
specific case I think that this is not likely to be an issue: most
people would never need to pull the submodule or update it in any way,
it would only need to be manipulated at release time (pull, copy
files, commit, and that's it), which occurs infrequently.

On Wed, Jan 25, 2017 at 3:30 PM, Anil Madhavapeddy <anil at recoil.org> wrote:
> On 25 Jan 2017, at 14:22, Daniel Bünzli <daniel.buenzli at erratique.ch> wrote:
>>
>> On Wednesday, 25 January 2017 at 14:45, David Allsopp wrote:
>>> It is desirable to keep the fragment files, but these add considerable
>>> weight to the main repository (and OCaml sources tarball). I have proposed
>>> in the solution using a Git submodule to store the archived entries.
>>
>> Are you sure about this ? It seems to me that git should be able to handle this without too much problem and it should be easy enough not to include them in the release tarball. I personally had a terrible experience with git submodules (though that was a long time ago) and I wouldn't advise anyone to get into this mess.
>
> Git submodules are indeed surprisingly difficult to use reliably.
> Would storing the fragments in an independent branch be workable?
> Those objects would not add more weight to a checkout of OCaml
> trunk, but still be accessible a checkout away.
>
> (Caveat: I haven't reviewed the rest of your proposal in detail, David,
>  so apologies if this is well-trodden ground).
>
> Anil
> _______________________________________________
> Infrastructure mailing list
> Infrastructure at lists.ocaml.org
> http://lists.ocaml.org/listinfo/infrastructure


More information about the Infrastructure mailing list