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

[Yotam Barnoy]

The fragments exist in full in git history before every release. I see
no reason to try to save them.

On Wed, Jan 25, 2017 at 10:04 AM, David Allsopp <dra-news at metastack.com> wrote:
> Indeed - git submodules are almost entirely inappropriate to every use-case. Their only use is to have parts of the tree which do not have to be initialised.
>
> There can be surprising results - however, the submodule itself is only updated by a script (see tools/changes.sh) and if one happens to be traversing entire versions of the ocaml tree, failing to run git submodule update is not going to break anything, unless you choose for some reason to run make FullChanges.
>
>
> David
>
>> -----Original Message-----
>> From: Infrastructure [mailto:infrastructure-bounces at lists.ocaml.org] On
>> Behalf Of Gabriel Scherer
>> Sent: 25 January 2017 14:38
>> To: Anil Madhavapeddy <anil at recoil.org>
>> Cc: infrastructure <infrastructure at lists.ocaml.org>
>> Subject: Re: [ocaml-infra] New Git repository in ocaml GitHub org
>>
>> 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
> _______________________________________________
> Infrastructure mailing list
> Infrastructure at lists.ocaml.org
> http://lists.ocaml.org/listinfo/infrastructure