Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

src

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Tom Lane authored
    Many committers seem to now be using a work flow in which back-patched
    commits are timestamped minutes or even hours apart in different branches
    (most likely because they commit in one branch before starting work on
    the next one).  git_changelog was failing to merge its reports in such
    cases, so increase the max time it's willing to merge commits across.
    I considered getting rid of the limit altogether, but that produces
    some odd results in terms of how the merged commit gets sorted relative
    to unrelated commits.
    7a1e34d3
    History
    Name Last commit Last update
    ..