Stephen Morton <stephen.c.morton@xxxxxxxxx> writes:
> That is interesting, so in the case of a non-ff push, there is no way
> for a pre-push hook to know what is being pushed in order to run?
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html