Re: git with custom diff for commits

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> I wouldn't do filters for something like that.  Can you guarantee that
>> the output from corresopnding smudge filter will load cleanly back to
>> the mysql database?
>
> The original poster said the date was an SQL comment, so, it should be
> safe to strip it. That said, precommit hook is probably a good or
> better solution. At least, if you're not sure you didn't make a
> mistake writting it, you'll notice either a good commit or no commit
> at all. With filters, you might well notice you corrupted the commit
> too late :-(.

Yeah.  After writing the message you are responding to, I realized that
I already do something like that to manage html/man branches that are
autogenerated, and it is exactly the same situation as Gerald is in.

The autogeneration of documentation and updating of html/man branches is
controlled by dodoc.sh script in 'todo' branch, installed as post-update
hook in my public repository.  It builds the documentation in a checkout
of 'master' branch, installs the result into another checkout of 'html'
and 'man' branches, and commits.

The twist is in the "install" step (this is different from my suggestion
of preventing the commit in pre-commit hook).  When the newly generated
documentation files are different from the previously generated ones
only by datestamp, they are not installed into 'html'/'man' checkouts,
and such a change is not included in the commits.

So my updated suggestion would be:

 - Keep a checkout of that mysql dump;

 - Make the dump procedure to dump to that checkout area;

 - Run "git diff HEAD", perhaps with the external diff that filters out
   the cruft as suggested in the thread, and run "git checkout $path"
   for paths that had only meaningless changes;

 - Run "git commit" if the above step did not nuke all changes.