[Kde-scm-interest] Post-commit hooks script
Johannes Sixt
j.sixt at viscovery.net
Fri Dec 4 08:23:39 CET 2009
Oswald Buddenhagen schrieb:
> On Thu, Dec 03, 2009 at 01:30:07PM -0600, Ian Monroe wrote:
>> On Thu, Dec 3, 2009 at 1:03 PM, Oswald Buddenhagen <ossi at kde.org> wrote:
>>> however, as i'm trying to make it really smart (trying to
>>> reconstruct the real history from the push as far as possible), i'm
>>> faced with some "interesting" problems, so it's taking a while ...
>> Just work with one commit at-a-time, not sure it makes sense to
>> respond to the whole push as an entity.
>>
> well, that's exactly the problem. just commits (sha1s) make totally no
> sense to a human, so they must be ascribed to particular branches. and
> figuring that out when multiple branches are pushed at once is an
> interesting discourse in graph theory when you consider that refs may be
> aliases to (parts of) each other and can have branches and merges on the
> way. this is admittedly a corner case, but it might become interesting
> when something is "imported" which had extended life outside the main
> repository. the simple case of a multi-branch push would be a fix in a
> stable branch and an immediate forward-merge to master (of course this
> has no chance to work in a highly contented monster repo, but is
> realistic for smaller repos).
Since you are using post-receive, you can use this strategy:
You read all "old new ref" from stdin.
You collect all "old".
When you now iterate over all "new ref" pairs, this:
git rev-list $new --not $all_old
tells you which of the pushed commits belong to the $new ref.
If you furthermore iterate over the refs in "logical" order (4.3.0 4.3.1
4.4.0 ... master), you can add $new to $all_old, then in the next
iteration you will visit only commits that have not been attributed to an
earlier ref.
-- Hannes
More information about the Kde-scm-interest
mailing list