https://github.com/git/git
- v2.9.5
- v2.9.4
- v2.9.3
- v2.9.2
- v2.9.1
- v2.9.0-rc2
- v2.9.0-rc1
- v2.9.0-rc0
- v2.9.0
- v2.8.6
- v2.8.5
- v2.8.4
- v2.8.3
- v2.8.2
- v2.8.1
- v2.8.0-rc4
- v2.8.0-rc3
- v2.8.0-rc2
- v2.8.0-rc1
- v2.8.0-rc0
- v2.8.0
- v2.7.6
- v2.7.5
- v2.7.4
- v2.7.3
- v2.7.2
- v2.7.1
- v2.7.0-rc3
- v2.7.0-rc2
- v2.7.0-rc1
- v2.7.0-rc0
- v2.7.0
- v2.6.7
- v2.6.6
- v2.6.5
- v2.6.4
- v2.6.3
- v2.6.2
- v2.6.1
- v2.6.0-rc3
- v2.6.0-rc2
- v2.6.0-rc1
- v2.6.0-rc0
- v2.6.0
- v2.5.6
- v2.5.5
- v2.5.4
- v2.5.3
- v2.5.2
- v2.5.1
- v2.5.0-rc3
- v2.5.0-rc2
- v2.5.0-rc1
- v2.5.0-rc0
- v2.5.0
- v2.44.0-rc2
- v2.44.0-rc1
- v2.44.0-rc0
- v2.44.0
- v2.43.3
- v2.43.2
- v2.43.1
- v2.43.0-rc2
- v2.43.0-rc1
- v2.43.0-rc0
- v2.43.0
- v2.42.1
- v2.42.0-rc2
- v2.42.0-rc1
- v2.42.0-rc0
- v2.42.0
- v2.41.0-rc2
- v2.41.0-rc1
- v2.41.0-rc0
- v2.41.0
- v2.40.1
- v2.40.0-rc2
- v2.40.0-rc1
- v2.40.0-rc0
- v2.40.0
- v2.4.9
- v2.4.8
- v2.4.7
- v2.4.6
- v2.4.5
- v2.4.4
- v2.4.3
- v2.4.2
- v2.4.12
- v2.4.11
- v2.4.10
- v2.4.1
- v2.4.0-rc3
- v2.4.0-rc2
- v2.4.0-rc1
- v2.4.0-rc0
- v2.4.0
- v2.39.3
- v2.39.2
- v2.39.1
- v2.39.0-rc2
- v2.39.0-rc1
- v2.39.0-rc0
- v2.39.0
- v2.38.5
- v2.38.4
- v2.38.3
- v2.38.2
- v2.38.1
- v2.38.0-rc2
- v2.38.0-rc1
- v2.38.0-rc0
- v2.38.0
- v2.37.7
- v2.37.6
- v2.37.5
- v2.37.4
- v2.37.3
- v2.37.2
- v2.37.1
- v2.37.0-rc2
- v2.37.0-rc1
- v2.37.0-rc0
- v2.37.0
- v2.36.6
- v2.36.5
- v2.36.4
- v2.36.3
- v2.36.2
- v2.36.1
- v2.36.0-rc2
- v2.36.0-rc1
- v2.36.0-rc0
- v2.36.0
- v2.35.8
- v2.35.7
- v2.35.6
- v2.35.5
- v2.35.4
- v2.35.3
- v2.35.2
- v2.35.1
- v2.35.0-rc2
- v2.35.0-rc1
- v2.35.0-rc0
- v2.35.0
- v2.34.8
- v2.34.7
- v2.34.6
- v2.34.5
- v2.34.4
- v2.34.3
- v2.34.2
- v2.34.1
- v2.34.0-rc2
- v2.34.0-rc1
- v2.34.0-rc0
- v2.34.0
- v2.33.8
- v2.33.7
- v2.33.6
- v2.33.5
- v2.33.4
- v2.33.3
- v2.33.2
- v2.33.1
- v2.33.0-rc2
- v2.33.0-rc1
- v2.33.0-rc0
- v2.33.0
- v2.32.7
- v2.32.6
- v2.32.5
- v2.32.4
- v2.32.3
- v2.32.2
- v2.32.1
- v2.32.0-rc3
- v2.32.0-rc2
- v2.32.0-rc1
- v2.32.0-rc0
- v2.32.0
- v2.31.8
- v2.31.7
- v2.31.6
- v2.31.5
- v2.31.4
- v2.31.3
- v2.31.2
- v2.31.1
- v2.31.0-rc2
- v2.31.0-rc1
- v2.31.0-rc0
- v2.31.0
- v2.30.9
- v2.30.8
- v2.30.7
- v2.30.6
- v2.30.5
- v2.30.4
- v2.30.3
- v2.30.2
- v2.30.1
- v2.30.0-rc2
- v2.30.0-rc1
- v2.30.0-rc0
- v2.30.0
- v2.3.9
- v2.3.8
- v2.3.7
- v2.3.6
- v2.3.5
- v2.3.4
- v2.3.3
- v2.3.2
- v2.3.10
- v2.3.1
- v2.3.0-rc2
- v2.3.0-rc1
- v2.3.0-rc0
- v2.3.0
- v2.29.3
- v2.29.2
- v2.29.1
- v2.29.0-rc2
- v2.29.0-rc1
- v2.29.0-rc0
- v2.29.0
- v2.28.1
- v2.28.0-rc2
- v2.28.0-rc1
- v2.28.0-rc0
- v2.28.0
- v2.27.1
- v2.27.0-rc2
- v2.27.0-rc1
- v2.27.0-rc0
- v2.27.0
- v2.26.3
- v2.26.2
- v2.26.1
- v2.26.0-rc2
- v2.26.0-rc1
- v2.26.0-rc0
- v2.26.0
- v2.25.5
- v2.25.4
- v2.25.3
- v2.25.2
- v2.25.1
- v2.25.0-rc2
- v2.25.0-rc1
- v2.25.0-rc0
- v2.25.0
- v2.24.4
- v2.24.3
- v2.24.2
- v2.24.1
- v2.24.0-rc2
- v2.24.0-rc1
- v2.24.0-rc0
- v2.24.0
- v2.23.4
- v2.23.3
- v2.23.2
- v2.23.1
- v2.23.0-rc2
- v2.23.0-rc1
- v2.23.0-rc0
- v2.23.0
- v2.22.5
- v2.22.4
- v2.22.3
- v2.22.2
- v2.22.1
- v2.22.0-rc3
- v2.22.0-rc2
- v2.22.0-rc1
- v2.22.0-rc0
- v2.22.0
- v2.21.4
- v2.21.3
- v2.21.2
- v2.21.1
- v2.21.0-rc2
- v2.21.0-rc1
- v2.21.0-rc0
- v2.21.0
- v2.20.5
- v2.20.4
- v2.20.3
- v2.20.2
- v2.20.1
- v2.20.0-rc2
- v2.20.0-rc1
- v2.20.0-rc0
- v2.20.0
- v2.2.3
- v2.2.2
- v2.2.1
- v2.2.0-rc3
- v2.2.0-rc2
- v2.2.0-rc1
- v2.2.0-rc0
- v2.2.0
- v2.19.6
- v2.19.5
- v2.19.4
- v2.19.3
- v2.19.2
- v2.19.1
- v2.19.0-rc2
- v2.19.0-rc1
- v2.19.0-rc0
- v2.19.0
- v2.18.5
- v2.18.4
- v2.18.3
- v2.18.2
- v2.18.1
- v2.18.0-rc2
- v2.18.0-rc1
- v2.18.0-rc0
- v2.18.0
- v2.17.6
- v2.17.5
- v2.17.4
- v2.17.3
- v2.17.2
- v2.17.1
- v2.17.0-rc2
- v2.17.0-rc1
- v2.17.0-rc0
- v2.17.0
- v2.16.6
- v2.16.5
- v2.16.4
- v2.16.3
- v2.16.2
- v2.16.1
- v2.16.0-rc2
- v2.16.0-rc1
- v2.16.0-rc0
- v2.16.0
- v2.15.4
- v2.15.3
- v2.15.2
- v2.15.1
- v2.15.0-rc2
- v2.15.0-rc1
- v2.15.0-rc0
- v2.15.0
- v2.14.6
- v2.14.5
- v2.14.4
- v2.14.3
- v2.14.2
- v2.14.1
- v2.14.0-rc1
- v2.14.0-rc0
- v2.14.0
- v2.13.7
- v2.13.6
- v2.13.5
- v2.13.4
- v2.13.3
- v2.13.2
- v2.13.1
- v2.13.0-rc2
- v2.13.0-rc1
- v2.13.0-rc0
- v2.13.0
- v2.12.5
- v2.12.4
- v2.12.3
- v2.12.2
- v2.12.1
- v2.12.0-rc2
- v2.12.0-rc1
- v2.12.0-rc0
- v2.12.0
- v2.11.4
- v2.11.3
- v2.11.2
- v2.11.1
- v2.11.0-rc3
- v2.11.0-rc2
- v2.11.0-rc1
- v2.11.0-rc0
- v2.11.0
- v2.10.5
- v2.10.4
- v2.10.3
- v2.10.2
- v2.10.1
- v2.10.0-rc2
- v2.10.0-rc1
- v2.10.0-rc0
- v2.10.0
- v2.1.4
- v2.1.3
- v2.1.2
- v2.1.1
- v2.1.0-rc2
- v2.1.0-rc1
- v2.1.0-rc0
- v2.1.0
- v2.0.5
- v2.0.4
- v2.0.3
- v2.0.2
- v2.0.1
- v2.0.0-rc4
- v2.0.0-rc3
- v2.0.0-rc2
- v2.0.0-rc1
- v2.0.0-rc0
- v2.0.0
- v1.9.5
- v1.9.4
- v1.9.3
- v1.9.2
- v1.9.1
- v1.9.0-rc3
- v1.9.0
- v1.9-rc2
- v1.9-rc1
- v1.9-rc0
- v1.8.5.6
- v1.8.5.5
- v1.8.5.4
- v1.8.5.3
- v1.8.5.2
- v1.8.5.1
- v1.8.5-rc3
- v1.8.5-rc2
- v1.8.5-rc1
- v1.8.5-rc0
- v1.8.5
- v1.8.4.5
- v1.8.4.4
- v1.8.4.3
- v1.8.4.2
- v1.8.4.1
- v1.8.4-rc4
- v1.8.4-rc3
- v1.8.4-rc2
- v1.8.4-rc1
- v1.8.4-rc0
- v1.8.4
- v1.8.3.4
- v1.8.3.3
- v1.8.3.2
- v1.8.3.1
- v1.8.3-rc3
- v1.8.3-rc2
- v1.8.3-rc1
- v1.8.3-rc0
- v1.8.3
- v1.8.2.3
- v1.8.2.2
- v1.8.2.1
- v1.8.2-rc3
- v1.8.2-rc2
- v1.8.2-rc1
- v1.8.2-rc0
- v1.8.2
- v1.8.1.6
- v1.8.1.5
- v1.8.1.4
- v1.8.1.3
- v1.8.1.2
- v1.8.1.1
- v1.8.1-rc3
- v1.8.1-rc2
- v1.8.1-rc1
- v1.8.1-rc0
- v1.8.1
- v1.8.0.3
- v1.8.0.2
- v1.8.0.1
- v1.8.0-rc3
- v1.8.0-rc2
- v1.8.0-rc1
- v1.8.0-rc0
- v1.8.0
- v1.7.9.7
- v1.7.9.6
- v1.7.9.5
- v1.7.9.4
- v1.7.9.3
- v1.7.9.2
- v1.7.9.1
- v1.7.9-rc2
- v1.7.9-rc1
- v1.7.9-rc0
- v1.7.9
- v1.7.8.6
- v1.7.8.5
- v1.7.8.4
- v1.7.8.3
- v1.7.8.2
- v1.7.8.1
- v1.7.8-rc4
- v1.7.8-rc3
- v1.7.8-rc2
- v1.7.8-rc1
- v1.7.8-rc0
- v1.7.8
- v1.7.7.7
- v1.7.7.6
- v1.7.7.5
- v1.7.7.4
- v1.7.7.3
- v1.7.7.2
- v1.7.7.1
- v1.7.7-rc3
- v1.7.7-rc2
- v1.7.7-rc1
- v1.7.7-rc0
- v1.7.7
- v1.7.6.6
- v1.7.6.5
- v1.7.6.4
- v1.7.6.3
- v1.7.6.2
- v1.7.6.1
- v1.7.6-rc3
- v1.7.6-rc2
- v1.7.6-rc1
- v1.7.6-rc0
- v1.7.6
- v1.7.5.4
- v1.7.5.3
- v1.7.5.2
- v1.7.5.1
- v1.7.5-rc3
- v1.7.5-rc2
- v1.7.5-rc1
- v1.7.5-rc0
- v1.7.5
- v1.7.4.5
- v1.7.4.4
- v1.7.4.3
- v1.7.4.2
- v1.7.4.1
- v1.7.4-rc3
- v1.7.4-rc2
- v1.7.4-rc1
- v1.7.4-rc0
- v1.7.4
- v1.7.3.5
- v1.7.3.4
- v1.7.3.3
- v1.7.3.2
- v1.7.3.1
- v1.7.3-rc2
- v1.7.3-rc1
- v1.7.3-rc0
- v1.7.3
- v1.7.2.5
- v1.7.2.4
- v1.7.2.3
- v1.7.2.2
- v1.7.2.1
- v1.7.2-rc3
- v1.7.2-rc2
- v1.7.2-rc1
- v1.7.2-rc0
- v1.7.2
- v1.7.12.4
- v1.7.12.3
- v1.7.12.2
- v1.7.12.1
- v1.7.12-rc3
- v1.7.12-rc2
- v1.7.12-rc1
- v1.7.12-rc0
- v1.7.12
- v1.7.11.7
- v1.7.11.6
- v1.7.11.5
- v1.7.11.4
- v1.7.11.3
- v1.7.11.2
- v1.7.11.1
- v1.7.11-rc3
- v1.7.11-rc2
- v1.7.11-rc1
- v1.7.11-rc0
- v1.7.11
- v1.7.10.5
- v1.7.10.4
- v1.7.10.3
- v1.7.10.2
- v1.7.10.1
- v1.7.10-rc4
- v1.7.10-rc3
- v1.7.10-rc2
- v1.7.10-rc1
- v1.7.10-rc0
- v1.7.10
- v1.7.1.4
- v1.7.1.3
- v1.7.1.2
- v1.7.1.1
- v1.7.1-rc2
- v1.7.1-rc1
- v1.7.1-rc0
- v1.7.1
- v1.7.0.9
- v1.7.0.8
- v1.7.0.7
- v1.7.0.6
- v1.7.0.5
- v1.7.0.4
- v1.7.0.3
- v1.7.0.2
- v1.7.0.1
- v1.7.0-rc2
- v1.7.0-rc1
- v1.7.0-rc0
- v1.7.0
- v1.6.6.3
- v1.6.6.2
- v1.6.6.1
- v1.6.6-rc4
- v1.6.6-rc3
- v1.6.6-rc2
- v1.6.6-rc1
- v1.6.6-rc0
- v1.6.6
- v1.6.5.9
- v1.6.5.8
- v1.6.5.7
- v1.6.5.6
- v1.6.5.5
- v1.6.5.4
- v1.6.5.3
- v1.6.5.2
- v1.6.5.1
- v1.6.5-rc3
- v1.6.5-rc2
- v1.6.5-rc1
- v1.6.5-rc0
- v1.6.5
- v1.6.4.5
- v1.6.4.4
- v1.6.4.3
- v1.6.4.2
- v1.6.4.1
- v1.6.4-rc3
- v1.6.4-rc2
- v1.6.4-rc1
- v1.6.4-rc0
- v1.6.4
- v1.6.3.4
- v1.6.3.3
- v1.6.3.2
- v1.6.3.1
- v1.6.3-rc4
- v1.6.3-rc3
- v1.6.3-rc2
- v1.6.3-rc1
- v1.6.3-rc0
- v1.6.3
- v1.6.2.5
- v1.6.2.4
- v1.6.2.3
- v1.6.2.2
- v1.6.2.1
- v1.6.2-rc2
- v1.6.2-rc1
- v1.6.2-rc0
- v1.6.2
- v1.6.1.4
- v1.6.1.3
- v1.6.1.2
- v1.6.1.1
- v1.6.1-rc4
- v1.6.1-rc3
- v1.6.1-rc2
- v1.6.1-rc1
- v1.6.1
- v1.6.0.6
- v1.6.0.5
- v1.6.0.4
- v1.6.0.3
- v1.6.0.2
- v1.6.0.1
- v1.6.0-rc3
- v1.6.0-rc2
- v1.6.0-rc1
- v1.6.0-rc0
- v1.6.0
- v1.5.6.6
- v1.5.6.5
- v1.5.6.4
- v1.5.6.3
- v1.5.6.2
- v1.5.6.1
- v1.5.6-rc3
- v1.5.6-rc2
- v1.5.6-rc1
- v1.5.6-rc0
- v1.5.6
- v1.5.5.6
- v1.5.5.5
- v1.5.5.4
- v1.5.5.3
- v1.5.5.2
- v1.5.5.1
- v1.5.5-rc3
- v1.5.5-rc2
- v1.5.5-rc1
- v1.5.5-rc0
- v1.5.5
- v1.5.4.7
- v1.5.4.6
- v1.5.4.5
- v1.5.4.4
- v1.5.4.3
- v1.5.4.2
- v1.5.4.1
- v1.5.4-rc5
- v1.5.4-rc4
- v1.5.4-rc3
- v1.5.4-rc2
- v1.5.4-rc1
- v1.5.4-rc0
- v1.5.4
- v1.5.3.8
- v1.5.3.7
- v1.5.3.6
- v1.5.3.5
- v1.5.3.4
- v1.5.3.3
- v1.5.3.2
- v1.5.3.1
- v1.5.3-rc7
- v1.5.3-rc6
- v1.5.3-rc5
- v1.5.3-rc4
- v1.5.3-rc3
- v1.5.3-rc2
- v1.5.3-rc1
- v1.5.3-rc0
- v1.5.3
- v1.5.2.5
- v1.5.2.4
- v1.5.2.3
- v1.5.2.2
- v1.5.2.1
- v1.5.2-rc3
- v1.5.2-rc2
- v1.5.2-rc1
- v1.5.2-rc0
- v1.5.2
- v1.5.1.6
- v1.5.1.5
- v1.5.1.4
- v1.5.1.3
- v1.5.1.2
- v1.5.1.1
- v1.5.1-rc3
- v1.5.1-rc2
- v1.5.1-rc1
- v1.5.1
- v1.5.0.7
- v1.5.0.6
- v1.5.0.5
- v1.5.0.4
- v1.5.0.3
- v1.5.0.2
- v1.5.0.1
- v1.5.0-rc4
- v1.5.0-rc3
- v1.5.0-rc2
- v1.5.0-rc1
- v1.5.0-rc0
- v1.5.0
- v1.4.4.5
- v1.4.4.4
- v1.4.4.3
- v1.4.4.2
- v1.4.4.1
- v1.4.4-rc2
- v1.4.4-rc1
- v1.4.4
- v1.4.3.5
- v1.4.3.4
- v1.4.3.3
- v1.4.3.2
- v1.4.3.1
- v1.4.3-rc3
- v1.4.3-rc2
- v1.4.3-rc1
- v1.4.3
- v1.4.2.4
- v1.4.2.3
- v1.4.2.2
- v1.4.2.1
- v1.4.2-rc4
- v1.4.2-rc3
- v1.4.2-rc2
- v1.4.2-rc1
- v1.4.2
- v1.4.1.1
- v1.4.1-rc2
- v1.4.1-rc1
- v1.4.1
- v1.4.0-rc2
- v1.4.0-rc1
- v1.4.0
- v1.3.3
- v1.3.2
- v1.3.1
- v1.3.0-rc4
- v1.3.0-rc3
- v1.3.0-rc2
- v1.3.0-rc1
- v1.3.0
- v1.2.6
- v1.2.5
- v1.2.4
- v1.2.3
- v1.2.2
- v1.2.1
- v1.2.0
- v1.1.6
- v1.1.5
- v1.1.4
- v1.1.3
- v1.1.2
- v1.1.1
- v1.1.0
- v1.0.9
- v1.0.8
- v1.0.7
- v1.0.6
- v1.0.5
- v1.0.4
- v1.0.3
- v1.0.13
- v1.0.12
- v1.0.11
- v1.0.10
- v1.0.0b
- v1.0.0a
- v1.0.0
- v0.99.9n
- v0.99.9m
- v0.99.9l
- v0.99.9k
- v0.99.9j
- v0.99.9i
- v0.99.9h
- v0.99.9g
- v0.99.9f
- v0.99.9e
- v0.99.9d
- v0.99.9c
- v0.99.9b
- v0.99.9a
- v0.99.9
- v0.99.8g
- v0.99.8f
- v0.99.8e
- v0.99.8d
- v0.99.8c
- v0.99.8b
- v0.99.8a
- v0.99.8
- v0.99.7d
- v0.99.7c
- v0.99.7b
- v0.99.7a
- v0.99.7
- v0.99.6
- v0.99.5
- v0.99.4
- v0.99.3
- v0.99.2
- v0.99.1
- v0.99
- gitgui-0.9.3
- gitgui-0.9.2
- gitgui-0.9.1
- gitgui-0.9.0
- gitgui-0.8.4
- gitgui-0.8.3
- gitgui-0.8.2
- gitgui-0.8.1
- gitgui-0.8.0
- gitgui-0.7.5
- gitgui-0.7.4
- gitgui-0.7.3
- gitgui-0.7.2
- gitgui-0.7.1
- gitgui-0.7.0-rc1
- gitgui-0.7.0
- gitgui-0.6.5
- gitgui-0.6.4
- gitgui-0.6.3
- gitgui-0.6.2
- gitgui-0.6.1
- gitgui-0.6.0
- gitgui-0.21.0
- gitgui-0.20.0
- gitgui-0.19.0
- gitgui-0.18.0
- gitgui-0.17.0
- gitgui-0.16.0
- gitgui-0.15.0
- gitgui-0.14.0
- gitgui-0.13.0
- gitgui-0.12.0
- gitgui-0.11.0
- gitgui-0.10.2
- gitgui-0.10.1
- gitgui-0.10.0
Take a new snapshot of a software origin
If the archived software origin currently browsed is not synchronized with its upstream version (for instance when new commits have been issued), you can explicitly request Software Heritage to take a new snapshot of it.
Use the form below to proceed. Once a request has been submitted and accepted, it will be processed as soon as possible. You can then check its processing state by visiting this dedicated page.![swh spinner](/static/img/swh-spinner.gif)
Processing "take a new snapshot" request ...
Permalinks
To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.
Revision | Author | Date | Message | Commit Date |
---|---|---|---|---|
fd59c5b | Johannes Schindelin | 23 June 2022, 10:36:14 UTC | Git 2.36.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:40:44 UTC |
8f8eea8 | Johannes Schindelin | 23 June 2022, 10:36:12 UTC | Sync with 2.35.4 * maint-2.35: Git 2.35.4 Git 2.34.4 Git 2.33.4 Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo | 23 June 2022, 10:36:12 UTC |
359da65 | Johannes Schindelin | 23 June 2022, 10:36:05 UTC | Git 2.35.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:36:05 UTC |
aef3d59 | Johannes Schindelin | 23 June 2022, 10:36:03 UTC | Sync with 2.34.4 * maint-2.34: Git 2.34.4 Git 2.33.4 Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo | 23 June 2022, 10:36:03 UTC |
f2eed22 | Johannes Schindelin | 23 June 2022, 10:35:49 UTC | Git 2.34.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:35:49 UTC |
378eade | Johannes Schindelin | 23 June 2022, 10:35:47 UTC | Sync with 2.33.4 * maint-2.33: Git 2.33.4 Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo | 23 June 2022, 10:35:47 UTC |
80c525c | Johannes Schindelin | 23 June 2022, 10:35:41 UTC | Git 2.33.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:35:41 UTC |
eebfde3 | Johannes Schindelin | 23 June 2022, 10:35:38 UTC | Sync with 2.32.3 * maint-2.32: Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo | 23 June 2022, 10:35:38 UTC |
656d9a2 | Johannes Schindelin | 23 June 2022, 10:35:32 UTC | Git 2.32.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:35:32 UTC |
fc0c773 | Johannes Schindelin | 23 June 2022, 10:35:30 UTC | Sync with 2.31.4 * maint-2.31: Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo | 23 June 2022, 10:35:30 UTC |
5b1c746 | Johannes Schindelin | 23 June 2022, 10:35:25 UTC | Git 2.31.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:35:25 UTC |
2f8809f | Johannes Schindelin | 23 June 2022, 10:35:23 UTC | Sync with 2.30.5 * maint-2.30: Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo | 23 June 2022, 10:35:23 UTC |
88b7be6 | Johannes Schindelin | 27 May 2022, 21:38:36 UTC | Git 2.30.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:31:05 UTC |
3b0bf27 | Carlo Marcelo Arenas Belón | 10 May 2022, 19:35:29 UTC | setup: tighten ownership checks post CVE-2022-24765 8959555cee7 (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), adds a function to check for ownership of repositories using a directory that is representative of it, and ways to add exempt a specific repository from said check if needed, but that check didn't account for owership of the gitdir, or (when used) the gitfile that points to that gitdir. An attacker could create a git repository in a directory that they can write into but that is owned by the victim to work around the fix that was introduced with CVE-2022-24765 to potentially run code as the victim. An example that could result in privilege escalation to root in *NIX would be to set a repository in a shared tmp directory by doing (for example): $ git -C /tmp init To avoid that, extend the ensure_valid_ownership function to be able to check for all three paths. This will have the side effect of tripling the number of stat() calls when a repository is detected, but the effect is expected to be likely minimal, as it is done only once during the directory walk in which Git looks for a repository. Additionally make sure to resolve the gitfile (if one was used) to find the relevant gitdir for checking. While at it change the message printed on failure so it is clear we are referring to the repository by its worktree (or gitdir if it is bare) and not to a specific directory. Helped-by: Junio C Hamano <junio@pobox.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> | 23 June 2022, 10:31:05 UTC |
b779214 | Junio C Hamano | 26 May 2022, 21:51:32 UTC | Merge branch 'cb/path-owner-check-with-sudo' With a recent update to refuse access to repositories of other people by default, "sudo make install" and "sudo git describe" stopped working. This series intends to loosen it while keeping the safety. * cb/path-owner-check-with-sudo: t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 June 2022, 10:31:04 UTC |
6b11e3d | Carlo Marcelo Arenas Belón | 17 June 2022, 20:23:38 UTC | git-compat-util: allow root to access both SUDO_UID and root owned Previous changes introduced a regression which will prevent root for accessing repositories owned by thyself if using sudo because SUDO_UID takes precedence. Loosen that restriction by allowing root to access repositories owned by both uid by default and without having to add a safe.directory exception. A previous workaround that was documented in the tests is no longer needed so it has been removed together with its specially crafted prerequisite. Helped-by: Johanness Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 June 2022, 21:03:08 UTC |
dc8c8de | Junio C Hamano | 08 June 2022, 01:48:52 UTC | Prepare for 2.36.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 June 2022, 21:27:53 UTC |
d2b11e0 | Junio C Hamano | 08 June 2022, 21:27:53 UTC | Merge branch 'jc/clone-remote-name-leak-fix' into maint "git clone --origin X" leaked piece of memory that held value read from the clone.defaultRemoteName configuration variable, which has been plugged. source: <xmqqlevl4ysk.fsf@gitster.g> * jc/clone-remote-name-leak-fix: clone: plug a miniscule leak | 08 June 2022, 21:27:53 UTC |
67c305f | Junio C Hamano | 08 June 2022, 21:27:53 UTC | Merge branch 'ds/midx-normalize-pathname-before-comparison' into maint The path taken by "git multi-pack-index" command from the end user was compared with path internally prepared by the tool withut first normalizing, which lead to duplicated paths not being noticed, which has been corrected. source: <pull.1221.v2.git.1650911234.gitgitgadget@gmail.com> * ds/midx-normalize-pathname-before-comparison: cache: use const char * for get_object_directory() multi-pack-index: use --object-dir real path midx: use real paths in lookup_multi_pack_index() | 08 June 2022, 21:27:53 UTC |
363d54f | Junio C Hamano | 08 June 2022, 21:27:52 UTC | Merge branch 'ah/rebase-keep-base-fix' into maint "git rebase --keep-base <upstream> <branch-to-rebase>" computed the commit to rebase onto incorrectly, which has been corrected. source: <20220421044233.894255-1-alexhenrie24@gmail.com> * ah/rebase-keep-base-fix: rebase: use correct base for --keep-base when a branch is given | 08 June 2022, 21:27:52 UTC |
d777ef9 | Junio C Hamano | 08 June 2022, 21:27:52 UTC | Merge branch 'pw/test-malloc-with-sanitize-address' into maint Avoid problems from interaction between malloc_check and address sanitizer. source: <pull.1210.git.1649507317350.gitgitgadget@gmail.com> * pw/test-malloc-with-sanitize-address: tests: make SANITIZE=address imply TEST_NO_MALLOC_CHECK | 08 June 2022, 21:27:52 UTC |
ac8f6b6 | Junio C Hamano | 08 June 2022, 21:27:52 UTC | Merge branch 'rs/commit-summary-wo-break-rewrite' into maint The commit summary shown after making a commit is matched to what is given in "git status" not to use the break-rewrite heuristics. source: <c35bd0aa-2e46-e710-2b39-89f18bad0097@web.de> * rs/commit-summary-wo-break-rewrite: commit, sequencer: turn off break_opt for commit summary | 08 June 2022, 21:27:52 UTC |
a5a5273 | Junio C Hamano | 08 June 2022, 21:27:52 UTC | Merge branch 'mg/detect-compiler-in-c-locale' into maint Build procedure fixup. source: <f306f43f375bc9b9c98e85260587442e5d9ef0ba.1652094958.git.git@grubix.eu> * mg/detect-compiler-in-c-locale: detect-compiler: make detection independent of locale | 08 June 2022, 21:27:52 UTC |
080b062 | Junio C Hamano | 08 June 2022, 21:27:51 UTC | Merge branch 'cb/ci-make-p4-optional' into maint macOS CI jobs have been occasionally flaky due to tentative version skew between perforce and the homebrew packager. Instead of failing the whole CI job, just let it skip the p4 tests when this happens. source: <20220512223940.238367-1-gitster@pobox.com> * cb/ci-make-p4-optional: ci: use https, not http to download binaries from perforce.com ci: reintroduce prevention from perforce being quarantined in macOS ci: avoid brew for installing perforce ci: make failure to find perforce more user friendly | 08 June 2022, 21:27:51 UTC |
f02e234 | Junio C Hamano | 08 June 2022, 21:27:51 UTC | Merge branch 'ab/valgrind-fixes' into maint A bit of test framework fixes with a few fixes to issues found by valgrind. source: <20220512223218.237544-1-gitster@pobox.com> * ab/valgrind-fixes: commit-graph.c: don't assume that stat() succeeds object-file: fix a unpack_loose_header() regression in 3b6a8db3b03 log test: skip a failing mkstemp() test under valgrind tests: using custom GIT_EXEC_PATH breaks --valgrind tests | 08 June 2022, 21:27:51 UTC |
9d13041 | Junio C Hamano | 08 June 2022, 21:27:51 UTC | Merge branch 'jc/archive-add-file-normalize-mode' into maint "git archive --add-file=<path>" picked up the raw permission bits from the path and propagated to zip output in some cases, without normalization, which has been corrected (tar output did not have this issue). source: <xmqqmtfme8v6.fsf@gitster.g> * jc/archive-add-file-normalize-mode: archive: do not let on-disk mode leak to zip archives | 08 June 2022, 21:27:51 UTC |
c47b89c | Junio C Hamano | 08 June 2022, 21:27:51 UTC | Merge branch 'jc/show-branch-g-current' into maint The "--current" option of "git show-branch" should have been made incompatible with the "--reflog" mode, but this was not enforced, which has been corrected. source: <xmqqh76mf7s4.fsf_-_@gitster.g> * jc/show-branch-g-current: show-branch: -g and --current are incompatible | 08 June 2022, 21:27:51 UTC |
b8117d2 | Junio C Hamano | 08 June 2022, 21:27:50 UTC | Merge branch 'jc/update-ozlabs-url' into maint Update URL to the gitk repository. * jc/update-ozlabs-url: SubmittingPatches: use more stable git.ozlabs.org URL | 08 June 2022, 21:27:51 UTC |
79d1e6d | Junio C Hamano | 08 June 2022, 21:27:50 UTC | Merge branch 'jc/http-clear-finished-pointer' into maint Meant to go with js/ci-gcc-12-fixes. source: <xmqq7d68ytj8.fsf_-_@gitster.g> * jc/http-clear-finished-pointer: http.c: clear the 'finished' member once we are done with it | 08 June 2022, 21:27:50 UTC |
596838d | Junio C Hamano | 08 June 2022, 21:27:50 UTC | Merge branch 'js/ci-gcc-12-fixes' into maint Fixes real problems noticed by gcc 12 and works around false positives. source: <pull.1238.git.1653351786.gitgitgadget@gmail.com> * js/ci-gcc-12-fixes: dir.c: avoid "exceeds maximum object size" error with GCC v12.x nedmalloc: avoid new compile error compat/win32/syslog: fix use-after-realloc | 08 June 2022, 21:27:50 UTC |
05e280c | Junio C Hamano | 26 May 2022, 19:37:31 UTC | http.c: clear the 'finished' member once we are done with it In http.c, the run_active_slot() function allows the given "slot" to make progress by calling step_active_slots() in a loop repeatedly, and the loop is not left until the request held in the slot completes. Ages ago, we used to use the slot->in_use member to get out of the loop, which misbehaved when the request in "slot" completes (at which time, the result of the request is copied away from the slot, and the in_use member is cleared, making the slot ready to be reused), and the "slot" gets reused to service a different request (at which time, the "slot" becomes in_use again, even though it is for a different request). The loop terminating condition mistakenly thought that the original request has yet to be completed. Today's code, after baa7b67d (HTTP slot reuse fixes, 2006-03-10) fixed this issue, uses a separate "slot->finished" member that is set in run_active_slot() to point to an on-stack variable, and the code that completes the request in finish_active_slot() clears the on-stack variable via the pointer to signal that the particular request held by the slot has completed. It also clears the in_use member (as before that fix), so that the slot itself can safely be reused for an unrelated request. One thing that is not quite clean in this arrangement is that, unless the slot gets reused, at which point the finished member is reset to NULL, the member keeps the value of &finished, which becomes a dangling pointer into the stack when run_active_slot() returns. Clear the finished member before the control leaves the function, which has a side effect of unconfusing compilers like recent GCC 12 that is over-eager to warn against such an assignment. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 27 May 2022, 22:58:31 UTC |
2acf4cf | Johannes Schindelin | 24 May 2022, 00:23:06 UTC | dir.c: avoid "exceeds maximum object size" error with GCC v12.x Technically, the pointer difference `end - start` _could_ be negative, and when cast to an (unsigned) `size_t` that would cause problems. In this instance, the symptom is: dir.c: In function 'git_url_basename': dir.c:3087:13: error: 'memchr' specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread] CC ewah/bitmap.o 3087 | if (memchr(start, '/', end - start) == NULL | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ While it is a bit far-fetched to think that `end` (which is defined as `repo + strlen(repo)`) and `start` (which starts at `repo` and never steps beyond the NUL terminator) could result in such a negative difference, GCC has no way of knowing that. See also https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783. Let's just add a safety check, primarily for GCC's benefit. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 24 May 2022, 22:58:41 UTC |
98cdb61 | Johannes Schindelin | 24 May 2022, 00:23:04 UTC | nedmalloc: avoid new compile error GCC v12.x complains thusly: compat/nedmalloc/nedmalloc.c: In function 'DestroyCaches': compat/nedmalloc/nedmalloc.c:326:12: error: the comparison will always evaluate as 'true' for the address of 'caches' will never be NULL [-Werror=address] 326 | if(p->caches) | ^ compat/nedmalloc/nedmalloc.c:196:22: note: 'caches' declared here 196 | threadcache *caches[THREADCACHEMAXCACHES]; | ^~~~~~ ... and it is correct, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 24 May 2022, 22:58:31 UTC |
a6a243e | Johannes Schindelin | 24 May 2022, 00:23:03 UTC | compat/win32/syslog: fix use-after-realloc Git for Windows' SDK recently upgraded to GCC v12.x which points out that the `pos` variable might be used even after the corresponding memory was `realloc()`ed and therefore potentially no longer valid. Since a subset of this SDK is used in Git's CI/PR builds, we need to fix this to continue to be able to benefit from the CI/PR runs. Note: This bug has been with us since 2a6b149c64f6 (mingw: avoid using strbuf in syslog, 2011-10-06), and while it looks tempting to replace the hand-rolled string manipulation with a `strbuf`-based one, that commit's message explains why we cannot do that: The `syslog()` function is called as part of the function in `daemon.c` which is set as the `die()` routine, and since `strbuf_grow()` can call that function if it runs out of memory, this would cause a nasty infinite loop that we do not want to re-introduce. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 24 May 2022, 22:58:22 UTC |
b9063af | Carlo Marcelo Arenas Belón | 13 May 2022, 01:00:19 UTC | t0034: add negative tests and allow git init to mostly work under sudo Add a support library that provides one function that can be used to run a "scriplet" of commands through sudo and that helps invoking sudo in the slightly awkward way that is required to ensure it doesn't block the call (if shell was allowed as tested in the prerequisite) and it doesn't run the command through a different shell than the one we intended. Add additional negative tests as suggested by Junio and that use a new workspace that is owned by root. Document a regression that was introduced by previous commits where root won't be able anymore to access directories they own unless SUDO_UID is removed from their environment. The tests document additional ways that this new restriction could be worked around and the documentation explains why it might be instead considered a feature, but a "fix" is planned for a future change. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 May 2022, 01:12:23 UTC |
ae9abbb | Carlo Marcelo Arenas Belón | 13 May 2022, 01:00:18 UTC | git-compat-util: avoid failing dir ownership checks if running privileged bdc77d1d685 (Add a function to determine whether a path is owned by the current user, 2022-03-02) checks for the effective uid of the running process using geteuid() but didn't account for cases where that user was root (because git was invoked through sudo or a compatible tool) and the original uid that repository trusted for its config was no longer known, therefore failing the following otherwise safe call: guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty [sudo] password for guy: fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else) Attempt to detect those cases by using the environment variables that those tools create to keep track of the original user id, and do the ownership check using that instead. This assumes the environment the user is running on after going privileged can't be tampered with, and also adds code to restrict that the new behavior only applies if running as root, therefore keeping the most common case, which runs unprivileged, from changing, but because of that, it will miss cases where sudo (or an equivalent) was used to change to another unprivileged user or where the equivalent tool used to raise privileges didn't track the original id in a sudo compatible way. Because of compatibility with sudo, the code assumes that uid_t is an unsigned integer type (which is not required by the standard) but is used that way in their codebase to generate SUDO_UID. In systems where uid_t is signed, sudo might be also patched to NOT be unsigned and that might be able to trigger an edge case and a bug (as described in the code), but it is considered unlikely to happen and even if it does, the code would just mostly fail safely, so there was no attempt either to detect it or prevent it by the code, which is something that might change in the future, based on expected user feedback. Reported-by: Guy Maurel <guy.j@maurel.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Randall Becker <rsbecker@nexbridge.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 May 2022, 01:12:23 UTC |
5f1a3fe | Carlo Marcelo Arenas Belón | 13 May 2022, 01:00:17 UTC | t: regression git needs safe.directory when using sudo Originally reported after release of v2.35.2 (and other maint branches) for CVE-2022-24765 and blocking otherwise harmless commands that were done using sudo in a repository that was owned by the user. Add a new test script with very basic support to allow running git commands through sudo, so a reproduction could be implemented and that uses only `git status` as a proxy of the issue reported. Note that because of the way sudo interacts with the system, a much more complete integration with the test framework will require a lot more work and that was therefore intentionally punted for now. The current implementation requires the execution of a special cleanup function which should always be kept as the last "test" or otherwise the standard cleanup functions will fail because they can't remove the root owned directories that are used. This also means that if failures are found while running, the specifics of the failure might not be kept for further debugging and if the test was interrupted, it will be necessary to clean the working directory manually before restarting by running: $ sudo rm -rf trash\ directory.t0034-root-safe-directory/ The test file also uses at least one initial "setup" test that creates a parallel execution directory under the "root" sub directory, which should be used as top level directory for all repositories that are used in this test file. Unlike all other tests the repository provided by the test framework should go unused. Special care should be taken when invoking commands through sudo, since the environment is otherwise independent from what the test framework setup and might have changed the values for HOME, SHELL and dropped several relevant environment variables for your test. Indeed `git status` was used as a proxy because it doesn't even require commits in the repository to work and usually doesn't require much from the environment to run, but a future patch will add calls to `git init` and that will fail to honor the default branch name, unless that setting is NOT provided through an environment variable (which means even a CI run could fail that test if enabled incorrectly). A new SUDO prerequisite is provided that does some sanity checking to make sure the sudo command that will be used allows for passwordless execution as root without restrictions and doesn't mess with git's execution path. This matches what is provided by the macOS agents that are used as part of GitHub actions and probably nowhere else. Most of those characteristics make this test mostly only suitable for CI, but it might be executed locally if special care is taken to provide for all of them in the local configuration and maybe making use of the sudo credential cache by first invoking sudo, entering your password if needed, and then invoking the test with: $ GIT_TEST_ALLOW_SUDO=YES ./t0034-root-safe-directory.sh If it fails to run, then it means your local setup wouldn't work for the test because of the configuration sudo has or other system settings, and things that might help are to comment out sudo's secure_path config, and make sure that the account you are using has no restrictions on the commands it can run through sudo, just like is provided for the user in the CI. For example (assuming a username of marta for you) something probably similar to the following entry in your /etc/sudoers (or equivalent) file: marta ALL=(ALL:ALL) NOPASSWD: ALL Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 May 2022, 01:12:23 UTC |
f15e00b | Ævar Arnfjörð Bjarmason | 12 May 2022, 22:39:40 UTC | ci: use https, not http to download binaries from perforce.com Since 522354d70f4 (Add Travis CI support, 2015-11-27) the CI has used http://filehost.perforce.com/perforce/ to download binaries from filehost.perforce.com, they were then moved to this script in 657343a602e (travis-ci: move Travis CI code into dedicated scripts, 2017-09-10). Let's use https instead for good measure. I don't think we need to worry about the DNS or network between the GitHub CI and perforce.com being MitM'd, but using https gives us extra validation of the payload at least, and is one less thing to worry about when checking where else we rely on non-TLS'd http connections. Also, use the same download site at perforce.com for Linux and macOS tarballs for consistency. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:43:08 UTC |
49af448 | Carlo Marcelo Arenas Belón | 12 May 2022, 22:39:39 UTC | ci: reintroduce prevention from perforce being quarantined in macOS 5ed9fc3fc86 (ci: prevent `perforce` from being quarantined, 2020-02-27) introduces this prevention for brew, but brew has been removed in a previous commit, so reintroduce an equivalent option to avoid a possible regression. This doesn't affect github actions (as configure now) and is therefore done silently to avoid any possible scary irrelevant messages. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:43:08 UTC |
d1c9195 | Carlo Marcelo Arenas Belón | 12 May 2022, 22:39:38 UTC | ci: avoid brew for installing perforce Perfoce's cask in brew is meant[1] to be used only by humans, so replace its use from the CI with a scripted binary download which is less likely to fail, as it is done in Linux. Kept the logic together so it will be less likely to break when moved around as on the fly code changes in this area are settled, at which point it will also feasable to ammend it to avoid some of the hardcoded values by using similar variables to the ones Linux does. In that same line, a POSIX sh syntax is used instead of the similar one used in Linux in preparation for an unrelated future change that might change the shell currently configured for it. This change reintroduces the risk that the installed binaries might not work because of being quarantined that was fixed with 5ed9fc3fc86 (ci: prevent `perforce` from being quarantined, 2020-02-27) but fixing that now was also punted for simplicity and since the affected cloud provider is scheduled to be retired with an on the fly change, but should be addressed if that other change is not integrated further. The discussion on the need to keep 2 radically different versions of the binaries to be tested with Linux vs macOS or how to upgrade to newer versions now that brew won't do that automatically for us has been punted for now as well. On that line the now obsolete comment about it in lib.sh was originally being updated by this change but created conflicts as it is moved around by other on the fly changes, so will be addressed independently as well. [1] https://github.com/Homebrew/homebrew-cask/pull/122347#discussion_r856026584 Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:43:07 UTC |
cde6b9b | Carlo Marcelo Arenas Belón | 12 May 2022, 22:39:37 UTC | ci: make failure to find perforce more user friendly In preparation for a future change that will make perforce installation optional in macOS, make sure that the check for it is done without triggering scary looking errors and add a user friendly message instead. All other existing uses of 'type <cmd>' in our shell scripts that check the availability of a command <cmd> send both standard output and error stream to /dev/null to squelch "<cmd> not found" diagnostic output, but this script left the standard error stream shown. Redirect it just like everybody else to squelch this error message that we fully expect to see. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:43:07 UTC |
7c89855 | Ævar Arnfjörð Bjarmason | 12 May 2022, 22:32:17 UTC | commit-graph.c: don't assume that stat() succeeds Fix code added in 8d84097f965 (commit-graph: expire commit-graph files, 2019-06-18) to check the return value of the stat() system call. Not doing so caused us to use uninitialized memory in the "Bloom generation is limited by --max-new-filters" test in t4216-log-bloom.sh: + rm -f trace.event + pwd + GIT_TRACE2_EVENT=[...]/t/trash directory.t4216-log-bloom/limits/trace.event git commit-graph write --reachable --split=replace --changed-paths --max-new-filters=2 ==24835== Syscall param utimensat(times[0].tv_sec) points to uninitialised byte(s) ==24835== at 0x499E65A: __utimensat64_helper (utimensat.c:34) ==24835== by 0x4999142: utime (utime.c:36) ==24835== by 0x552BE0: mark_commit_graphs (commit-graph.c:2213) ==24835== by 0x550822: write_commit_graph (commit-graph.c:2424) ==24835== by 0x54E3A0: write_commit_graph_reachable (commit-graph.c:1681) ==24835== by 0x4374BB: graph_write (commit-graph.c:269) ==24835== by 0x436F7D: cmd_commit_graph (commit-graph.c:326) ==24835== by 0x407B9A: run_builtin (git.c:465) ==24835== by 0x406651: handle_builtin (git.c:719) ==24835== by 0x407575: run_argv (git.c:786) ==24835== by 0x406410: cmd_main (git.c:917) ==24835== by 0x511F09: main (common-main.c:56) ==24835== Address 0x1ffeffde70 is on thread 1's stack ==24835== in frame #1, created by utime (utime.c:25) ==24835== Uninitialised value was created by a stack allocation ==24835== at 0x552B50: mark_commit_graphs (commit-graph.c:2201) ==24835== [...] error: last command exited with $?=126 not ok 137 - Bloom generation is limited by --max-new-filters This would happen as we stat'd the non-existing ".git/objects/info/commit-graph" file. Let's fix mark_commit_graphs() to check the stat()'s return value, and while we're at it fix another case added in the same commit to do the same. The caller in expire_commit_graphs() would have been less likely to run into this, as it's operating on files it just got from readdir(), but it could still happen due to a race with e.g. a concurrent "rm -rf" of the commit-graph files. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:42:26 UTC |
4627c67 | Ævar Arnfjörð Bjarmason | 12 May 2022, 22:32:18 UTC | object-file: fix a unpack_loose_header() regression in 3b6a8db3b03 Fix a regression in my 3b6a8db3b03 (object-file.c: use "enum" return type for unpack_loose_header(), 2021-10-01) revealed both by running the test suite with --valgrind, and with the amended "git fsck" test. In practice this regression in v2.34.0 caused us to claim that we couldn't parse the header, as opposed to not being able to unpack it. Before the change in the C code the test_cmp added here would emit: -error: unable to unpack header of ./objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 +error: unable to parse header of ./objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 I.e. we'd proceed to call parse_loose_header() on the uninitialized "hdr" value, and it would have been very unlikely for that uninitialized memory to be a valid git object. The other callers of unpack_loose_header() were already checking the enum values exhaustively. See 3b6a8db3b03 and 5848fb11acd (object-file.c: return ULHR_TOO_LONG on "header too long", 2021-10-01). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:42:26 UTC |
29d8e21 | Ævar Arnfjörð Bjarmason | 12 May 2022, 22:32:16 UTC | log test: skip a failing mkstemp() test under valgrind Skip a test added in f1e3df31699 (t: increase test coverage of signature verification output, 2020-03-04) when running under valgrind. Due to valgrind's interception of mkstemp() this test will fail with: + pwd + TMPDIR=[...]/t/trash directory.t4202-log/bogus git log --show-signature -n1 plain-fail ==7696== VG_(mkstemp): failed to create temp file: [...]/t/trash directory.t4202-log/bogus/valgrind_proc_7696_cmdline_d545ddcf [... 10 more similar lines omitted ..] valgrind: Startup or configuration error: valgrind: Can't create client cmdline file in [...]/t/trash directory.t4202-log/bogus/valgrind_proc_7696_cmdline_6e542d1d valgrind: Unable to start up properly. Giving up. error: last command exited with $?=1 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:42:26 UTC |
58407e0 | Ævar Arnfjörð Bjarmason | 12 May 2022, 22:32:15 UTC | tests: using custom GIT_EXEC_PATH breaks --valgrind tests Fix a regression in b7d11a0f5d2 (tests: exercise the RUNTIME_PREFIX feature, 2021-07-24) where tests that want to set up and test a "git" wrapper in $PATH conflicted with the t/bin/valgrind wrapper(s) doing the same. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 22:42:26 UTC |
6a61661 | Junio C Hamano | 12 May 2022, 21:31:09 UTC | archive: do not let on-disk mode leak to zip archives When the "--add-file" option is used to add the contents from an untracked file to the archive, the permission mode bits for these files are sent to the archive-backend specific "write_entry()" method as-is. We normalize the mode bits for tracked files way before we pass them to the write_entry() method; we should do the same here. This is not strictly needed for "tar" archive-backend, as it has its own code to further clean them up, but "zip" archive-backend is not so well prepared. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 May 2022, 21:32:25 UTC |
b014cee | Junio C Hamano | 11 May 2022, 15:10:12 UTC | SubmittingPatches: use more stable git.ozlabs.org URL Signed-off-by: Junio C Hamano <gitster@pobox.com> | 11 May 2022, 15:19:08 UTC |
1fbfd96 | Michael J Gruber | 09 May 2022, 11:22:02 UTC | detect-compiler: make detection independent of locale `detect-compiler` has accumulated a few compiler dependent workarounds lately for the more and more ubiquitious gcc12. This is intended to make CI set-ups work across tool-chain updates, but also help those developers who build with `DEVELOPER=1`. Alas, `detect-compiler` uses the locale dependent output of `$(CC) -v` to parse for the version string, which fails unless it literally contains ` version`. Use `LANG=C $(CC) -v` instead to grep for stable output. Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 May 2022, 15:52:26 UTC |
e54793a | Junio C Hamano | 05 May 2022, 21:36:37 UTC | Git 2.36.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 05 May 2022, 21:36:37 UTC |
565442c | Junio C Hamano | 05 May 2022, 21:36:25 UTC | Merge branch 'ab/cc-package-fixes' into maint Correct choices of C compilers used in various CI jobs. source: <patch-v3-1.1-8b3444ecc87-20220422T092015Z-avarab@gmail.com> * ab/cc-package-fixes: CI: select CC based on CC_PACKAGE (again) | 05 May 2022, 21:36:25 UTC |
c038dd6 | Junio C Hamano | 05 May 2022, 21:36:25 UTC | Merge branch 'jc/cocci-xstrdup-or-null-fix' into maint Get rid of a bogus and over-eager coccinelle rule. source: <xmqq1qxd6e4x.fsf@gitster.g> * jc/cocci-xstrdup-or-null-fix: cocci: drop bogus xstrdup_or_null() rule | 05 May 2022, 21:36:25 UTC |
676cead | Junio C Hamano | 05 May 2022, 21:36:25 UTC | Merge branch 'rs/format-patch-pathspec-fix' into maint "git format-patch <args> -- <pathspec>" lost the pathspec when showing the second and subsequent commits, which has been corrected. source: <c36896a1-6247-123b-4fa3-b7eb24af1897@web.de> * rs/format-patch-pathspec-fix: 2.36 format-patch regression fix | 05 May 2022, 21:36:25 UTC |
09a2302 | Junio C Hamano | 05 May 2022, 21:36:25 UTC | Merge branch 'rs/fast-export-pathspec-fix' into maint "git fast-export -- <pathspec>" lost the pathspec when showing the second and subsequent commits, which has been corrected. source: <2c988c7b-0efe-4222-4a43-8124fe1a9da6@web.de> * rs/fast-export-pathspec-fix: 2.36 fast-export regression fix | 05 May 2022, 21:36:25 UTC |
8da1481 | Junio C Hamano | 05 May 2022, 21:36:24 UTC | Merge branch 'jc/show-pathspec-fix' into maint "git show <commit1> <commit2>... -- <pathspec>" lost the pathspec when showing the second and subsequent commits, which has been corrected. source: <xmqqo80j87g0.fsf_-_@gitster.g> * jc/show-pathspec-fix: 2.36 show regression fix | 05 May 2022, 21:36:24 UTC |
ee12682 | Junio C Hamano | 05 May 2022, 21:36:24 UTC | Merge branch 'rs/name-rev-fix-free-after-use' into maint Regression fix for 2.36 where "git name-rev" started to sometimes reference strings after they are freed. This fixes a regression in 2.36 and is slate to go to 2.36.1 source: <340c8810-d912-7b18-d46e-a9d43f20216a@web.de> * rs/name-rev-fix-free-after-use: Revert "name-rev: release unused name strings" | 05 May 2022, 21:36:24 UTC |
8e5c46e | Junio C Hamano | 05 May 2022, 21:36:24 UTC | Merge branch 'jc/diff-tree-stdin-fix' into maint "diff-tree --stdin" has been broken for about a year, but 2.36 release broke it even worse by breaking running the command with <pathspec>, which in turn broke "gitk" and got noticed. This has been corrected by aligning its behaviour to that of "log". This fixes a regression in 2.36 and is slate to go to 2.36.1 source: <xmqq7d7bsu2n.fsf@gitster.g> * jc/diff-tree-stdin-fix: 2.36 gitk/diff-tree --stdin regression fix | 05 May 2022, 21:36:24 UTC |
899df5f | Junio C Hamano | 05 May 2022, 21:36:24 UTC | Merge branch 'gc/submodule-update-part2' into maint "git submodule update" without pathspec should silently skip an uninitialized submodule, but it started to become noisy by mistake. This fixes a regression in 2.36 and is slate to go to 2.36.1 source: <pull.1258.v2.git.git.1650890741430.gitgitgadget@gmail.com> * gc/submodule-update-part2: submodule--helper: fix initialization of warn_if_uninitialized | 05 May 2022, 21:36:24 UTC |
08bdd3a | Junio C Hamano | 01 May 2022, 05:00:30 UTC | cocci: drop bogus xstrdup_or_null() rule 13092a91 (cocci: refactor common patterns to use xstrdup_or_null(), 2016-10-12) introduced a rule to rewrite this conditional call to xstrdup(E) and an assignment to variable V: - if (E) - V = xstrdup(E); into an unconditional call to xstrdup_or_null(E) and an assignment to variable V: + V = xstrdup_or_null(E); which is utterly bogus. The original code may already have an acceptable value in V and the conditional assignment may be to improve the value already in V with a copy of a better value E when (and only when) E is not NULL. The rewritten construct unconditionally discards the existing value of V and replaces it with a copy of E, even when E is NULL, which changes the meaning of the program. By the way, if it were -if (E && !V) - V = xstrdup(E); +V = xstrdup_or_null(E); it would probably have been correct. But there is no existing code that would have been improved by such a rule, so let's just remove the bogus one without replacing with the more specific one. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 May 2022, 05:23:11 UTC |
6dfadc8 | Junio C Hamano | 01 May 2022, 05:17:15 UTC | clone: plug a miniscule leak The remote_name variable is first assigned a copy of the value of the "clone.defaultremotename" configuration variable and then by the value of the "--origin" command line option. The former is prepared to see multiple instances of the configuration variable by freeing the current value of the variable before a copy of the newly discovered value gets assigned to it. The latter however blindly assigned a copy of the new value to the variable, thereby leaking the value read from the configuration variable. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 May 2022, 05:22:12 UTC |
d1c2527 | René Scharfe | 30 April 2022, 14:31:43 UTC | 2.36 fast-export regression fix e900d494dc (diff: add an API for deferred freeing, 2021-02-11) added a way to allow reusing diffopts: the no_free bit. 244c27242f (diff.[ch]: have diff_free() call clear_pathspec(opts.pathspec), 2022-02-16) made that mechanism mandatory. git fast-export doesn't set no_free, so path limiting stopped working after the first commit. Set the flag and add a basic test to make sure only changes to the specified files are exported. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 30 April 2022, 18:50:33 UTC |
91f8f7e | René Scharfe | 30 April 2022, 10:32:44 UTC | 2.36 format-patch regression fix e900d494dc (diff: add an API for deferred freeing, 2021-02-11) added a way to allow reusing diffopts: the no_free bit. 244c27242f (diff.[ch]: have diff_free() call clear_pathspec(opts.pathspec), 2022-02-16) made that mechanism mandatory. git format-patch only sets no_free when --output is given, causing it to forget pathspecs after the first commit. Set no_free unconditionally instead. The existing test was unable to detect this breakage because it checks stderr for the absence of a certain string, but format-patch writes to stdout. Also the test was not checking the case of one commit modifying multiple files and a pathspec limiting the diff. Replace it with a more thorough one. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 30 April 2022, 18:49:59 UTC |
5cdb384 | Junio C Hamano | 30 April 2022, 05:29:51 UTC | 2.36 show regression fix This only surfaced as a regression after 2.36 release, but the breakage was already there with us for at least a year. e900d494 (diff: add an API for deferred freeing, 2021-02-11) introduced a mechanism to delay freeing resources held in diff_options struct that need to be kept as long as the struct will be reused to compute diff. "git log -p" was taught to utilize the mechanism but it was done with an incorrect assumption that the underlying helper function, cmd_log_walk(), is called only once, and it is OK to do the freeing at the end of it. Alas, for "git show A B", the function is called once for each commit given, so it is not OK to free the resources until we finish calling it for all the commits given from the command line. During 2.36 release cycle, we started clearing the <pathspec> as part of this freeing, which made the bug a lot more visible. Fix this breakage by tweaking how cmd_log_walk() frees the resources at the end and using a variant of it that does not immediately free the resources to show each commit object from the command line in "git show". Protect the fix with a few new tests. Reported-by: Daniel Li <dan@danielyli.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 30 April 2022, 05:31:17 UTC |
4f1ccef | Orgad Shaneh | 25 April 2022, 12:45:41 UTC | submodule--helper: fix initialization of warn_if_uninitialized The .warn_if_uninitialized member was introduced by 48308681 (git submodule update: have a dedicated helper for cloning, 2016-02-29) to submodule_update_clone struct and initialized to false. When c9911c93 (submodule--helper: teach update_data more options, 2022-03-15) moved it to update_data struct, it started to initialize it to true but this change was not explained in its log message. The member is set to true only when pathspec was given, and is used when a submodule that matched the pathspec is found uninitialized to give diagnostic message. "submodule update" without pathspec is supposed to iterate over all submodules (i.e. without pathspec limitation) and update only the initialized submodules, and finding uninitialized submodules during the iteration is a totally expected and normal thing that should not be warned. [jc: added tests] Signed-off-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 26 April 2022, 18:14:10 UTC |
f8781bf | Junio C Hamano | 26 April 2022, 16:11:44 UTC | 2.36 gitk/diff-tree --stdin regression fix This only surfaced as a regression after 2.36 release, but the breakage was already there with us for at least a year. The diff_free() call is to be used after we completely finished with a diffopt structure. After "git diff A B" finishes producing output, calling it before process exit is fine. But there are commands that prepares diff_options struct once, compares two sets of paths, releases resources that were used to do the comparison, then reuses the same diff_option struct to go on to compare the next two sets of paths, like "git log -p". After "git log -p" finishes showing a single commit, calling it before it goes on to the next commit is NOT fine. There is a mechanism, the .no_free member in diff_options struct, to help "git log" to avoid calling diff_free() after showing each commit and instead call it just one. When the mechanism was introduced in e900d494 (diff: add an API for deferred freeing, 2021-02-11), however, we forgot to do the same to "diff-tree --stdin", which *is* a moral equivalent to "git log". During 2.36 release cycle, we started clearing the pathspec in diff_free(), so programs like gitk that runs git diff-tree --stdin -- <pathspec> downstream of a pipe, processing one commit after another, started showing irrelevant comparison outside the given <pathspec> from the second commit. The same commit, by forgetting to teach the .no_free mechanism, broke "diff-tree --stdin -I<regexp>" and nobody noticed it for over a year, presumably because it is so seldom used an option. But <pathspec> is a different story. The breakage was very prominently visible and was reported immediately after 2.36 was released. Fix this breakage by mimicking how "git log" utilizes the .no_free member so that "diff-tree --stdin" behaves more similarly to "log". Protect the fix with a few new tests. Reported-by: Matthias Aßhauer <mha1993@live.de> Helped-by: René Scharfe <l.s.r@web.de> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 26 April 2022, 16:26:35 UTC |
11f9e8d | Derrick Stolee | 25 April 2022, 18:27:14 UTC | cache: use const char * for get_object_directory() The get_object_directory() method returns the exact string stored at the_repository->objects->odb->path. The return type of "char *" implies that the caller must keep track of the buffer and free() it when complete. This causes significant problems later when the ODB is accessed. Use "const char *" as the return type to avoid this confusion. There are no current callers that care about the non-const definition. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 April 2022, 18:31:13 UTC |
b56166c | Derrick Stolee | 25 April 2022, 18:27:13 UTC | multi-pack-index: use --object-dir real path The --object-dir argument to 'git multi-pack-index' allows a user to specify an alternate to use instead of the local $GITDIR. This is used by third-party tools like VFS for Git to maintain the pack-files in a "shared object cache" used by multiple clones. On Windows, the user can specify a path using a Windows-style file path with backslashes such as "C:\Path\To\ObjectDir". This same path style is used in the .git/objects/info/alternates file, so it already matches the path of that alternate. However, find_odb() converts these paths to real-paths for the comparison, which use forward slashes. As of the previous change, lookup_multi_pack_index() uses real-paths, so it correctly finds the target multi-pack-index when given these paths. Some commands such as 'git multi-pack-index repack' call child processes using the object_dir value, so it can be helpful to convert the path to the real-path before sending it to those locations. Add a callback to convert the real path immediately upon parsing the argument. We need to be careful that we don't store the exact value out of get_object_directory() and free it, or we could corrupt a later use of the_repository->objects->odb->path. We don't use get_object_directory() for the initial instantiation in cmd_multi_pack_index() because we need 'git multi-pack-index -h' to work without a Git repository. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 April 2022, 18:31:12 UTC |
eafcc6d | Derrick Stolee | 25 April 2022, 18:27:12 UTC | midx: use real paths in lookup_multi_pack_index() This helper looks for a parsed multi-pack-index whose object directory matches the given object_dir. Before going into the loop over the parsed multi-pack-indexes, it calls find_odb() to ensure that the given object_dir is actually a known object directory. However, find_odb() uses real-path manipulations to compare the input to the alternate directories. This same real-path comparison is not used in the loop, leading to potential issues with the strcmp(). Update the method to use the real-path values instead. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 April 2022, 18:31:11 UTC |
45a14f5 | René Scharfe | 22 April 2022, 18:44:40 UTC | Revert "name-rev: release unused name strings" This reverts commit 2d53975488df195e1431c3f90bfb5b60018d5bf6. 3656f84278 (name-rev: prefer shorter names over following merges, 2021-12-04) broke the assumption of 2d53975488 (name-rev: release unused name strings, 2020-02-04) that a better name for a child is a better name for all of its ancestors as well, because it added a penalty for generation > 0. This leads to strings being free(3)'d that are still needed. 079f970971 (name-rev: sort tip names before applying, 2020-02-05) already reduced the number of free(3) calls for the use case that motivated the original patch (name-rev --all in the Chromium repository) from ca. 44000 to 5, and 3656f84278 eliminated even those few. So this revert won't affect name-rev's performance on that particular repo. Reported-by: Thomas Hurst <tom@hur.st> Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 23 April 2022, 16:46:40 UTC |
3506cae | Ævar Arnfjörð Bjarmason | 22 April 2022, 09:20:53 UTC | CI: select CC based on CC_PACKAGE (again) Fix a regression in 707d2f2fe86 (CI: use "$runs_on_pool", not "$jobname" to select packages & config, 2021-11-23). In that commit I changed CC=gcc from CC=gcc-9, but on OSX the "gcc" in $PATH points to clang, we need to use gcc-9 instead. Likewise for the linux-gcc job CC=gcc-8 was changed to the implicit CC=gcc, which would select GCC 9.4.0 instead of GCC 8.4.0. Furthermore in 25715419bf4 (CI: don't run "make test" twice in one job, 2021-11-23) when the "linux-TEST-vars" job was split off from "linux-gcc" the "cc_package: gcc-8" line was copied along with it, so its "cc_package" line wasn't working as intended either. As a table, this is what's changed by this commit, i.e. it only affects the linux-gcc, linux-TEST-vars and osx-gcc jobs: |-------------------+-----------+-------------------+-------+-------| | jobname | vector.cc | vector.cc_package | old | new | |-------------------+-----------+-------------------+-------+-------| | linux-clang | clang | - | clang | clang | | linux-sha256 | clang | - | clang | clang | | linux-gcc | gcc | gcc-8 | gcc | gcc-8 | | osx-clang | clang | - | clang | clang | | osx-gcc | gcc | gcc-9 | clang | gcc-9 | | linux-gcc-default | gcc | - | gcc | gcc | | linux-TEST-vars | gcc | gcc-8 | gcc | gcc-8 | |-------------------+-----------+-------------------+-------+-------| Reported-by: Carlo Arenas <carenas@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 22 April 2022, 18:28:17 UTC |
41c64ae | Junio C Hamano | 21 April 2022, 21:25:47 UTC | show-branch: -g and --current are incompatible When "--current" is given to "git show-branch" running in the "--reflog" mode, the code tries to reference a "reflog" message that does not even exist. This is because the --current is not prepared to work in that mode. The reason "--current" exists is to support this request: I list branches on the command line. These are the branchesI care about and I use as anchoring points. I may or may not be on one of these main branches. Please make sure I can view the commits on the current branch with respect to what is in these other branches. And to serve that request, the code checks if the current branch is among the ones listed on the command line, and adds it only if it is not to the end of one array, which essentially lists the objects. The reflog mode additionally uses another array to list reflog messages, which the "--current" code does not add to. This leaves one uninitialized slot at the end of the array of reflog messages, and causes the program to show garbage or segfault. Catch the unsupported (and meaningless) combination and exit with a usage error. There are other combinations of options that are incompatible but have not been tested. Add test to cover them while adding coverage for this new combination. Reported-by: Gregory David <gregory.david@p1sec.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 April 2022, 21:26:42 UTC |
9e5ebe9 | Alex Henrie | 21 April 2022, 04:42:33 UTC | rebase: use correct base for --keep-base when a branch is given --keep-base rebases onto the merge base of the given upstream and the current HEAD regardless of whether a branch is given. This is contrary to the documentation and to the option's intended purpose. Instead, rebase onto the merge base of the given upstream and the given branch. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 April 2022, 16:35:45 UTC |
6cd33dc | Junio C Hamano | 18 April 2022, 05:21:51 UTC | Git 2.36 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 April 2022, 05:21:51 UTC |
b908065 | Junio C Hamano | 18 April 2022, 05:20:49 UTC | Merge tag 'l10n-2.36.0-rnd2.1' of https://github.com/git-l10n/git-po l10n-2.36.0-rnd2.1 * tag 'l10n-2.36.0-rnd2.1' of https://github.com/git-l10n/git-po: l10n: sv.po: Update Swedish translation (5282t0f0u) l10n: Update Catalan translation l10n: po-id for 2.36 (round 2) l10n: de.po: Update German translation l10n: zh_CN v2.36.0 round 2 l10n: pt_PT: update Portuguese translation l10n: vi(5285t): v2.36.0 round 2 l10n: zh_TW: v2.36.0 round 2 l10n: fr: v2.36 round 2 l10n: tr: v2.36.0 round 2 l10n: git.pot: v2.36.0 round 2 (4 new, 3 removed) l10n: fr: v2.36 round 1 l10n: zh_CN v2.36.0 round 1 l10n: Update zh_CN repo link l10n: po-id for 2.36 (round 1) l10n: tr: v2.36.0 round 1 l10n: git.pot: v2.36.0 round 1 (192 new, 106 removed) l10n: pt_PT: update TEAMS file l10n: pt_PT: update Portuguese translation | 18 April 2022, 05:20:49 UTC |
db4361b | Junio C Hamano | 17 April 2022, 23:32:05 UTC | Merge branch 'cb/buggy-gcc-12-workaround' A couple of work around for CI breaking warnings from gcc 12. * cb/buggy-gcc-12-workaround: config.mak.dev: alternative workaround to gcc 12 warning in http.c config.mak.dev: workaround gcc 12 bug affecting "pedantic" CI job | 17 April 2022, 23:32:05 UTC |
9b23d2c | Peter Krefting | 17 April 2022, 17:13:34 UTC | l10n: sv.po: Update Swedish translation (5282t0f0u) Signed-off-by: Peter Krefting <peter@softwolves.pp.se> | 17 April 2022, 17:13:34 UTC |
1208041 | Jiang Xin | 17 April 2022, 01:07:28 UTC | Merge branch 'master' of github.com:Softcatala/git-po * 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation | 17 April 2022, 01:07:28 UTC |
ac87f96 | Jordi Mas | 16 April 2022, 18:17:17 UTC | l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> | 16 April 2022, 18:17:17 UTC |
aac04e0 | Bagas Sanjaya | 14 April 2022, 06:40:35 UTC | l10n: po-id for 2.36 (round 2) Translate following new components: * setup.c * split-index.c * strbuf.c * trailer.c Also delete obsolete strings. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 16 April 2022, 10:04:26 UTC |
9c539d1 | Carlo Marcelo Arenas Belón | 15 April 2022, 23:13:42 UTC | config.mak.dev: alternative workaround to gcc 12 warning in http.c This provides a "no code change needed" option to the "fix" currently queued as part of ab/http-gcc-12-workaround and therefore should be reverted once that gets merged. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 15 April 2022, 23:27:04 UTC |
846a29a | Carlo Marcelo Arenas Belón | 15 April 2022, 23:13:41 UTC | config.mak.dev: workaround gcc 12 bug affecting "pedantic" CI job Originally noticed by Peff[1], but yet to be corrected[2] and planned to be released with Fedora 36 (scheduled for Apr 19). dir.c: In function ‘git_url_basename’: dir.c:3085:13: error: ‘memchr’ specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread] 3085 | if (memchr(start, '/', end - start) == NULL | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fedora is used as part of the CI, and therefore that release will trigger failures, unless the version of the image used is locked to an older release, as an alternative. Restricting the flag to the affected source file, as well as implementing an independent facility to track these workarounds was specifically punted to minimize the risk of introducing problems so close to a release. This change should be reverted once the underlying gcc bug is solved and which should be visible by NOT triggering a warning, otherwise. [1] https://lore.kernel.org/git/YZQhLh2BU5Hquhpo@coredump.intra.peff.net/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075786 Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 15 April 2022, 23:26:16 UTC |
c616d18 | Jiang Xin | 15 April 2022, 00:26:53 UTC | Merge branch 'master' of github.com:ruester/git-po-de * 'master' of github.com:ruester/git-po-de: l10n: de.po: Update German translation | 15 April 2022, 00:26:53 UTC |
cb6da32 | Jiang Xin | 15 April 2022, 00:26:06 UTC | Merge branch 'fz/po-2.36.0-round2' of github.com:fangyi-zhou/git-po * 'fz/po-2.36.0-round2' of github.com:fangyi-zhou/git-po: l10n: zh_CN v2.36.0 round 2 | 15 April 2022, 00:26:06 UTC |
4027e30 | Junio C Hamano | 14 April 2022, 21:17:12 UTC | Merge branch 'jc/revert-ref-transaction-hook-changes' Revert the "deletion of a ref should not trigger transaction events for loose and packed ref backends separately" that regresses the behaviour when a ref is not modified since it was packed. * jc/revert-ref-transaction-hook-changes: RelNotes: revert the description on the reverted topics Revert "fetch: increase test coverage of fetches" Revert "Merge branch 'ps/avoid-unnecessary-hook-invocation-with-packed-refs'" | 14 April 2022, 21:17:12 UTC |
b32632c | Junio C Hamano | 14 April 2022, 21:17:12 UTC | Merge branch 'jc/relnotes-updates' Wording updates for 2.36 release notes. * jc/relnotes-updates: RelNotes: mention safe.directory RelNotes: clarify "bisect run unexecutable" tweak | 14 April 2022, 21:17:12 UTC |
4ac22f8 | Matthias Rüster | 09 April 2022, 15:57:47 UTC | l10n: de.po: Update German translation Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> | 14 April 2022, 15:03:02 UTC |
40f3541 | Fangyi Zhou | 14 April 2022, 14:46:21 UTC | l10n: zh_CN v2.36.0 round 2 Signed-off-by: Fangyi Zhou <me@fangyi.io> | 14 April 2022, 14:49:18 UTC |
b3717a8 | Daniel Santos | 23 February 2022, 19:39:47 UTC | l10n: pt_PT: update Portuguese translation * update the following words translations: commit, untracked, stage, cache, stash, work..., index, reset, label, check..., tags, graft, alternate object, amend, ancestor, cherry-pick, bisect, blame, chain, cache, bug, chunk, branch, bundle, clean, clone, commit-graph, commit object, commit-ish, committer, cover letter, conflict, dangling, detach, dir, dumb, fast-forward, file system, fixup, fork, fetch, Git archive, gitdir, graft, replace ref * correct some mispellings * git-po-helper update * remove some obsolete lines * unfuzzy entries * random translation updates * update contact in pt_PT.po * add the following words to the translation table: override, recurse, print, offset, unbundle, mirror repository, multi-pack, bad, whitespace, batch * remove the following words of the translation table: core Git * change the following words on the translation table: dry-run, apply, patch, replay, blame, chain, gitdir, file system, fork, unset, handle * some translation to the first person * update copyright text * word 'utilização:' to 'uso:' * word 'pai' to 'parente' Signed-off-by: Daniel Santos <dacs.git@brilhante.top> | 14 April 2022, 11:09:07 UTC |
2a7f398 | Tran Ngoc Quan | 14 April 2022, 06:58:46 UTC | l10n: vi(5285t): v2.36.0 round 2 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> | 14 April 2022, 08:34:48 UTC |
dd6cf19 | Jiang Xin | 14 April 2022, 05:13:38 UTC | Merge branch 'loc/tw/0407' of github.com:l10n-tw/git-po * 'loc/tw/0407' of github.com:l10n-tw/git-po: l10n: zh_TW: v2.36.0 round 2 | 14 April 2022, 05:13:38 UTC |
c9f01d5 | Yi-Jyun Pan | 07 April 2022, 06:30:49 UTC | l10n: zh_TW: v2.36.0 round 2 Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com> | 14 April 2022, 00:07:08 UTC |
4315986 | Junio C Hamano | 13 April 2022, 23:55:36 UTC | RelNotes: revert the description on the reverted topics Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 23:55:36 UTC |
255ede9 | Junio C Hamano | 13 April 2022, 23:51:41 UTC | RelNotes: mention safe.directory Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 23:51:41 UTC |
26ff9be | Junio C Hamano | 13 April 2022, 23:42:33 UTC | RelNotes: clarify "bisect run unexecutable" tweak We do not have to guess how common the mistake the change targets is when describing it. Such an argument may be good while proposing a change, but does not quite belong in the record of what has already happened, i.e. a release note. Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 23:42:33 UTC |
347cc1b | Junio C Hamano | 13 April 2022, 22:58:04 UTC | Revert "fetch: increase test coverage of fetches" This reverts commit 2a0cafd464709cfa22fe7249290c644a2a26c520, as it expects a working "a ref deletion must produce a single transaction, not one for loose and another for packed" topic, which we do not have. | 13 April 2022, 22:58:04 UTC |
c6da34a | Junio C Hamano | 13 April 2022, 22:51:33 UTC | Revert "Merge branch 'ps/avoid-unnecessary-hook-invocation-with-packed-refs'" This reverts commit 991b4d47f0accd3955d05927d5ce434e03ffbdb6, reversing changes made to bcd020f88e1e22f38422ac3f73ab06b34ec4bef1. | 13 April 2022, 22:51:33 UTC |
1ac7422 | Junio C Hamano | 13 April 2022, 22:26:32 UTC | Sync with Git 2.35.3 | 13 April 2022, 22:26:32 UTC |
d516b2d | Junio C Hamano | 13 April 2022, 22:21:34 UTC | Git 2.35.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 22:21:34 UTC |
2f0dde7 | Junio C Hamano | 13 April 2022, 22:21:31 UTC | Git 2.34.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 22:21:31 UTC |
1f65dd6 | Junio C Hamano | 13 April 2022, 22:21:28 UTC | Git 2.33.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 22:21:28 UTC |
1530434 | Junio C Hamano | 13 April 2022, 22:21:26 UTC | Git 2.32.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 22:21:26 UTC |