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

[David Allsopp]

Thomas Leonard wrote:
> On 25 January 2017 at 13:45, David Allsopp <dra-news at metastack.com> wrote:
> > I'm hoping to merge OCaml GPR#1014
> > (https://github.com/ocaml/ocaml/pull/1014) in advance of the OCaml
> > 4.05 code freeze. The principal aim of this GPR is to stop the Changes
> > file being a constant source of merge conflicts on open pull requests.
> > This is fixed by splitting the Changes file into individual entries
> > which are recombined using a script. At each release, the individual
> > files are merged into Changes and the new Changes file committed in
> > one go (for convenience, in a manner not unrelated to having both
> > configure.ac and configure in a repository).
> >
> > 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. The submodule is at present at
> > https://github.com/dra27/ocaml-changelog and I would like to move this
> > repository to the ocaml namespace. It would be sensible for the
> > repository not to accept pull requests or issues via the GUI and,
> > unless others are keen to be able to perform the OCaml release
> > manager's job, only I (at least for the initial commits) and Damien
> Doligez definitely need push access to it.
> 
> Why do the fragments need to be kept anywhere?

The question as to why one might keep an output document but not the input sources which generated it I must confess has surprised me, but you live and learn. The fragments obviously form a very primitive database - at the moment the only information contained in that tree which is lost is its structure, but we don't do anything with that, so it's largely moot. 

> If you can explode a changes file

I can explode a Changes file now. If something were to be changed in the future, then that would require updating both the script which explodes the Changes and the script which recombines the fragments (to add new files). For me, I'd keep the fragments somewhere and not worry about having to explode a Changes file again, as that feels like more work. 

> then you could presumably just configure your Git merge
> driver to do the `merge (explode ours) (explode theirs)` step
> automatically.

This isn't what's happening - "theirs" is fragment files.

> Looks like there's already one for GNU style ChangeLog files, e.g.

Would be fine if we had a GMU style ChangeLog! :o)


David