Merged repo for protocol headers? Why are they split?

[Peter Hutterer]

On Mon, Nov 27, 2017 at 09:07:12PM +0100, Daniel Martin wrote:
> On 22 November 2017 at 07:45, Adam Jackson <ajax at nwnk.net> wrote:
> > On Wed, 2017-11-22 at 10:25 +1000, Peter Hutterer wrote:
> >> On Tue, Nov 21, 2017 at 03:28:20PM -0800, Dylan Baker wrote:
> >> > Your script splits each proto into a subdirectory, does it really make sense to
> >> > do that, or should the final proto package have everything together in the root?
> >>
> >> please no! if you merge all repos the history will be messy. With subdirectories
> >> at least you get a nice git log for each individual repo if you specify the
> >> directory name.
> >
> > Agreed, that'd be a useful property to preserve given how random the
> > repo and file names are.
> 
> Just started to test an idea today, to get an even better history. The
> idea is basically (omitting details):
> 1. format-patch each commit into a patch, the filename includes the
> commit time (UTC)
>    - patches of all repos become sorted and when applying them we get
> a nice history
> 2. hammer with sed on the patches
>    - add a proto prefix to the subject
>    - change initial position of files (i.e. move headers into
> include/X11/..., txts into doc/), no need to move files later

if there are any commit messages that reference others ("Reverts commit
abcd123") you lose the reference because the sha is now different. so I'd
rather not do a re-commit of everything.
 
> Surprisingly, this works pretty good for the first commits (reduced
> testing surface for the beginning). Last stop was at renames of files.
> But, I got another idea, which I can test tomorrow.
> 
> The merge into subdirs looks straight forward and we can do that if I
> find a show-stopper. Deal?

have you looked at subtree merges? Keeps the repo history for each merged
repository and the one from the top-level repository. And it forces you to
merge into a directory anyway, so that's a win right there.

Cheers,
   Peter