[Bf-committers] Helper git hooks

[Julien RIVAUD (_FrnchFrgg_)]

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.

> For now i think it's fine to have liberal script which says "hey, you're
> about to do something which is not considered safe and you need to be 100%
> sure you want to do this" to avoid accidents. And don't force everyone to
> use it.

Fair enough.

> Maybe if it'll become really an issue we make it more strict in the future,
> but atm don't think we really need them. Changed hash is not so bad, it's
> only bad when you change hash to a local submodule commit which is not in
> the repo. Perhaps for this we indeed need some server-side hooks which will
> reject any change which tries to screw up the repo.

Sure, esp. since that probably won't ever be a valid use-case anyway.

> 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).

_FrnchFrgg_