On Mon, Feb 07, 2011 at 10:33:00PM +0100, Miklos Vajna <vmiklos@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.
Attachment:
pgpv27MD7xXh9.pgp
Description: PGP signature