Re: Sample pre-push hook can crash

Stephen Morton <stephen.c.morton@gmail.com> writes:

If you were up-to-date from the other side once:

    ---A---B---C

and built one new commit on top:

    ---A---B---C---D

when you attempt to push it out, there are various possibilities.

An ff situation is simple. They didn't do anything, so the hook gets "we'd be updating their ref from C to D", and "rev-list C..D" would tell you that you would need to make sure D is sane.

If your push does not fast-forward, that would mean something has happened on the other side while you were working on D. Perhaps they accepted another commit that you haven't seen:

    ---A---B---C---E

and because you haven't fetched from them, even though the hook may say "we'd be updating their ref from E to D", you haven't heard of E, you do not know where it would be relative to the history you have:

                  E???

    ---A---B---C---D

Or perhaps they themselves rewound their history and they now have this E at the tip:

    ---A---B---C
            \
             E

But again, because you do not yet know where E is relative to your history, you cannot say C is where you can stop checking your side of the history.

Or perhaps they somehow obtained your D without you pushing into them (e.g. you pushed to the "next" tree and they fixed your commit and the result was merged there) and have something like this:

    ---A---B---C---D---E

In this case, D is not even a new commit from their point of view, and updating their tip E with your old D would lose the fixup E they made for D, but again, you do not know what E is yet, you cannot say "they have this already, so there is no check I need to do".

In summary, you cannot even say which ones you have need to be checked.

If you _are_ using @{u} tracking, then you would know at least they used to have up to C in their repository to limit your check, but you cannot unconditionally say ref@{u}.. without making sure ref@{u} makes sense in the first place.

An obvious alternative for the sample script would be to instead let the non-ff push pass the pre-push check (as you may have other arrangements to forbid non-ff pushes) without actually checking anything. As this sample script is to serve as a sample, I think such an advanced consideration of loosening checks depending on the situation should be left to the end users.