Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Oh, and because it's relevant for the question: There's a tool in the tree (https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f...) that shows (by heuristics) which branches a commit has been cherry-picked to. Looks like this:

    Author: Tom Lane <[email protected]>
    Branch: master [9d4ca0131] 2017-01-26 12:18:07 -0500
    Branch: REL9_6_STABLE [2dfc12647] 2017-01-26 12:17:47 -0500
    Branch: REL9_5_STABLE [423ad86f4] 2017-01-26 12:17:47 -0500
    Branch: REL9_4_STABLE [2c1976a6c] 2017-01-26 12:17:47 -0500
    Branch: REL9_3_STABLE [2e024f83b] 2017-01-26 12:17:47 -0500
    Branch: REL9_2_STABLE [fe6120f9b] 2017-01-26 12:17:47 -0500
    
        Ensure that a tsquery like '!foo' matches empty tsvectors.
        
        !foo means "the tsvector does not contain foo", and therefore it should
        match an empty tsvector.  ts_match_vq() overenthusiastically supposed
        that an empty tsvector could never match any query, so it forcibly
        returned FALSE, the wrong answer.  Remove the premature optimization.
        
        Our behavior on this point was inconsistent, because while seqscans and
        GIST index searches both failed to match empty tsvectors, GIN index
        searches would find them, since GIN scans don't rely on ts_match_vq().
        That makes this certainly a bug, not a debatable definition disagreement,
        so back-patch to all supported branches.
        
        Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me.
        
        Discussion: https://postgr.es/m/[email protected]

Edit: fighting with formatting #2


git patch-id is not bad for this:

Here are the four commits with "Fix roundoff problems in float8_timestamptz() and make_interval()" as their commit message:

  $ git log --pretty="%h - %d" --date-order --all --grep=float8_time 
  1888fad440 -  (origin/REL9_4_STABLE)
  7786b98482 -  (origin/REL9_5_STABLE)
  404756fe89 -  (origin/REL9_6_STABLE)
  8f93bd8512 - 
And here's what "git patch-id" thinks of them:

  $ git log -p --date-order --all --grep=float8_time | git patch-id
  cd559dd389e09655a64c3c6f41c2f76e6fd72b77 1888fad440036195c7e7a933fc17410fad8dcc3d
  cd559dd389e09655a64c3c6f41c2f76e6fd72b77 7786b984825ea720aed3a11ee465dc3d6cfc8d96
  63a51849977948d89992cbfbbd86c2598c92072f 404756fe89f62735f6075abb594b54be9c262b27
  63a51849977948d89992cbfbbd86c2598c92072f 8f93bd8512466c9b6c4dbc1e5efd0f72b8e2be9a
It can tell that the 9.4 and 9.5 patches are identical to each other, and that the 9.6 and master patches are also identical to each other. But there were differences between the two groups.


This is fairly easy to do, if you enforce a policy of requiring cherry-picks to reference the original commit (i.e. requiring -x in the git cherry-pick command).

You can the grep the log for all the commits which contain the commit ID you are interested in (and any that mention those commits).


That's not always that helpful, because you often will want to cherry-pick from another branch than master. E.g. when cherry-picking a change from master into 9.6, 9.5, 9.4, 9.3, 9.2 it'll e.g. often be easier to cherry-pick from 9.3 into 9.2, rather than master into 9.2 (due to conflicts increasing the further back you go). Obviously you could do that manually or script it regardless. But the current heuristics have worked without problems for years, so there seems little reason to change things ;)




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: