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 <o...@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 _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
