[Libreoffice] git submodule

Miklos Vajna vmiklos at frugalware.org
Mon Feb 7 14:31:31 PST 2011


On Mon, Feb 07, 2011 at 10:33:00PM +0100, Miklos Vajna <vmiklos at frugalware.org> wrote:
> Automatic git commit --amend is really dangerous, I would not do it.
> It's not an accident non-fastforwards are rejected while pushing.

It turns out I misunderstood it, I thought this is about git commit
--amend in the repos, not in githeads.git.

So here is what we discussed on IRC:

The problem of "a logical commit may affect multiple repos and you don't
want to bisect a state when such a multi-repo change is not fully
applied" is similar to the one the cvs2<something more modern>
converters do, where cvs does not handle multi-file commits.

That means in case one uses the same commit message for commits in
different repos, we can assume it does not make sense to try to build
when not all affected repos are updated.

As a consequence, a post-receive git hook could be written, which would
be executed on the freedesktop servers, which would do the followings:

for i in repos:
        for j in commits:
                update_githeads_txt()
                if (j.author, j.commitmsg) in githeads:
                        # the same author already pushed something with
                        # the same commit message to an other repo
                        git commit --amend githeads.txt
                else:
                        # something new
                        git commit githeads.txt

In reality 'g push' executes git push for each affected repo, so the
hook in fact would do the inner cycle only.

Also, we could add one more constraint: when we use --amend, the
timestamp of the "old commit" should not differ too much (say, 5
minutes) from the "new commit".

The format of githeads.txt could be still what tinbuild has, we can get
other properties of the commits anytime from the repos based on the
sha1.

Does this sound reasonable? That way we would have a githeads.git that
could be used for bisecting (the 'g bisect' part if of course missing,
but possible to implement - that would update the state of the repos
based on githeads.txt) and it would be quite small.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110207/f0763535/attachment-0001.pgp>


More information about the LibreOffice mailing list