[Bf-committers] Helper git hooks

[Sergey Sharybin]

On Wed, Nov 27, 2013 at 2:50 AM, Julien RIVAUD (_FrnchFrgg_) <
frnchfrgg at free.fr> wrote:

> Le 26/11/2013 18:46, Sergey Sharybin a écrit :
> > Well, it's not just arc. It's also bugs in git which lead to such an
> > issues. With current arc from git it should no longer happen. But
> there're
> > still loads of ways to screw up things even without arc.
>
> The problem with current git is at commit time (in fact at staging time)
> because the add doesn't ignore the gitlink (the way a submodule SHA1 is
> stored in the superproject) even though you asked git to (and then
> because "git status" ignores when it shouldn't you don't see it). When a
> commit is submodule-clean and ensured to be (because in maniphest when
> reviewing you see the equivalent of git show so you are certain it is
> clean), no operation can make it unclean without modifying the commit
> itself thus changing the SHA1. A git push won't ever do that, and as
> "arc land" is supposed to be an equivalent of "push" that shouldn't happen.
>

As i understood the situation, current arc from git repo should not stage
submodules. As for git, yes git only can do commit, then git show the
changes. But it's gonna to be fixed soon.

Or there're still some issues you see even when git is fixed?


> > And i'm not so much fussed if submodule hash changes if it doesn't break
> > repo consistency.
>
> But some of these changes can break buildbot it seems. Maybe you could
> also make buildbot robust against that (and ignore these hashes except
> for releases buiding).
>

Was thinking about this yes. But there's not much i can control. For sure i
can replace buildbot's git wrapper with custom commands and so.. But that'd
be extra hassle i'm afraid.

Especially since normal human beings will also have issues cloning the
repository with broken hashes.. Think it's more important to train self not
to screw up the repo rather than spending time on making buildbot robust.

-- 
With best regards, Sergey Sharybin