Re: [boost] date_time -> serialization (Was: spirtit -> serialization)

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-06-17 05:26:44

Andrey Semashev wrote:

> On Tuesday 17 June 2014 01:45:29 Julian Gonggrijp wrote:
> 
>> A commit hook is provided that
>> module maintainers can opt to add to their module configuration to
>> have it generated automatically (this won't affect history or be slow;
>> see below).
> 
> I see two potential problems with git hooks.

Thank you for taking the effort to figure this out with me. :-)

> 
> 1. As I understand, the hooks won't work with merging pull requests, unless 
> merged manually, on the developer's machine with the hook installed.

That's something I would have to look into. In principle the hook isn't 
necessary on a merge because the automated merge will take care of 
updates, but it might occasionally expose merge conflicts in the cache 
file to maintainers (although in that case there should always be a 
matching header file conflict). There might or might not exist such a 
thing as a merge conflict hook. Either way, it doesn't really matter 
anymore because you have convinced me that hooks at the module level 
are not the way to go.

> 2. AFAIK, the hooks need to be set up by developers on every local copy of the 
> git repository. It is possible that someone performs a commit without running 
> the hook (maybe not intentionally), leaving the cache outdated.

Yes. At first I thought this wouldn't be an issue, but I now realise it 
is.

> [...]
> 
>>> [...]
>>> 
>>> Another alternative is to create a new git submodule to store the cache
>>> in.
>> 
>> I think that would be a bad idea. The cache should be directly coupled
>> to the commit. We must avoid rolling our own datastructures just to
>> match the right cache to the right commit.
> 
> There is a way to associate it with the commit - if the cache is stored in the 
> superproject and generated when the superproject is updated to refer to the 
> new commit in the submodule. The updated metadata can be committed in the same 
> commit as the reference update.

I think this might be the best idea. It would be reasonably simple to 
implement and it covers most cases. Only if maintainers want to do 
custom checkouts on somebody else's module they'll have to use the 
"blind" fallback, but I guess that's acceptable.

Note that this would still require hooks, but only for the superproject 
maintainers.

-Julian