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.46.0-rc2
- v2.46.0-rc1
- v2.46.0-rc0
- v2.46.0
- v2.45.2
- v2.45.1
- v2.45.0-rc1
- v2.45.0-rc0
- v2.45.0
- v2.44.2
- v2.44.1
- v2.44.0-rc2
- v2.44.0-rc1
- v2.44.0-rc0
- v2.44.0
- v2.43.5
- v2.43.4
- 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.3
- v2.42.2
- v2.42.1
- v2.42.0-rc2
- v2.42.0-rc1
- v2.42.0-rc0
- v2.42.0
- v2.41.2
- v2.41.1
- v2.41.0-rc2
- v2.41.0-rc1
- v2.41.0-rc0
- v2.41.0
- v2.40.3
- v2.40.2
- 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.5
- v2.39.4
- 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 ...
Revision | Author | Date | Message | Commit Date |
---|---|---|---|---|
7800e1d | Taylor Blau | 30 September 2022, 21:04:26 UTC | Git 2.33.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> | 06 October 2022, 21:42:27 UTC |
3957f3c | Taylor Blau | 06 October 2022, 21:42:02 UTC | Sync with 2.32.4 Signed-off-by: Taylor Blau <me@ttaylorr.com> | 06 October 2022, 21:42:02 UTC |
af778cd | Taylor Blau | 30 September 2022, 21:00:58 UTC | Git 2.32.4 Signed-off-by: Taylor Blau <me@ttaylorr.com> | 06 October 2022, 21:41:15 UTC |
9cbd282 | Taylor Blau | 06 October 2022, 21:40:44 UTC | Sync with 2.31.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> | 06 October 2022, 21:40:44 UTC |
ecf9b4a | Taylor Blau | 30 September 2022, 20:56:02 UTC | Git 2.31.5 Signed-off-by: Taylor Blau <me@ttaylorr.com> | 06 October 2022, 21:39:26 UTC |
1225129 | Taylor Blau | 06 October 2022, 21:39:15 UTC | Sync with 2.30.6 Signed-off-by: Taylor Blau <me@ttaylorr.com> | 06 October 2022, 21:39:15 UTC |
abd4d67 | Taylor Blau | 30 September 2022, 20:32:10 UTC | Git 2.30.6 Signed-off-by: Taylor Blau <me@ttaylorr.com> | 06 October 2022, 21:38:16 UTC |
067aa8f | Taylor Blau | 30 September 2022, 20:48:56 UTC | t2080: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t1092 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:27:18 UTC |
4a7dab5 | Taylor Blau | 30 September 2022, 20:47:00 UTC | t1092: prepare for changing protocol.file.allow Explicitly cloning over the "file://" protocol in t1092 in preparation for merging a security release which will change the default value of this configuration to be "user". Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:27:14 UTC |
0ca6ead | Kevin Backhouse | 28 September 2022, 22:53:32 UTC | alias.c: reject too-long cmdline strings in split_cmdline() This function improperly uses an int to represent the number of entries in the resulting argument array. This allows a malicious actor to intentionally overflow the return value, leading to arbitrary heap writes. Because the resulting argv array is typically passed to execv(), it may be possible to leverage this attack to gain remote code execution on a victim machine. This was almost certainly the case for certain configurations of git-shell until the previous commit limited the size of input it would accept. Other calls to split_cmdline() are typically limited by the size of argv the OS is willing to hand us, so are similarly protected. So this is not strictly fixing a known vulnerability, but is a hardening of the function that is worth doing to protect against possible unknown vulnerabilities. One approach to fixing this would be modifying the signature of `split_cmdline()` to look something like: int split_cmdline(char *cmdline, const char ***argv, size_t *argc); Where the return value of `split_cmdline()` is negative for errors, and zero otherwise. If non-NULL, the `*argc` pointer is modified to contain the size of the `**argv` array. But this implies an absurdly large `argv` array, which more than likely larger than the system's argument limit. So even if split_cmdline() allowed this, it would fail immediately afterwards when we called execv(). So instead of converting all of `split_cmdline()`'s callers to work with `size_t` types in this patch, instead pursue the minimal fix here to prevent ever returning an array with more than INT_MAX entries in it. Signed-off-by: Kevin Backhouse <kevinbackhouse@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
71ad7fe | Jeff King | 28 September 2022, 22:52:48 UTC | shell: limit size of interactive commands When git-shell is run in interactive mode (which must be enabled by creating $HOME/git-shell-commands), it reads commands from stdin, one per line, and executes them. We read the commands with git_read_line_interactively(), which uses a strbuf under the hood. That means we'll accept an input of arbitrary size (limited only by how much heap we can allocate). That creates two problems: - the rest of the code is not prepared to handle large inputs. The most serious issue here is that split_cmdline() uses "int" for most of its types, which can lead to integer overflow and out-of-bounds array reads and writes. But even with that fixed, we assume that we can feed the command name to snprintf() (via xstrfmt()), which is stuck for historical reasons using "int", and causes it to fail (and even trigger a BUG() call). - since the point of git-shell is to take input from untrusted or semi-trusted clients, it's a mild denial-of-service. We'll allocate as many bytes as the client sends us (actually twice as many, since we immediately duplicate the buffer). We can fix both by just limiting the amount of per-command input we're willing to receive. We should also fix split_cmdline(), of course, which is an accident waiting to happen, but that can come on top. Most calls to split_cmdline(), including the other one in git-shell, are OK because they are reading from an OS-provided argv, which is limited in practice. This patch should eliminate the immediate vulnerabilities. I picked 4MB as an arbitrary limit. It's big enough that nobody should ever run into it in practice (since the point is to run the commands via exec, we're subject to OS limits which are typically much lower). But it's small enough that allocating it isn't that big a deal. The code is mostly just swapping out fgets() for the strbuf call, but we have to add a few niceties like flushing and trimming line endings. We could simplify things further by putting the buffer on the stack, but 4MB is probably a bit much there. Note that we'll _always_ allocate 4MB, which for normal, non-malicious requests is more than we would before this patch. But on the other hand, other git programs are happy to use 96MB for a delta cache. And since we'd never touch most of those pages, on a lazy-allocating OS like Linux they won't even get allocated to actual RAM. The ideal would be a version of strbuf_getline() that accepted a maximum value. But for a minimal vulnerability fix, let's keep things localized and simple. We can always refactor further on top. The included test fails in an obvious way with ASan or UBSan (which notice the integer overflow and out-of-bounds reads). Without them, it fails in a less obvious way: we may segfault, or we may try to xstrfmt() a long string, leading to a BUG(). Either way, it fails reliably before this patch, and passes with it. Note that we don't need an EXPENSIVE prereq on it. It does take 10-15s to fail before this patch, but with the new limit, we fail almost immediately (and the perl process generating 2GB of data exits via SIGPIPE). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
32696a4 | Jeff King | 28 September 2022, 22:50:36 UTC | shell: add basic tests We have no tests of even basic functionality of git-shell. Let's add a couple of obvious ones. This will serve as a framework for adding tests for new things we fix, as well as making sure we don't screw anything up too badly while doing so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
a1d4f67 | Taylor Blau | 29 July 2022, 19:22:13 UTC | transport: make `protocol.file.allow` be "user" by default An earlier patch discussed and fixed a scenario where Git could be used as a vector to exfiltrate sensitive data through a Docker container when a potential victim clones a suspicious repository with local submodules that contain symlinks. That security hole has since been plugged, but a similar one still exists. Instead of convincing a would-be victim to clone an embedded submodule via the "file" protocol, an attacker could convince an individual to clone a repository that has a submodule pointing to a valid path on the victim's filesystem. For example, if an individual (with username "foo") has their home directory ("/home/foo") stored as a Git repository, then an attacker could exfiltrate data by convincing a victim to clone a malicious repository containing a submodule pointing at "/home/foo/.git" with `--recurse-submodules`. Doing so would expose any sensitive contents in stored in "/home/foo" tracked in Git. For systems (such as Docker) that consider everything outside of the immediate top-level working directory containing a Dockerfile as inaccessible to the container (with the exception of volume mounts, and so on), this is a violation of trust by exposing unexpected contents in the working copy. To mitigate the likelihood of this kind of attack, adjust the "file://" protocol's default policy to be "user" to prevent commands that execute without user input (including recursive submodule initialization) from taking place by default. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
f4a32a5 | Taylor Blau | 29 July 2022, 19:21:53 UTC | t/t9NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that interact with submodules a handful of times use `test_config_global`. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
0d3beb7 | Taylor Blau | 29 July 2022, 19:21:40 UTC | t/t7NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
0f21b8f | Taylor Blau | 29 July 2022, 19:21:18 UTC | t/t6NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
225d2d5 | Taylor Blau | 29 July 2022, 19:21:06 UTC | t/t5NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
ac7e57f | Taylor Blau | 29 July 2022, 19:20:43 UTC | t/t4NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
f8d510e | Taylor Blau | 29 July 2022, 19:20:28 UTC | t/t3NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
99f4abb | Taylor Blau | 29 July 2022, 19:20:03 UTC | t/2NNNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Test scripts that rely on submodules throughout use a `git config --global` during a setup test towards the beginning of the script. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
8a96dbc | Taylor Blau | 29 July 2022, 19:16:10 UTC | t/t1NNN: allow local submodules To prepare for the default value of `protocol.file.allow` to change to "user", ensure tests that rely on local submodules can initialize them over the file protocol. Tests that only need to interact with submodules in a limited capacity have individual Git commands annotated with the appropriate configuration via `-c`. Tests that interact with submodules a handful of times use `test_config_global` instead. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
7de0c30 | Taylor Blau | 29 July 2022, 19:13:58 UTC | t/lib-submodule-update.sh: allow local submodules To prepare for changing the default value of `protocol.file.allow` to "user", update the `prolog()` function in lib-submodule-update to allow submodules to be cloned over the file protocol. This is used by a handful of submodule-related test scripts, which themselves will have to tweak the value of `protocol.file.allow` in certain locations. Those will be done in subsequent commits. Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 UTC |
6f054f9 | Taylor Blau | 28 July 2022, 21:35:17 UTC | builtin/clone.c: disallow `--local` clones with symlinks When cloning a repository with `--local`, Git relies on either making a hardlink or copy to every file in the "objects" directory of the source repository. This is done through the callpath `cmd_clone()` -> `clone_local()` -> `copy_or_link_directory()`. The way this optimization works is by enumerating every file and directory recursively in the source repository's `$GIT_DIR/objects` directory, and then either making a copy or hardlink of each file. The only exception to this rule is when copying the "alternates" file, in which case paths are rewritten to be absolute before writing a new "alternates" file in the destination repo. One quirk of this implementation is that it dereferences symlinks when cloning. This behavior was most recently modified in 36596fd2df (clone: better handle symlinked files at .git/objects/, 2019-07-10), which attempted to support `--local` clones of repositories with symlinks in their objects directory in a platform-independent way. Unfortunately, this behavior of dereferencing symlinks (that is, creating a hardlink or copy of the source's link target in the destination repository) can be used as a component in attacking a victim by inadvertently exposing the contents of file stored outside of the repository. Take, for example, a repository that stores a Dockerfile and is used to build Docker images. When building an image, Docker copies the directory contents into the VM, and then instructs the VM to execute the Dockerfile at the root of the copied directory. This protects against directory traversal attacks by copying symbolic links as-is without dereferencing them. That is, if a user has a symlink pointing at their private key material (where the symlink is present in the same directory as the Dockerfile, but the key itself is present outside of that directory), the key is unreadable to a Docker image, since the link will appear broken from the container's point of view. This behavior enables an attack whereby a victim is convinced to clone a repository containing an embedded submodule (with a URL like "file:///proc/self/cwd/path/to/submodule") which has a symlink pointing at a path containing sensitive information on the victim's machine. If a user is tricked into doing this, the contents at the destination of those symbolic links are exposed to the Docker image at runtime. One approach to preventing this behavior is to recreate symlinks in the destination repository. But this is problematic, since symlinking the objects directory are not well-supported. (One potential problem is that when sharing, e.g. a "pack" directory via symlinks, different writers performing garbage collection may consider different sets of objects to be reachable, enabling a situation whereby garbage collecting one repository may remove reachable objects in another repository). Instead, prohibit the local clone optimization when any symlinks are present in the `$GIT_DIR/objects` directory of the source repository. Users may clone the repository again by prepending the "file://" scheme to their clone URL, or by adding the `--no-local` option to their `git clone` invocation. The directory iterator used by `copy_or_link_directory()` must no longer dereference symlinks (i.e., it *must* call `lstat()` instead of `stat()` in order to discover whether or not there are symlinks present). This has no bearing on the overall behavior, since we will immediately `die()` on encounter a symlink. Note that t5604.33 suggests that we do support local clones with symbolic links in the source repository's objects directory, but this was likely unintentional, or at least did not take into consideration the problem with sharing parts of the objects directory with symbolic links at the time. Update this test to reflect which options are and aren't supported. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Taylor Blau <me@ttaylorr.com> | 01 October 2022, 04:23:38 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 |
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 |
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 |
09f66d6 | Junio C Hamano | 13 April 2022, 22:21:08 UTC | Git 2.31.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 22:21:08 UTC |
17083c7 | Junio C Hamano | 13 April 2022, 20:31:29 UTC | Git 2.30.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 20:31:29 UTC |
0f85c4a | Derrick Stolee | 13 April 2022, 15:32:31 UTC | setup: opt-out of check with safe.directory=* With the addition of the safe.directory in 8959555ce (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02) released in v2.35.2, we are receiving feedback from a variety of users about the feature. Some users have a very large list of shared repositories and find it cumbersome to add this config for every one of them. In a more difficult case, certain workflows involve running Git commands within containers. The container boundary prevents any global or system config from communicating `safe.directory` values from the host into the container. Further, the container almost always runs as a different user than the owner of the directory in the host. To simplify the reactions necessary for these users, extend the definition of the safe.directory config value to include a possible '*' value. This value implies that all directories are safe, providing a single setting to opt-out of this protection. Note that an empty assignment of safe.directory clears all previous values, and this is already the case with the "if (!value || !*value)" condition. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 19:42:51 UTC |
bb50ec3 | Matheus Valadares | 13 April 2022, 15:32:30 UTC | setup: fix safe.directory key not being checked It seems that nothing is ever checking to make sure the safe directories in the configs actually have the key safe.directory, so some unrelated config that has a value with a certain directory would also make it a safe directory. Signed-off-by: Matheus Valadares <me@m28.io> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 19:42:51 UTC |
e47363e | Derrick Stolee | 13 April 2022, 15:32:29 UTC | t0033: add tests for safe.directory It is difficult to change the ownership on a directory in our test suite, so insert a new GIT_TEST_ASSUME_DIFFERENT_OWNER environment variable to trick Git into thinking we are in a differently-owned directory. This allows us to test that the config is parsed correctly. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 19:42:49 UTC |
87ed4fc | Johannes Schindelin | 17 March 2022, 09:57:44 UTC | Git 2.33.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:31:32 UTC |
303b876 | Johannes Schindelin | 17 March 2022, 09:57:43 UTC | Sync with 2.32.1 * maint-2.32: Git 2.32.1 Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:31:32 UTC |
9bcd7a8 | Johannes Schindelin | 17 March 2022, 09:57:38 UTC | Git 2.32.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:31:29 UTC |
201b0c7 | Johannes Schindelin | 17 March 2022, 09:57:37 UTC | Sync with 2.31.2 * maint-2.31: Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:31:28 UTC |
44de39c | Johannes Schindelin | 17 March 2022, 09:57:32 UTC | Git 2.31.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:24:29 UTC |
6a2381a | Johannes Schindelin | 17 March 2022, 09:57:31 UTC | Sync with 2.30.3 * maint-2.30: Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:24:29 UTC |
cb95038 | Johannes Schindelin | 17 March 2022, 09:15:15 UTC | Git 2.30.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:22:17 UTC |
fdcad5a | Johannes Schindelin | 23 March 2022, 22:00:41 UTC | Fix `GIT_CEILING_DIRECTORIES` with `C:\` and the likes When determining the length of the longest ancestor of a given path with respect to to e.g. `GIT_CEILING_DIRECTORIES`, we special-case the root directory by returning 0 (i.e. we pretend that the path `/` does not end in a slash by virtually stripping it). That is the correct behavior because when normalizing paths, the root directory is special: all other directory paths have their trailing slash stripped, but not the root directory's path (because it would become the empty string, which is not a legal path). However, this special-casing of the root directory in `longest_ancestor_length()` completely forgets about Windows-style root directories, e.g. `C:\`. These _also_ get normalized with a trailing slash (because `C:` would actually refer to the current directory on that drive, not necessarily to its root directory). In fc56c7b34b (mingw: accomodate t0060-path-utils for MSYS2, 2016-01-27), we almost got it right. We noticed that `longest_ancestor_length()` expects a slash _after_ the matched prefix, and if the prefix already ends in a slash, the normalized path won't ever match and -1 is returned. But then that commit went astray: The correct fix is not to adjust the _tests_ to expect an incorrect -1 when that function is fed a prefix that ends in a slash, but instead to treat such a prefix as if the trailing slash had been removed. Likewise, that function needs to handle the case where it is fed a path that ends in a slash (not only a prefix that ends in a slash): if it matches the prefix (plus trailing slash), we still need to verify that the path does not end there, otherwise the prefix is not actually an ancestor of the path but identical to it (and we need to return -1 in that case). With these two adjustments, we no longer need to play games in t0060 where we only add `$rootoff` if the passed prefix is different from the MSYS2 pseudo root, instead we also add it for the MSYS2 pseudo root itself. We do have to be careful to skip that logic entirely for Windows paths, though, because they do are not subject to that MSYS2 pseudo root treatment. This patch fixes the scenario where a user has set `GIT_CEILING_DIRECTORIES=C:\`, which would be ignored otherwise. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:21:08 UTC |
8959555 | Johannes Schindelin | 02 March 2022, 11:23:04 UTC | setup_git_directory(): add an owner check for the top-level directory It poses a security risk to search for a git directory outside of the directories owned by the current user. For example, it is common e.g. in computer pools of educational institutes to have a "scratch" space: a mounted disk with plenty of space that is regularly swiped where any authenticated user can create a directory to do their work. Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. The same holds true in multi-user setups running Windows, as `C:\` is writable to every authenticated user by default. To plug this vulnerability, we stop Git from accepting top-level directories owned by someone other than the current user. We avoid looking at the ownership of each and every directories between the current and the top-level one (if there are any between) to avoid introducing a performance bottleneck. This new default behavior is obviously incompatible with the concept of shared repositories, where we expect the top-level directory to be owned by only one of its legitimate users. To re-enable that use case, we add support for adding exceptions from the new default behavior via the config setting `safe.directory`. The `safe.directory` config setting is only respected in the system and global configs, not from repository configs or via the command-line, and can have multiple values to allow for multiple shared repositories. We are particularly careful to provide a helpful message to any user trying to use a shared repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 21 March 2022, 12:16:26 UTC |
bdc77d1 | Johannes Schindelin | 02 March 2022, 10:06:24 UTC | Add a function to determine whether a path is owned by the current user This function will be used in the next commit to prevent `setup_git_directory()` from discovering a repository in a directory that is owned by someone other than the current user. Note: We cannot simply use `st.st_uid` on Windows just like we do on Linux and other Unix-like platforms: according to https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions this field is always zero on Windows (because Windows' idea of a user ID does not fit into a single numerical value). Therefore, we have to do something a little involved to replicate the same functionality there. Also note: On Windows, a user's home directory is not actually owned by said user, but by the administrator. For all practical purposes, it is under the user's control, though, therefore we pretend that it is owned by the user. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 21 March 2022, 12:16:26 UTC |
2a9a586 | Johannes Schindelin | 17 March 2022, 11:52:12 UTC | Merge branch 'cb/mingw-gmtime-r' Build fix on Windows. * cb/mingw-gmtime-r: mingw: avoid fallback for {local,gm}time_r() Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 17 March 2022, 11:52:12 UTC |
6e7ad1e | Carlo Marcelo Arenas Belón | 27 November 2021, 10:15:32 UTC | mingw: avoid fallback for {local,gm}time_r() mingw-w64's pthread_unistd.h had a bug that mistakenly (because there is no support for the *lockfile() functions required[1]) defined _POSIX_THREAD_SAFE_FUNCTIONS and that was being worked around since 3ecd153a3b (compat/mingw: support MSys2-based MinGW build, 2016-01-14). The bug was fixed in winphtreads, but as a side effect, leaves the reentrant functions from time.h no longer visible and therefore breaks the build. Since the intention all along was to avoid using the fallback functions, formalize the use of POSIX by setting the corresponding feature flag and compile out the implementation for the fallback functions. [1] https://unix.org/whitepapers/reentrant.html Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 March 2022, 11:52:12 UTC |
898225b | Johannes Schindelin | 17 March 2022, 09:35:52 UTC | GIT-VERSION-GEN: bump to v2.33.1 This was missed in af6d1d602a8f (Git 2.33.1, 2021-10-12). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 17 March 2022, 09:35:52 UTC |
5fbd2fc | Junio C Hamano | 04 November 2021, 19:24:20 UTC | Merge branch 'vd/pthread-setspecific-g11-fix' into maint One CI task based on Fedora image noticed a not-quite-kosher consturct recently, which has been corrected. * vd/pthread-setspecific-g11-fix: async_die_is_recursing: work around GCC v11.x issue on Fedora | 04 November 2021, 19:24:20 UTC |
494cb27 | Junio C Hamano | 04 November 2021, 19:22:10 UTC | Merge branch 'ma/doc-git-version' into maint Typofix. * ma/doc-git-version: git.txt: fix typo | 04 November 2021, 19:22:10 UTC |
ecb8d9d | Junio C Hamano | 04 November 2021, 19:20:14 UTC | Merge branch 'pw/rebase-r-fixes' into maint Regression fix. * pw/rebase-r-fixes: rebase -i: fix rewording with --committer-date-is-author-date | 04 November 2021, 19:20:14 UTC |
99c7db5 | Junio C Hamano | 04 November 2021, 19:20:13 UTC | Merge branch 'jk/log-warn-on-bogus-encoding' into maint Squelch over-eager warning message added during this cycle. * jk/log-warn-on-bogus-encoding: log: document --encoding behavior on iconv() failure Revert "logmsg_reencode(): warn when iconv() fails" | 04 November 2021, 19:20:13 UTC |
4b540cf | Victoria Dye | 04 November 2021, 04:01:03 UTC | async_die_is_recursing: work around GCC v11.x issue on Fedora This fix corrects an issue found in the `dockerized(pedantic, fedora)` CI build, first appearing after the introduction of a new version of the Fedora docker image version. This image includes a version of `glibc` with the attribute `__attr_access_none` added to `pthread_setspecific` [1], the implementation of which only exists for GCC 11.X - the version included in the Fedora image. The attribute requires that the pointer provided in the second argument of `pthread_getspecific` must, if not NULL, be a pointer to a valid object. In the usage in `async_die_is_recursing`, `(void *)1` is not valid, causing the error. This fix imitates a workaround added in SELinux [2] by using the pointer to the static `async_die_counter` itself as the second argument to `pthread_setspecific`. This guaranteed non-NULL, valid pointer matches the intent of the current usage while not triggering the build error. [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a1561c3bbe8 [2] https://lore.kernel.org/all/20211021140519.6593-1-cgzones@googlemail.com/ Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Victoria Dye <vdye@github.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 04 November 2021, 06:12:10 UTC |
9d6b9df | Phillip Wood | 02 November 2021, 21:30:51 UTC | rebase -i: fix rewording with --committer-date-is-author-date baf8ec8d3a (rebase -r: don't write .git/MERGE_MSG when fast-forwarding, 2021-08-20) stopped reading the author script in run_git_commit() when rewording a commit. This is normally safe because "git commit --amend" preserves the authorship. However if the user passes "--committer-date-is-author-date" then we need to read the author date from the author script when rewording. Fix this regression by tightening the check for when it is safe to skip reading the author script. Reported-by: Jonas Kittner <jonas.kittner@ruhr-uni-bochum.de> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 03 November 2021, 17:44:45 UTC |
9e8fe7b | Jeff King | 29 October 2021, 21:10:03 UTC | log: document --encoding behavior on iconv() failure We already note that we may produce invalid output when we skip calling iconv() altogether. But we may also do so if iconv() fails, and we have no good alternative. Let's document this to avoid surprising users. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 29 October 2021, 21:35:59 UTC |
0988e66 | Junio C Hamano | 29 October 2021, 20:48:58 UTC | Revert "logmsg_reencode(): warn when iconv() fails" This reverts commit fd680bc5 (logmsg_reencode(): warn when iconv() fails, 2021-08-27). Throwing a warning for each and every commit that gets reencoded, without allowing a way to squelch, would make it unpleasant for folks who have to deal with an ancient part of the history in an old project that used wrong encoding in the commits. | 29 October 2021, 20:48:58 UTC |
82a57cd | Martin Ågren | 24 October 2021, 17:08:20 UTC | git.txt: fix typo Fix the spelling of "internally". Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 October 2021, 17:19:30 UTC |
af6d1d6 | Junio C Hamano | 12 October 2021, 20:51:59 UTC | Git 2.33.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 October 2021, 20:51:59 UTC |
9e25a2e | Junio C Hamano | 12 October 2021, 20:51:49 UTC | Merge branch 'ah/connect-parse-feature-v0-fix' into maint Protocol v0 clients can get stuck parsing a malformed feature line. * ah/connect-parse-feature-v0-fix: connect: also update offset for features without values | 12 October 2021, 20:51:49 UTC |
bbfc821 | Junio C Hamano | 12 October 2021, 20:51:49 UTC | Merge branch 'ab/make-clean-depend-dirs' into maint "make clean" has been updated to remove leftover .depend/ directories, even when it is not told to use them to compute header dependencies. * ab/make-clean-depend-dirs: Makefile: clean .depend dirs under COMPUTE_HEADER_DEPENDENCIES != yes | 12 October 2021, 20:51:49 UTC |
77edbde | Junio C Hamano | 12 October 2021, 20:51:48 UTC | Merge branch 'jk/http-redact-fix' into maint Sensitive data in the HTTP trace were supposed to be redacted, but we failed to do so in HTTP/2 requests. * jk/http-redact-fix: http: match headers case-insensitively when redacting | 12 October 2021, 20:51:48 UTC |
ef09a7f | Junio C Hamano | 12 October 2021, 20:51:48 UTC | Merge branch 'da/difftool-dir-diff-symlink-fix' into maint "git difftool --dir-diff" mishandled symbolic links. * da/difftool-dir-diff-symlink-fix: difftool: fix symlink-file writing in dir-diff mode | 12 October 2021, 20:51:48 UTC |
b59c060 | Junio C Hamano | 12 October 2021, 20:51:48 UTC | Merge branch 'cb/cvsserver' into maint "git cvsserver" had a long-standing bug in its authentication code, which has finally been corrected (it is unclear and is a separate question if anybody is seriously using it, though). * cb/cvsserver: Documentation: cleanup git-cvsserver git-cvsserver: protect against NULL in crypt(3) git-cvsserver: use crypt correctly to compare password hashes | 12 October 2021, 20:51:48 UTC |
c365967 | Junio C Hamano | 12 October 2021, 20:51:47 UTC | Merge branch 'jk/clone-unborn-head-in-bare' into maint "git clone" from a repository whose HEAD is unborn into a bare repository didn't follow the branch name the other side used, which is corrected. * jk/clone-unborn-head-in-bare: clone: handle unborn branch in bare repos | 12 October 2021, 20:51:47 UTC |
e61304f | Junio C Hamano | 12 October 2021, 20:51:47 UTC | Merge branch 'en/stash-df-fix' into maint "git stash", where the tentative change involves changing a directory to a file (or vice versa), was confused, which has been corrected. * en/stash-df-fix: stash: restore untracked files AFTER restoring tracked files stash: avoid feeding directories to update-index t3903: document a pair of directory/file bugs | 12 October 2021, 20:51:47 UTC |
9cfc01e | Junio C Hamano | 12 October 2021, 20:51:47 UTC | Merge branch 'jk/strvec-typefix' into maint Correct nr and alloc members of strvec struct to be of type size_t. * jk/strvec-typefix: strvec: use size_t to store nr and alloc | 12 October 2021, 20:51:47 UTC |
b809c3d | Junio C Hamano | 12 October 2021, 20:51:46 UTC | Merge branch 'en/am-abort-fix' into maint When "git am --abort" fails to abort correctly, it still exited with exit status of 0, which has been corrected. * en/am-abort-fix: am: fix incorrect exit status on am fail to abort t4151: add a few am --abort tests git-am.txt: clarify --abort behavior | 12 October 2021, 20:51:46 UTC |
b5f309d | Junio C Hamano | 12 October 2021, 20:51:46 UTC | Merge branch 'ps/update-ref-batch-flush' into maint "git update-ref --stdin" failed to flush its output as needed, which potentially led the conversation to a deadlock. * ps/update-ref-batch-flush: t1400: avoid SIGPIPE race condition on fifo update-ref: fix streaming of status updates | 12 October 2021, 20:51:46 UTC |
d64b99d | Junio C Hamano | 12 October 2021, 20:51:46 UTC | Merge branch 'rs/no-mode-to-open-when-appending' into maint The "mode" word is useless in a call to open(2) that does not create a new file. Such a call in the files backend of the ref subsystem has been cleaned up. * rs/no-mode-to-open-when-appending: refs/files-backend: remove unused open mode parameter | 12 October 2021, 20:51:46 UTC |
6287460 | Junio C Hamano | 12 October 2021, 20:51:45 UTC | Merge branch 'tb/pack-finalize-ordering' into maint The order in which various files that make up a single (conceptual) packfile has been reevaluated and straightened up. This matters in correctness, as an incomplete set of files must not be shown to a running Git. * tb/pack-finalize-ordering: pack-objects: rename .idx files into place after .bitmap files pack-write: split up finish_tmp_packfile() function builtin/index-pack.c: move `.idx` files into place last index-pack: refactor renaming in final() builtin/repack.c: move `.idx` files into place last pack-write.c: rename `.idx` files after `*.rev` pack-write: refactor renaming in finish_tmp_packfile() bulk-checkin.c: store checksum directly pack.h: line-wrap the definition of finish_tmp_packfile() | 12 October 2021, 20:51:46 UTC |
6aa501a | Junio C Hamano | 12 October 2021, 20:51:45 UTC | Merge branch 'rs/range-diff-avoid-segfault-with-I' into maint "git range-diff -I... <range> <range>" segfaulted, which has been corrected. * rs/range-diff-avoid-segfault-with-I: range-diff: avoid segfault with -I | 12 October 2021, 20:51:45 UTC |
79c887d | Junio C Hamano | 12 October 2021, 20:51:45 UTC | Merge branch 'ab/reverse-midx-optim' into maint The code that optionally creates the *.rev reverse index file has been optimized to avoid needless computation when it is not writing the file out. * ab/reverse-midx-optim: pack-write: skip *.rev work when not writing *.rev | 12 October 2021, 20:51:45 UTC |
62a7648 | Junio C Hamano | 12 October 2021, 20:51:44 UTC | Merge branch 'jc/trivial-threeway-binary-merge' into maint The "git apply -3" code path learned not to bother the lower level merge machinery when the three-way merge can be trivially resolved without the content level merge. * jc/trivial-threeway-binary-merge: apply: resolve trivial merge without hitting ll-merge with "--3way" | 12 October 2021, 20:51:45 UTC |
1af6324 | Junio C Hamano | 12 October 2021, 20:51:44 UTC | Merge branch 'ab/send-email-config-fix' into maint Regression fix. * ab/send-email-config-fix: send-email: fix a "first config key wins" regression in v2.33.0 | 12 October 2021, 20:51:44 UTC |
bf4ca3f | Junio C Hamano | 12 October 2021, 20:51:44 UTC | Merge branch 'so/diff-index-regression-fix' into maint Recent "diff -m" changes broke "gitk", which has been corrected. * so/diff-index-regression-fix: diff-index: restore -c/--cc options handling | 12 October 2021, 20:51:44 UTC |
d9e2677 | Junio C Hamano | 12 October 2021, 20:51:43 UTC | Merge branch 'jk/log-warn-on-bogus-encoding' into maint Doc update plus improved error reporting. * jk/log-warn-on-bogus-encoding: docs: use "character encoding" to refer to commit-object encoding logmsg_reencode(): warn when iconv() fails | 12 October 2021, 20:51:43 UTC |
48939c5 | Junio C Hamano | 12 October 2021, 20:51:43 UTC | Merge branch 'tk/fast-export-anonymized-tag-fix' into maint The output from "git fast-export", when its anonymization feature is in use, showed an annotated tag incorrectly. * tk/fast-export-anonymized-tag-fix: fast-export: fix anonymized tag using original length | 12 October 2021, 20:51:43 UTC |
f11b01b | Junio C Hamano | 12 October 2021, 20:51:43 UTC | Merge branch 'mh/send-email-reset-in-reply-to' into maint Even when running "git send-email" without its own threaded discussion support, a threading related header in one message is carried over to the subsequent message to result in an unwanted threading, which has been corrected. * mh/send-email-reset-in-reply-to: send-email: avoid incorrect header propagation | 12 October 2021, 20:51:43 UTC |
e4bea4a | Junio C Hamano | 12 October 2021, 20:51:42 UTC | Merge branch 'sg/set-ceiling-during-tests' into maint Buggy tests could damage repositories outside the throw-away test area we created. We now by default export GIT_CEILING_DIRECTORIES to limit the damage from such a stray test. * sg/set-ceiling-during-tests: test-lib: set GIT_CEILING_DIRECTORIES to protect the surrounding repository | 12 October 2021, 20:51:42 UTC |
a45b824 | Junio C Hamano | 12 October 2021, 20:51:42 UTC | Merge branch 'jh/sparse-index-resize-fix' into maint The sparse-index support can corrupt the index structure by storing a stale and/or uninitialized data, which has been corrected. * jh/sparse-index-resize-fix: sparse-index: copy dir_hash in ensure_full_index() | 12 October 2021, 20:51:42 UTC |
0a5af02 | Junio C Hamano | 12 October 2021, 20:51:42 UTC | Merge branch 'ka/want-ref-in-namespace' into maint "git upload-pack" which runs on the other side of "git fetch" forgot to take the ref namespaces into account when handling want-ref requests. * ka/want-ref-in-namespace: docs: clarify the interaction of transfer.hideRefs and namespaces upload-pack.c: treat want-ref relative to namespace t5730: introduce fetch command helper | 12 October 2021, 20:51:42 UTC |
69247e2 | Junio C Hamano | 12 October 2021, 20:51:41 UTC | Merge branch 'sg/column-nl' into maint The parser for the "--nl" option of "git column" has been corrected. * sg/column-nl: column: fix parsing of the '--nl' option | 12 October 2021, 20:51:41 UTC |
689cfaf | Junio C Hamano | 12 October 2021, 20:51:41 UTC | Merge branch 'cb/makefile-apple-clang' into maint Build update for Apple clang. * cb/makefile-apple-clang: build: catch clang that identifies itself as "$VENDOR clang" build: clang version may not be followed by extra words build: update detect-compiler for newer Xcode version | 12 October 2021, 20:51:41 UTC |
474e4f9 | Junio C Hamano | 12 October 2021, 20:51:41 UTC | Merge branch 'rs/branch-allow-deleting-dangling' into maint "git branch -D <branch>" used to refuse to remove a broken branch ref that points at a missing commit, which has been corrected. * rs/branch-allow-deleting-dangling: branch: allow deleting dangling branches with --force | 12 October 2021, 20:51:41 UTC |
cd9a57f | Junio C Hamano | 12 October 2021, 20:51:40 UTC | Merge branch 'mt/quiet-with-delayed-checkout' into maint The delayed checkout code path in "git checkout" etc. were chatty even when --quiet and/or --no-progress options were given. * mt/quiet-with-delayed-checkout: checkout: make delayed checkout respect --quiet and --no-progress | 12 October 2021, 20:51:40 UTC |
872c9e6 | Junio C Hamano | 12 October 2021, 20:51:40 UTC | Merge branch 'dd/diff-files-unmerged-fix' into maint "git diff --relative" segfaulted and/or produced incorrect result when there are unmerged paths. * dd/diff-files-unmerged-fix: diff-lib: ignore paths that are outside $cwd if --relative asked | 12 October 2021, 20:51:40 UTC |
ae9e6ef | Junio C Hamano | 12 October 2021, 20:51:39 UTC | Merge branch 'rs/git-mmap-uses-malloc' into maint mmap() imitation used to call xmalloc() that dies upon malloc() failure, which has been corrected to just return an error to the caller to be handled. * rs/git-mmap-uses-malloc: compat: let git_mmap use malloc(3) directly | 12 October 2021, 20:51:40 UTC |
3fb1d4d | Junio C Hamano | 12 October 2021, 20:51:39 UTC | Merge branch 'pw/rebase-r-fixes' into maint Various bugs in "git rebase -r" have been fixed. * pw/rebase-r-fixes: rebase -r: fix merge -c with a merge strategy rebase -r: don't write .git/MERGE_MSG when fast-forwarding rebase -i: add another reword test rebase -r: make 'merge -c' behave like reword | 12 October 2021, 20:51:39 UTC |
8b02ffe | Junio C Hamano | 12 October 2021, 20:51:39 UTC | Merge branch 'pw/rebase-skip-final-fix' into maint Checking out all the paths from HEAD during the last conflicted step in "git rebase" and continuing would cause the step to be skipped (which is expected), but leaves MERGE_MSG file behind in $GIT_DIR and confuses the next "git commit", which has been corrected. * pw/rebase-skip-final-fix: rebase --continue: remove .git/MERGE_MSG rebase --apply: restore some tests t3403: fix commit authorship | 12 October 2021, 20:51:39 UTC |
ff09581 | Junio C Hamano | 12 October 2021, 20:51:38 UTC | Merge branch 'cb/ci-use-upload-artifacts-v1' into maint Use upload-artifacts v1 (instead of v2) for 32-bit linux, as the new version has a blocker bug for that architecture. * cb/ci-use-upload-artifacts-v1: ci: use upload-artifacts v1 for dockerized jobs | 12 October 2021, 20:51:38 UTC |
444b854 | Junio C Hamano | 12 October 2021, 20:51:38 UTC | Merge branch 'jk/commit-edit-fixup-fix' into maint "git commit --fixup" now works with "--edit" again, after it was broken in v2.32. * jk/commit-edit-fixup-fix: commit: restore --edit when combined with --fixup | 12 October 2021, 20:51:38 UTC |
ee2b241 | Junio C Hamano | 12 October 2021, 20:51:38 UTC | Merge branch 'jk/range-diff-fixes' into maint "git range-diff" code clean-up. * jk/range-diff-fixes: range-diff: use ssize_t for parsed "len" in read_patches() range-diff: handle unterminated lines in read_patches() range-diff: drop useless "offset" variable from read_patches() | 12 October 2021, 20:51:38 UTC |