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

[Yotam Barnoy]

Why not just delete the separate files with each release?

> On Jan 25, 2017, at 9:39 AM, Gabriel Scherer <gabriel.scherer at gmail.com> wrote:
>
> 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
> _______________________________________________
> Infrastructure mailing list
> Infrastructure at lists.ocaml.org
> http://lists.ocaml.org/listinfo/infrastructure