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.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.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 |
---|---|---|---|---|
47ae905 | Junio C Hamano | 27 July 2020, 01:01:43 UTC | Git 2.28 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 27 July 2020, 01:01:43 UTC |
5c06d60 | Junio C Hamano | 26 July 2020, 16:48:11 UTC | Merge tag 'l10n-2.28.0-rnd1' of https://www.github.com/git-l10n/git-po into master l10n-2.28.0-rnd1 * tag 'l10n-2.28.0-rnd1' of https://www.github.com/git-l10n/git-po: l10n: es: 2.28.0 round 1 l10n: de.po: Update German translation for Git v2.28.0 l10n: de.po: fix grammar l10n: zh_CN: for git v2.28.0 l10n round 1 l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated) l10n: vi.po: correct "ident line" translation l10n: vi.po(4931t): Updated translation for v2.28.0 l10n: fr v2.28.0 round 1 l10n: sv.po: Update Swedish translation (4931t0f0u) l10n: it.po: update the Italian translation for Git 2.28.0 round 1 l10n: tr: v2.28.0 round 1 l10n: git.pot: v2.28.0 round 1 (70 new, 14 removed) l10n: Update Catalan translation | 26 July 2020, 16:48:11 UTC |
05b3a3d | Jiang Xin | 26 July 2020, 16:05:41 UTC | Merge branch 'master' of github.com:Softcatala/git-po * 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation | 26 July 2020, 16:05:41 UTC |
7b0e326 | Christopher Diaz Riveros | 26 July 2020, 15:12:01 UTC | l10n: es: 2.28.0 round 1 Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com> | 26 July 2020, 15:12:01 UTC |
418cca9 | Junio C Hamano | 24 July 2020, 22:54:05 UTC | Merge branch 'ps/ref-transaction-hook' into master A new hook. * ps/ref-transaction-hook: githooks.txt: use correct "reference-transaction" hook name | 24 July 2020, 22:54:06 UTC |
6c18d03 | Bojun Chen | 24 July 2020, 13:57:57 UTC | githooks.txt: use correct "reference-transaction" hook name The "reference transaction" hook was introduced in commit 6754159767 (refs: implement reference transaction hook, 2020-06-19). The name of the hook is declared as "reference-transaction" in "refs.c" and testcases, but the name declared in "githooks.txt" is different. Signed-off-by: Bojun Chen <bojun.cbj@alibaba-inc.com> Reviewed-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 24 July 2020, 20:53:58 UTC |
45f83df | Matthias Rüster | 12 July 2020, 11:18:30 UTC | l10n: de.po: Update German translation for Git v2.28.0 Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> | 24 July 2020, 18:35:30 UTC |
7112e05 | Ralf Thielow | 05 July 2020, 15:35:21 UTC | l10n: de.po: fix grammar Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> | 24 July 2020, 18:33:38 UTC |
3d20111 | Taylor Blau | 22 July 2020, 20:29:40 UTC | Documentation/RelNotes: fix a typo in 2.28's relnotes Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 22 July 2020, 21:10:20 UTC |
b066807 | Junio C Hamano | 22 July 2020, 16:30:01 UTC | Git 2.28-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 22 July 2020, 16:30:01 UTC |
cfa7ae8 | Junio C Hamano | 21 July 2020, 21:19:09 UTC | Merge branch 'en/sparse-status' into master Fix to a "git prompt" regression during this development cycle. * en/sparse-status: git-prompt: change == to = for zsh's sake | 21 July 2020, 21:19:10 UTC |
7157c2b | Jiang Xin | 10 July 2020, 02:32:01 UTC | l10n: zh_CN: for git v2.28.0 l10n round 1 Translate 70 new messages (4931t0f0u) for git 2.28.0. Reviewed-by: Fangyi Zhou <me@fangyi.io> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 21 July 2020, 08:31:13 UTC |
0c5ead4 | Jiang Xin | 21 July 2020, 08:00:54 UTC | Merge branch 'l10n/zh_TW/200716' of github.com:l10n-tw/git-po * 'l10n/zh_TW/200716' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated) | 21 July 2020, 08:00:54 UTC |
e8882a8 | David J. Malan | 21 July 2020, 00:15:31 UTC | git-prompt: change == to = for zsh's sake When using git-prompt.sh with zsh, __git_ps1 currently errs when inside a repo with: __git_ps1:96: = not found Avoid using non-portable "==" that is only understood by bash and not zsh. Change to "=" so that the prompt script becomes usable with zsh again. Signed-off-by: David J. Malan <malan@harvard.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 July 2020, 00:37:20 UTC |
e7ae437 | Junio C Hamano | 20 July 2020, 19:04:06 UTC | Merge https://github.com/prati0100/git-gui into master * https://github.com/prati0100/git-gui: git-gui: allow opening work trees from the startup dialog | 20 July 2020, 19:04:06 UTC |
6b77569 | Yi-Jyun Pan | 16 July 2020, 10:40:58 UTC | l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated) Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com> | 20 July 2020, 10:39:27 UTC |
877c10b | Đoàn Trần Công Danh | 16 July 2020, 13:32:51 UTC | l10n: vi.po: correct "ident line" translation While we're at it, fix some minor misspelling and improve translation for 3-way-merging. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> | 20 July 2020, 01:55:12 UTC |
ebf9785 | Tran Ngoc Quan | 15 July 2020, 08:31:56 UTC | l10n: vi.po(4931t): Updated translation for v2.28.0 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> | 20 July 2020, 01:54:50 UTC |
ae46588 | Junio C Hamano | 18 July 2020, 23:35:22 UTC | Merge branch 'dl/branch-cleanup' into master Last minute fix-up to tests for portability. * dl/branch-cleanup: t3200: don't grep for `strerror()` string | 18 July 2020, 23:35:22 UTC |
00a7a21 | Junio C Hamano | 18 July 2020, 23:35:21 UTC | Merge branch 'js/pu-to-seen' into master Last minute fix-up to documentation. * js/pu-to-seen: gitworkflows.txt: fix broken subsection underline | 18 July 2020, 23:35:22 UTC |
d400cb0 | Junio C Hamano | 18 July 2020, 23:35:20 UTC | Merge branch 'jc/relnotes-v0-extension-update' into master Last minute fix-up to the release notes. * jc/relnotes-v0-extension-update: RelNotes: update the v0 with extension situation | 18 July 2020, 23:35:20 UTC |
d223e85 | Martin Ågren | 18 July 2020, 09:48:40 UTC | t3200: don't grep for `strerror()` string In 6b7093064a ("t3200: test for specific errors", 2020-06-15), we learned to grep stderr to ensure that the failing `git branch` invocations fail for the right reason. In two of these tests, we grep for "File exists", expecting the string to show up there since config.c calls `error_errno()`, which ends up including `strerror(errno)` in the error message. But as we saw in 4605a73073 ("t1091: don't grep for `strerror()` string", 2020-03-08), there exists at least one implementation where `strerror()` yields a slightly different string than the one we're grepping for. In particular, these tests fail on the NonStop platform. Similar to 4605a73073, grep for the beginning of the string instead to avoid relying on `strerror()` behavior. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 July 2020, 20:47:05 UTC |
ca8bb50 | Martin Ågren | 18 July 2020, 20:17:23 UTC | gitworkflows.txt: fix broken subsection underline AsciiDoctor renders the "~~~~~~~~~" literally. That's not our intention: it is supposed to indicate a level 2 subsection. In 828197de8f ("docs: adjust for the recent rename of `pu` to `seen`", 2020-06-25), the length of this section header grew by two characters but we didn't adjust the number of ~ characters accordingly. AsciiDoc handles this discrepancy ok and still picks this up as a subsection title, but Asciidoctor is not as forgiving. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 July 2020, 20:43:34 UTC |
1e1a30b | Junio C Hamano | 17 July 2020, 20:33:04 UTC | RelNotes: update the v0 with extension situation With the two-patch series for regression fix, to the users from 2.27 days, there is no visible behaviour change---we do not warn and fail use of v0 repositories with newer extensions yet, so there is nothing to note in the backward compatibility section. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 July 2020, 20:33:04 UTC |
3ddac3d | Junio C Hamano | 17 July 2020, 01:02:52 UTC | Git 2.28-rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 July 2020, 01:02:52 UTC |
d13b7f2 | Junio C Hamano | 17 July 2020, 00:58:42 UTC | Merge branch 'jn/v0-with-extensions-fix' into master In 2.28-rc0, we corrected a bug that some repository extensions are honored by mistake even in a version 0 repositories (these configuration variables in extensions.* namespace were supposed to have special meaning in repositories whose version numbers are 1 or higher), but this was a bit too big a change. * jn/v0-with-extensions-fix: repository: allow repository format upgrade with extensions Revert "check_repository_format_gently(): refuse extensions for old repositories" | 17 July 2020, 00:58:42 UTC |
62f2eca | Jonathan Nieder | 16 July 2020, 06:28:18 UTC | repository: allow repository format upgrade with extensions Now that we officially permit repository extensions in repository format v0, permit upgrading a repository with extensions from v0 to v1 as well. For example, this means a repository where the user has set "extensions.preciousObjects" can use "git fetch --filter=blob:none origin" to upgrade the repository to use v1 and the partial clone extension. To avoid mistakes, continue to forbid repository format upgrades in v0 repositories with an unrecognized extension. This way, a v0 user using a misspelled extension field gets a chance to correct the mistake before updating to the less forgiving v1 format. While we're here, make the error message for failure to upgrade the repository format a bit shorter, and present it as an error, not a warning. Reported-by: Huan Huan Chen <huanhuanchen@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 16 July 2020, 16:36:39 UTC |
1166419 | Jonathan Nieder | 16 July 2020, 06:24:29 UTC | Revert "check_repository_format_gently(): refuse extensions for old repositories" This reverts commit 14c7fa269e42df4133edd9ae7763b678ed6594cd. The core.repositoryFormatVersion field was introduced in ab9cb76f661 (Repository format version check., 2005-11-25), providing a welcome bit of forward compatibility, thanks to some welcome analysis by Martin Atukunda. The semantics are simple: a repository with core.repositoryFormatVersion set to 0 should be comprehensible by all Git implementations in active use; and Git implementations should error out early instead of trying to act on Git repositories with higher core.repositoryFormatVersion values representing new formats that they do not understand. A new repository format did not need to be defined until 00a09d57eb8 (introduce "extensions" form of core.repositoryformatversion, 2015-06-23). This provided a finer-grained extension mechanism for Git repositories. In a repository with core.repositoryFormatVersion set to 1, Git implementations can act on "extensions.*" settings that modify how a repository is interpreted. In repository format version 1, unrecognized extensions settings cause Git to error out. What happens if a user sets an extension setting but forgets to increase the repository format version to 1? The extension settings were still recognized in that case; worse, unrecognized extensions settings do *not* cause Git to error out. So combining repository format version 0 with extensions settings produces in some sense the worst of both worlds. To improve that situation, since 14c7fa269e4 (check_repository_format_gently(): refuse extensions for old repositories, 2020-06-05) Git instead ignores extensions in v0 mode. This way, v0 repositories get the historical (pre-2015) behavior and maintain compatibility with Git implementations that do not know about the v1 format. Unfortunately, users had been using this sort of configuration and this behavior change came to many as a surprise: - users of "git config --worktree" that had followed its advice to enable extensions.worktreeConfig (without also increasing the repository format version) would find their worktree configuration no longer taking effect - tools such as copybara[*] that had set extensions.partialClone in existing repositories (without also increasing the repository format version) would find that setting no longer taking effect The behavior introduced in 14c7fa269e4 might be a good behavior if we were traveling back in time to 2015, but we're far too late. For some reason I thought that it was what had been originally implemented and that it had regressed. Apologies for not doing my research when 14c7fa269e4 was under development. Let's return to the behavior we've had since 2015: always act on extensions.* settings, regardless of repository format version. While we're here, include some tests to describe the effect on the "upgrade repository version" code path. [*] https://github.com/google/copybara/commit/ca76c0b1e13c4e36448d12c2aba4a5d9d98fb6e7 Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 16 July 2020, 16:36:37 UTC |
b6a658b | Junio C Hamano | 15 July 2020, 23:29:51 UTC | Hopefully the last batch before -rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 15 July 2020, 23:29:51 UTC |
d1ae8ba | Junio C Hamano | 15 July 2020, 23:29:45 UTC | Merge branch 'tb/commit-graph-no-check-oids' into master Fix to the code to produce progress bar, which is new in the upcoming release. * tb/commit-graph-no-check-oids: commit-graph: fix "Collecting commits from input" progress line | 15 July 2020, 23:29:45 UTC |
1863dbd | Junio C Hamano | 15 July 2020, 23:29:44 UTC | Merge branch 'ct/diff-with-merge-base-clarification' into master Doc update. * ct/diff-with-merge-base-clarification: git-diff.txt: reorder possible usages git-diff.txt: don't mark required argument as optional | 15 July 2020, 23:29:44 UTC |
12f5eb9 | Junio C Hamano | 15 July 2020, 23:29:43 UTC | Merge branch 'sg/commit-graph-progress-fix' into master The code to produce progress output from "git commit-graph --write" had a few breakages, which have been fixed. * sg/commit-graph-progress-fix: commit-graph: fix "Writing out commit graph" progress counter commit-graph: fix progress of reachable commits | 15 July 2020, 23:29:43 UTC |
05920f0 | Junio C Hamano | 15 July 2020, 23:29:43 UTC | Merge branch 'ta/wait-on-aliased-commands-upon-signal' into master When an aliased command, whose output is piped to a pager by git, gets killed by a signal, the pager got into a funny state, which has been corrected (again). * ta/wait-on-aliased-commands-upon-signal: Wait for child on signal death for aliases to externals Wait for child on signal death for aliases to builtins | 15 July 2020, 23:29:43 UTC |
862aead | SZEDER Gábor | 10 July 2020, 19:02:38 UTC | commit-graph: fix "Collecting commits from input" progress line To display a progress line while reading commits from standard input and looking them up, 5b6653e523 (builtin/commit-graph.c: dereference tags in builtin, 2020-05-13) should have added a pair of start_delayed_progress() and stop_progress() calls around the loop reading stdin. Alas, the stop_progress() call ended up at the wrong place, after write_commit_graph(), which does all the commit-graph computation and writing, and has several progress lines of its own. Consequently, that new Collecting commits from input: 1234 progress line is overwritten by the first progress line shown by write_commit_graph(), and its final "done" line is shown last, after everything is finished: $ { sleep 3 ; git rev-list -3 HEAD ; sleep 1 ; } | ~/src/git/git commit-graph write --stdin-commits Expanding reachable commits in commit graph: 873402, done. Writing out commit graph in 4 passes: 100% (3493608/3493608), done. Collecting commits from input: 3, done. Furthermore, that stop_progress() call was added after the 'cleanup' label, where that loop reading stdin jumps in case of an error. In case of invalid input this then results in the "done" line shown after the error message: $ { sleep 3 ; git rev-list -3 HEAD ; echo junk ; } | ~/src/git/git commit-graph write --stdin-commits error: unexpected non-hex object ID: junk Collecting commits from input: 3, done. Move that stop_progress() call to the right place. While at it, drop the unnecessary 'if (progress)' condition protecting the stop_progress() call, because that function is prepared to handle a NULL progress struct. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 15 July 2020, 18:57:19 UTC |
78b76d3 | Martin Ågren | 13 July 2020, 19:10:09 UTC | git-diff.txt: reorder possible usages The description of `git diff` goes through several different invocations (numbering added by me): 1. git diff [<options>] [--] [<path>...] 2. git diff [<options>] --no-index [--] <path> <path> 3. git diff [<options>] --cached [<commit>] [--] [<path>...] 4. git diff [<options>] <commit> [--] [<path>...] 5. git diff [<options>] <commit> <commit> [--] [<path>...] 6. git diff [<options>] <commit>..<commit> [--] [<path>...] 7. git diff [<options>] <commit> <commit>... <commit> [--] [<path>...] 8. git diff [<options>] <commit>...<commit> [--] [<path>...] It then goes on to say that "all of the <commit> in the above description, except in the last two forms that use '..' notations, can be any <tree>". The "last two" actually refers to 6 and 8. This got out of sync in commit b7e10b2ca2 ("Documentation: usage for diff combined commits", 2020-06-12) which added item 7 to the mix. As a further complication, after b7e10b2ca2 we also have some potential confusion around "the '..' notation". The "..[.]" in items 6 and 8 are part of the rev notation, whereas the "..." in item 7 is manpage language for "one or more". Move item 6 down, i.e., to between 7 and 8, to restore the ordering. Because 6 refers to 5 ("synonymous to the previous form") we need to tweak the language a bit. An added bonus of this commit is that we're trying to steer users away from `git diff <commit>..<commit>` and moving it further down probably doesn't hurt. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 July 2020, 19:47:38 UTC |
bc5482e | Martin Ågren | 13 July 2020, 19:10:08 UTC | git-diff.txt: don't mark required argument as optional Commit b7e10b2ca2 ("Documentation: usage for diff combined commits", 2020-06-12) modified the synopsis by adding an optional "[<commit>...]" to 'git diff' [<options>] <commit> <commit> [--] [<path>...] to effectively add 'git diff' [<options>] <commit> <commit>... <commit> [--] [<path>...] as another valid invocation. Which makes sense. Further down, in the description, it left the existing entry for 'git diff' [<options>] <commit> <commit> [--] [<path>...] intact and added a new entry on 'git diff' [<options>] <commit> [<commit>...] <commit> [--] [<path>...] where it says that "[t]his form is to view the results of a merge commit" and details how "the first listed commit must be the merge itself". But one possible instantiation of this form is `git diff <commit> <commit>` for which the added text doesn't really apply. Remove the brackets so that we lose this overlap between the two descriptions. We can still use the more compact representation in the synopsis. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 July 2020, 19:47:36 UTC |
a4ef098 | Jiang Xin | 13 July 2020, 00:39:23 UTC | Merge branch 'fr_v2.28.0_rnd1' of github.com:jnavila/git * 'fr_v2.28.0_rnd1' of github.com:jnavila/git: l10n: fr v2.28.0 round 1 | 13 July 2020, 00:39:23 UTC |
0c7696e | Jean-Noël Avila | 12 July 2020, 16:15:44 UTC | l10n: fr v2.28.0 round 1 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> | 12 July 2020, 16:15:44 UTC |
186ae86 | Jiang Xin | 12 July 2020, 09:53:39 UTC | Merge branch 'master' of github.com:nafmo/git-l10n-sv * 'master' of github.com:nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (4931t0f0u) | 12 July 2020, 09:53:39 UTC |
f32ab4e | Peter Krefting | 11 July 2020, 16:52:35 UTC | l10n: sv.po: Update Swedish translation (4931t0f0u) Signed-off-by: Peter Krefting <peter@softwolves.pp.se> | 11 July 2020, 16:52:58 UTC |
dda29f3 | Alessandro Menti | 11 July 2020, 13:35:23 UTC | l10n: it.po: update the Italian translation for Git 2.28.0 round 1 Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it> | 11 July 2020, 13:38:10 UTC |
73d5056 | Emir Sarı | 10 July 2020, 10:07:30 UTC | l10n: tr: v2.28.0 round 1 Signed-off-by: Emir Sarı <bitigchi@me.com> | 10 July 2020, 10:07:30 UTC |
d84f4ab | Jiang Xin | 10 July 2020, 01:54:33 UTC | l10n: git.pot: v2.28.0 round 1 (70 new, 14 removed) Generate po/git.pot from v2.28.0-rc0 for git v2.28.0 l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 10 July 2020, 01:54:33 UTC |
bd42bbe | Junio C Hamano | 09 July 2020, 20:45:21 UTC | Git 2.28-rc0 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 July 2020, 21:00:45 UTC |
d341042 | Junio C Hamano | 09 July 2020, 21:00:45 UTC | Merge branch 'mt/entry-fstat-fallback-fix' into master "git checkout" failed to catch an error from fstat() after updating a path in the working tree. * mt/entry-fstat-fallback-fix: entry: check for fstat() errors after checkout | 09 July 2020, 21:00:45 UTC |
3ed0f1e | Junio C Hamano | 09 July 2020, 21:00:44 UTC | Merge branch 'ma/rebase-doc-typofix' into master Typofix. * ma/rebase-doc-typofix: git-rebase.txt: fix description list separator | 09 July 2020, 21:00:45 UTC |
9850823 | Junio C Hamano | 09 July 2020, 21:00:44 UTC | Merge branch 'jn/eject-fetch-write-commit-graph-out-of-experimental' into master "fetch.writeCommitGraph" was enabled when "feature.experimental" is asked for, but it was found to be a bit too risky even for bold folks in its current shape. The configuration has been ejected, at least for now, from the "experimental" feature set. * jn/eject-fetch-write-commit-graph-out-of-experimental: experimental: default to fetch.writeCommitGraph=false | 09 July 2020, 21:00:44 UTC |
24ecfdf | Junio C Hamano | 09 July 2020, 21:00:44 UTC | Merge branch 'tb/fix-persistent-shallow' into master When "fetch.writeCommitGraph" configuration is set in a shallow repository and a fetch moves the shallow boundary, we wrote out broken commit-graph files that do not match the reality, which has been corrected. * tb/fix-persistent-shallow: commit.c: don't persist substituted parents when unshallowing | 09 July 2020, 21:00:44 UTC |
46be023 | Junio C Hamano | 09 July 2020, 21:00:43 UTC | Merge branch 'ct/diff-with-merge-base-clarification' into master Recent update to "git diff" meant as a code clean-up introduced a bug in its error handling code, which has been corrected. * ct/diff-with-merge-base-clarification: diff: check for merge bases before assigning sym->base | 09 July 2020, 21:00:43 UTC |
20d451c | Junio C Hamano | 09 July 2020, 21:00:42 UTC | Merge branch 'rs/line-log-until' into master "git log -Lx,y:path --before=date" lost track of where the range should be because it didn't take the changes made by the youngest commits that are omitted from the output into account. * rs/line-log-until: revision: disable min_age optimization with line-log | 09 July 2020, 21:00:42 UTC |
b7ebe8f | Junio C Hamano | 09 July 2020, 21:00:42 UTC | Merge branch 'ra/send-email-in-reply-to-from-command-line-wins' into master "git send-email --in-reply-to=<msg>" did not use the In-Reply-To: header with the value given from the command line, and let it be overridden by the value on In-Reply-To: header in the messages being sent out (if exists). * ra/send-email-in-reply-to-from-command-line-wins: send-email: restore --in-reply-to superseding behavior | 09 July 2020, 21:00:42 UTC |
b2b7a54 | Junio C Hamano | 09 July 2020, 21:00:41 UTC | Merge branch 'vs/completion-with-set-u' into master The command line completion support (in contrib/) used to be prepared to work with "set -u" but recent changes got a bit more sloppy. This has been corrected. * vs/completion-with-set-u: completion: nounset mode fixes | 09 July 2020, 21:00:41 UTC |
8251695 | Junio C Hamano | 09 July 2020, 21:00:41 UTC | Merge branch 'cc/cat-file-usage-update' into master Doc/usage update. * cc/cat-file-usage-update: cat-file: add missing [=<format>] to usage/synopsis | 09 July 2020, 21:00:41 UTC |
81de0c0 | Martin Ågren | 09 July 2020, 18:24:38 UTC | git-rebase.txt: fix description list separator We don't give a "::" for the list separator, but just a single ":". This ends up rendering literally, "--apply: Use applying strategies ...". As a follow-on error, the list continuation, "+", also ends up rendering literally (because we don't have a list). This was introduced in 52eb738d6b ("rebase: add an --am option", 2020-02-15) and survived the rename in 10cdb9f38a ("rebase: rename the two primary rebase backends", 2020-02-15). Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 July 2020, 18:35:57 UTC |
169b91f | Jordi Mas | 09 July 2020, 18:01:42 UTC | l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> | 09 July 2020, 18:01:42 UTC |
150cd3b | SZEDER Gábor | 09 July 2020, 17:00:03 UTC | commit-graph: fix "Writing out commit graph" progress counter 76ffbca71a (commit-graph: write Bloom filters to commit graph file, 2020-04-06) added two delayed progress lines to writing the Bloom filter index and data chunk. This is wrong, because a single common progress is used while writing all chunks, which is not updated while writing these two new chunks, resulting in incomplete-looking "done" lines: Expanding reachable commits in commit graph: 888679, done. Computing commit changed paths Bloom filters: 100% (888678/888678), done. Writing out commit graph in 6 passes: 66% (3554712/5332068), done. Use the common 'struct progress' instance while writing the Bloom filter chunks as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 July 2020, 17:28:49 UTC |
6f9d5f2 | SZEDER Gábor | 09 July 2020, 16:54:32 UTC | commit-graph: fix progress of reachable commits To display a progress line while iterating over all refs, d335ce8f24 (commit-graph.c: show progress of finding reachable commits, 2020-05-13) should have added a pair of start_delayed_progress() and stop_progress() calls around a for_each_ref() invocation. Alas, the stop_progress() call ended up at the wrong place, after write_commit_graph(), which does all the commit-graph computation and writing, and has several progress lines of its own. Consequently, that new Collecting referenced commits: 123 progress line is overwritten by the first progress line shown by write_commit_graph(), and its final "done" line is shown last, after everything is finished: Expanding reachable commits in commit graph: 344786, done. Computing commit changed paths Bloom filters: 100% (344786/344786), done. Collecting referenced commits: 154, done. Move that stop_progress() call to the right place. While at it, drop the unnecessary 'if (data.progress)' condition protecting the stop_progress() call, because that function is prepared to handle a NULL progress struct. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 July 2020, 17:27:23 UTC |
35e6e21 | Matheus Tavares | 09 July 2020, 02:10:39 UTC | entry: check for fstat() errors after checkout In 11179eb311 ("entry.c: check if file exists after checkout", 2017-10-05) we started checking the result of the lstat() call done after writing a file, to avoid writing garbage to the corresponding cache entry. However, the code skips calling lstat() if it's possible to use fstat() when it still has the file descriptor open. And when calling fstat() we don't do the same error checking. To fix that, let the callers of fstat_output() know when fstat() fails. In this case, write_entry() will try to use lstat() and properly report an error if that fails as well. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 July 2020, 16:45:06 UTC |
b5651a2 | Jonathan Nieder | 07 July 2020, 06:20:39 UTC | experimental: default to fetch.writeCommitGraph=false The fetch.writeCommitGraph feature makes fetches write out a commit graph file for the newly downloaded pack on fetch. This improves the performance of various commands that would perform a revision walk and eventually ought to be the default for everyone. To prepare for that future, it's enabled by default for users that set feature.experimental=true to experience such future defaults. Alas, for --unshallow fetches from a shallow clone it runs into a snag: by the time Git has fetched the new objects and is writing a commit graph, it has performed a revision walk and r->parsed_objects contains information about the shallow boundary from *before* the fetch. The commit graph writing code is careful to avoid writing a commit graph file in shallow repositories, but the new state is not shallow, and the result is that from that point on, commands like "git log" make use of a newly written commit graph file representing a fictional history with the old shallow boundary. We could fix this by making the commit graph writing code more careful to avoid writing a commit graph that could have used any grafts or shallow state, but it is possible that there are other pieces of mutated state that fetch's commit graph writing code may be relying on. So disable it in the feature.experimental configuration. Google developers have been running in this configuration (by setting fetch.writeCommitGraph=false in the system config) to work around this bug since it was discovered in April. Once the fix lands, we'll enable fetch.writeCommitGraph=true again to give it some early testing before rolling out to a wider audience. In other words: - this patch only affects behavior with feature.experimental=true - it makes feature.experimental match the configuration Google has been using for the last few months, meaning it would leave users in a better tested state than without it - this should improve testing for other features guarded by feature.experimental, by making feature.experimental safer to use Reported-by: Jay Conrod <jayconrod@google.com> Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 July 2020, 23:37:43 UTC |
ce16364 | Taylor Blau | 08 July 2020, 21:10:53 UTC | commit.c: don't persist substituted parents when unshallowing Since 37b9dcabfc (shallow.c: use '{commit,rollback}_shallow_file', 2020-04-22), Git knows how to reset stat-validity checks for the $GIT_DIR/shallow file, allowing it to change between a shallow and non-shallow state in the same process (e.g., in the case of 'git fetch --unshallow'). However, when $GIT_DIR/shallow changes, Git does not alter or remove any grafts (nor substituted parents) in memory. This comes up in a "git fetch --unshallow" with fetch.writeCommitGraph set to true. Ordinarily in a shallow repository (and before 37b9dcabfc, even in this case), commit_graph_compatible() would return false, indicating that the repository should not be used to write a commit-graphs (since commit-graph files cannot represent a shallow history). But since 37b9dcabfc, in an --unshallow operation that check succeeds. Thus even though the repository isn't shallow any longer (that is, we have all of the objects), the in-core representation of those objects still has munged parents at the shallow boundaries. When the commit-graph write proceeds, we use the incorrect parentage, producing wrong results. There are two ways for a user to work around this: either (1) set 'fetch.writeCommitGraph' to 'false', or (2) drop the commit-graph after unshallowing. One way to fix this would be to reset the parsed object pool entirely (flushing the cache and thus preventing subsequent reads from modifying their parents) after unshallowing. That would produce a problem when callers have a now-stale reference to the old pool, and so this patch implements a different approach. Instead, attach a new bit to the pool, 'substituted_parent', which indicates if the repository *ever* stored a commit which had its parents modified (i.e., the shallow boundary prior to unshallowing). This bit needs to be sticky because all reads subsequent to modifying a commit's parents are unreliable when unshallowing. Modify the check in 'commit_graph_compatible' to take this bit into account, and correctly avoid generating commit-graphs in this case, thus solving the bug. Helped-by: Derrick Stolee <dstolee@microsoft.com> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Reported-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 July 2020, 23:13:46 UTC |
5f46e61 | Jeff King | 08 July 2020, 04:38:19 UTC | diff: check for merge bases before assigning sym->base In symdiff_prepare(), we iterate over the set of parsed objects to pick out any symmetric differences, including the left, right, and base elements. We assign the results into pointers in a "struct symdiff", and then complain if we didn't find a base, like so: sym->left = rev->pending.objects[lpos].name; sym->right = rev->pending.objects[rpos].name; sym->base = rev->pending.objects[basepos].name; if (basecount == 0) die(_("%s...%s: no merge base"), sym->left, sym->right); But the least lines are backwards. If basecount is 0, then basepos will be -1, and we will access memory outside of the pending array. This isn't usually that big a deal, since we don't do anything besides a single pointer-sized read before exiting anyway, but it does violate the C standard, and of course memory-checking tools like ASan complain. Let's put the basecount check first. Note that we haveto split it from the other assignments, since the die() relies on sym->left and sym->right having been assigned (this isn't strictly necessary, but is easier to read than dereferencing the pending array again). Reported-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 July 2020, 20:57:18 UTC |
c0d73a5 | Trygve Aaberge | 07 July 2020, 12:17:15 UTC | Wait for child on signal death for aliases to externals When we are running an alias to an external command, we want to wait for that process to exit even after receiving ^C which normally kills the git process. This is useful when the process is ignoring SIGINT (which e.g. pagers often do), and then we don't want it to be killed. Having an alias which invokes a pager is probably not common, but it can be useful e.g. if you have an alias to a git command which uses a subshell as one of the arguments (in which case you have to use an external command, not an alias to a builtin). This patch is similar to the previous commit, but the previous commit fixed this only for aliases to builtins, while this commit does the same for aliases to external commands. In addition to waiting after clean like the previous commit, this also enables cleaning the child (that was already enabled for aliases to builtins before the previous commit), because wait_after_clean relies on it. Lastly, while the previous commit fixed a regression, I don't think this has ever worked properly. Signed-off-by: Trygve Aaberge <trygveaa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 July 2020, 20:15:13 UTC |
e662df7 | Trygve Aaberge | 07 July 2020, 12:17:14 UTC | Wait for child on signal death for aliases to builtins When you hit ^C all the processes in the tree receives it. When a git command uses a pager, git ignores this and waits until the pager quits. However, when using an alias there is an additional process in the tree which didn't ignore the signal. That caused it to exit which in turn caused the pager to exit. This fixes that for aliases to builtins. This was originally fixed in 46df6906 (execv_dashed_external: wait for child on signal death, 2017-01-06), but was broken by ee4512ed (trace2: create new combined trace facility, 2019-02-22) and then b9140840 (git: avoid calling aliased builtins via their dashed form, 2019-07-29). Signed-off-by: Trygve Aaberge <trygveaa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 July 2020, 20:14:05 UTC |
4a0fcf9 | Junio C Hamano | 07 July 2020, 05:13:31 UTC | The seventh batch Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 July 2020, 05:13:31 UTC |
43f46d6 | Junio C Hamano | 07 July 2020, 05:09:19 UTC | Merge branch 'es/worktree-code-cleanup' Code cleanup. * es/worktree-code-cleanup: worktree: avoid dead-code in conditional | 07 July 2020, 05:09:19 UTC |
efafdca | Junio C Hamano | 07 July 2020, 05:09:18 UTC | Merge branch 'dl/test-must-fail-fixes-5' The effort to avoid using test_must_fail on non-git command continues. * dl/test-must-fail-fixes-5: lib-submodule-update: pass 'test_must_fail' as an argument lib-submodule-update: prepend "git" to $command lib-submodule-update: consolidate --recurse-submodules lib-submodule-update: add space after function name | 07 July 2020, 05:09:18 UTC |
0a23331 | Junio C Hamano | 07 July 2020, 05:09:17 UTC | Merge branch 'jk/fast-export-anonym-alt' "git fast-export --anonymize" learned to take customized mapping to allow its users to tweak its output more usable for debugging. * jk/fast-export-anonym-alt: fast-export: use local array to store anonymized oid fast-export: anonymize "master" refname fast-export: allow seeding the anonymized mapping fast-export: add a "data" callback parameter to anonymize_str() fast-export: move global "idents" anonymize hashmap into function fast-export: use a flex array to store anonymized entries fast-export: stop storing lengths in anonymized hashmaps fast-export: tighten anonymize_mem() interface to handle only strings fast-export: store anonymized oids as hex strings fast-export: use xmemdupz() for anonymizing oids t9351: derive anonymized tree checks from original repo | 07 July 2020, 05:09:17 UTC |
0ac0947 | Junio C Hamano | 07 July 2020, 05:09:17 UTC | Merge branch 'js/diff-files-i-t-a-fix-for-difftool' "git difftool" has trouble dealing with paths added to the index with the intent-to-add bit. * js/diff-files-i-t-a-fix-for-difftool: difftool -d: ensure that intent-to-add files are handled correctly diff-files --raw: show correct post-image of intent-to-add files | 07 July 2020, 05:09:17 UTC |
11cbda2 | Junio C Hamano | 07 July 2020, 05:09:17 UTC | Merge branch 'js/default-branch-name' The name of the primary branch in existing repositories, and the default name used for the first branch in newly created repositories, is made configurable, so that we can eventually wean ourselves off of the hardcoded 'master'. * js/default-branch-name: contrib: subtree: adjust test to change in fmt-merge-msg testsvn: respect `init.defaultBranch` remote: use the configured default branch name when appropriate clone: use configured default branch name when appropriate init: allow setting the default for the initial branch name via the config init: allow specifying the initial branch name for the new repository docs: add missing diamond brackets submodule: fall back to remote's HEAD for missing remote.<name>.branch send-pack/transport-helper: avoid mentioning a particular branch fmt-merge-msg: stop treating `master` specially | 07 July 2020, 05:09:17 UTC |
480e785 | Junio C Hamano | 07 July 2020, 05:09:17 UTC | Merge branch 'rs/pack-bits-in-object-better' By renumbering object flag bits, "struct object" managed to lose bloated inter-field padding. * rs/pack-bits-in-object-better: revision: reallocate TOPO_WALK object flags | 07 July 2020, 05:09:17 UTC |
67d99b8 | Junio C Hamano | 07 July 2020, 05:09:17 UTC | Merge branch 'bc/http-push-flagsfix' The code to push changes over "dumb" HTTP had a bad interaction with the commit reachability code due to incorrect allocation of object flag bits, which has been corrected. * bc/http-push-flagsfix: http-push: ensure unforced pushes fail when data would be lost | 07 July 2020, 05:09:17 UTC |
8a78e4d | Junio C Hamano | 07 July 2020, 05:09:16 UTC | Merge branch 'js/pu-to-seen' The documentation and some tests have been adjusted for the recent renaming of "pu" branch to "seen". * js/pu-to-seen: tests: reference `seen` wherever `pu` was referenced docs: adjust the technical overview for the rename `pu` -> `seen` docs: adjust for the recent rename of `pu` to `seen` | 07 July 2020, 05:09:16 UTC |
0258ed1 | Junio C Hamano | 07 July 2020, 05:09:15 UTC | Merge branch 'cb/is-descendant-of' Code clean-up. * cb/is-descendant-of: commit-reach: avoid is_descendant_of() shim | 07 July 2020, 05:09:16 UTC |
5c61d10 | Junio C Hamano | 07 July 2020, 05:09:15 UTC | Merge branch 'mk/pb-pretty-email-without-domain-part-fix' Docfix. * mk/pb-pretty-email-without-domain-part-fix: doc: fix author vs. committer copy/paste error | 07 July 2020, 05:09:15 UTC |
65ffaca | Junio C Hamano | 07 July 2020, 05:09:15 UTC | Merge branch 'jl/complete-git-prune' Add "git prune" to the completion (in contrib/), which could be typed by end-users from the command line. * jl/complete-git-prune: bash-completion: add git-prune into bash completion | 07 July 2020, 05:09:15 UTC |
645f631 | Junio C Hamano | 07 July 2020, 05:09:15 UTC | Merge branch 'es/get-worktrees-unsort' API cleanup for get_worktrees() * es/get-worktrees-unsort: worktree: drop get_worktrees() unused 'flags' argument worktree: drop get_worktrees() special-purpose sorting option | 07 July 2020, 05:09:15 UTC |
e7e113a | Junio C Hamano | 07 July 2020, 05:09:14 UTC | Merge branch 'bc/sha-256-cvs-svn-updates' CVS/SVN interface have been prepared for SHA-256 transition * bc/sha-256-cvs-svn-updates: git-cvsexportcommit: port to SHA-256 git-cvsimport: port to SHA-256 git-cvsserver: port to SHA-256 git-svn: set the OID length based on hash algorithm perl: make SVN code hash independent perl: make Git::IndexInfo work with SHA-256 perl: create and switch variables for hash constants t/lib-git-svn: make hash size independent t9101: make hash independent t9104: make hash size independent t9100: make test work with SHA-256 t9108: make test hash independent t9168: make test hash independent t9109: make test hash independent | 07 July 2020, 05:09:14 UTC |
d80bea4 | Junio C Hamano | 07 July 2020, 05:09:13 UTC | Merge branch 'ak/commit-graph-to-slab' A few fields in "struct commit" that do not have to always be present have been moved to commit slabs. * ak/commit-graph-to-slab: commit-graph: minimize commit_graph_data_slab access commit: move members graph_pos, generation to a slab commit-graph: introduce commit_graph_data_slab object: drop parsed_object_pool->commit_count | 07 July 2020, 05:09:14 UTC |
0cc4dca | Junio C Hamano | 07 July 2020, 05:09:13 UTC | Merge branch 'en/sparse-status' "git status" learned to report the status of sparse checkout. * en/sparse-status: git-prompt: include sparsity state as well git-prompt: document how in-progress operations affect the prompt wt-status: show sparse checkout status as well | 07 July 2020, 05:09:13 UTC |
33a22c1 | Junio C Hamano | 07 July 2020, 05:09:13 UTC | Merge branch 'ps/ref-transaction-hook' A new hook. * ps/ref-transaction-hook: refs: implement reference transaction hook | 07 July 2020, 05:09:13 UTC |
1221085 | Junio C Hamano | 07 July 2020, 05:09:13 UTC | Merge branch 'bc/sha-256-part-2' SHA-256 migration work continues. * bc/sha-256-part-2: (44 commits) remote-testgit: adapt for object-format bundle: detect hash algorithm when reading refs t5300: pass --object-format to git index-pack t5704: send object-format capability with SHA-256 t5703: use object-format serve option t5702: offer an object-format capability in the test t/helper: initialize the repository for test-sha1-array remote-curl: avoid truncating refs with ls-remote t1050: pass algorithm to index-pack when outside repo builtin/index-pack: add option to specify hash algorithm remote-curl: detect algorithm for dumb HTTP by size builtin/ls-remote: initialize repository based on fetch t5500: make hash independent serve: advertise object-format capability for protocol v2 connect: parse v2 refs with correct hash algorithm connect: pass full packet reader when parsing v2 refs Documentation/technical: document object-format for protocol v2 t1302: expect repo format version 1 for SHA-256 builtin/show-index: provide options to determine hash algo t5302: modernize test formatting ... | 07 July 2020, 05:09:13 UTC |
01faa91 | René Scharfe | 04 July 2020, 12:56:32 UTC | revision: disable min_age optimization with line-log If one of the options --before, --min-age or --until is given, limit_list() filters out younger commits early on. Line-log needs all those commits to trace the movement of line ranges, though. Skip this optimization if both are used together. Reported-by: Мария Долгополова <dolgopolovamariia@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 July 2020, 01:38:03 UTC |
3080c50 | Johannes Schindelin | 01 July 2020, 21:19:07 UTC | difftool -d: ensure that intent-to-add files are handled correctly In https://github.com/git-for-windows/git/issues/2677, a `git difftool -d` problem was reported. The underlying cause was a bug in `git diff-files --raw` that we just fixed: it reported intent-to-add files with the empty _tree_ as the post-image OID, when we need to show an all-zero (or, "null") OID instead, to indicate to the caller that they have to look at the worktree file. The symptom of that problem shown by `git difftool` was this: error: unable to read sha1 file of <path> (<empty-tree-OID>) error: could not write '<filename>' Make sure that the reported `difftool` problem stays fixed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 July 2020, 23:15:45 UTC |
85953a3 | Johannes Schindelin | 01 July 2020, 21:19:06 UTC | diff-files --raw: show correct post-image of intent-to-add files The documented behavior of `git diff-files --raw` is to display [...] 0{40} if creation, unmerged or "look at work tree". on the right hand (i.e. postimage) side. This happens for files that have unstaged modifications, and for files that are unmodified but stat-dirty. For intent-to-add files, we used to show the empty blob's hash instead. In c26022ea8f5 (diff: convert diff_addremove to struct object_id, 2017-05-30), we made that worse by inadvertently changing that to the hash of the empty tree. Let's make the behavior consistent with files that have unstaged modifications (which applies to intent-to-add files, too) by showing all-zero values also for intent-to-add files. Accordingly, this patch adjusts the expectations set by the regression test introduced in feea6946a5b (diff-files: treat "i-t-a" files as "not-in-index", 2020-06-20). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 July 2020, 23:15:43 UTC |
f9f60d7 | Rafael Aquini | 29 June 2020, 14:11:04 UTC | send-email: restore --in-reply-to superseding behavior git send-email --in-reply-to= fails to override In-Reply-To email headers, if they're present in the output of format-patch, even when explicitly told to do so by the option --no-thread, which breaks the contract of the command line switch option, per its man page. " --in-reply-to=<identifier> Make the first mail (or all the mails with --no-thread) appear as a reply to the given Message-Id, which avoids breaking threads to provide a new patch series. " This patch fixes the aformentioned issue, by bringing --in-reply-to's old overriding behavior back. The test was donated by Carlo Marcelo Arenas Belón. Signed-off-by: Rafael Aquini <aquini@redhat.com> Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 July 2020, 23:12:21 UTC |
0172f78 | Christian Couder | 01 July 2020, 10:16:18 UTC | cat-file: add missing [=<format>] to usage/synopsis When displaying cat-file usage, the fact that a <format> can be specified is only visible when lookling at the --batch and --batch-check options which are shown like this: --batch[=<format>] show info and content of objects fed from the standard input --batch-check[=<format>] show info about objects fed from the standard input It seems more coherent and improves discovery to also show it on the usage line. In the documentation the DESCRIPTION tells us that "The output format can be overridden using the optional <format> argument", but we can't see the <format> argument in the SYNOPSIS above the description which is confusing. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 July 2020, 22:54:05 UTC |
c2dbcd2 | Ville Skyttä | 29 June 2020, 18:59:45 UTC | completion: nounset mode fixes Accessing unset variables results an errors when the shell is in nounset/-u mode. This fixes the cases I've come across while using git completion in a shell running in that mode for a while. It's hard to tell if this is the complete set, but at least it improves things. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 July 2020, 21:55:30 UTC |
508fd8e | Đoàn Trần Công Danh | 29 June 2020, 16:20:03 UTC | contrib: subtree: adjust test to change in fmt-merge-msg We're starting to stop treating `master' specially in fmt-merge-msg. Adjust the test to reflect that change. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 30 June 2020, 15:41:15 UTC |
a08a83d | Junio C Hamano | 29 June 2020, 20:58:58 UTC | The sixth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> | 29 June 2020, 21:17:27 UTC |
298d704 | Junio C Hamano | 29 June 2020, 21:17:27 UTC | Merge branch 'sk/diff-files-show-i-t-a-as-new' "git diff-files" has been taught to say paths that are marked as intent-to-add are new files, not modified from an empty blob. * sk/diff-files-show-i-t-a-as-new: diff-files: treat "i-t-a" files as "not-in-index" | 29 June 2020, 21:17:27 UTC |
fa2c57d | Junio C Hamano | 29 June 2020, 21:17:27 UTC | Merge branch 'rs/commit-reach-leakfix' Leakfix. * rs/commit-reach-leakfix: commit-reach: plug minor memory leak after using is_descendant_of() | 29 June 2020, 21:17:27 UTC |
b381c98 | Junio C Hamano | 29 June 2020, 21:17:26 UTC | Merge branch 'rs/pull-leakfix' Leakfix. * rs/pull-leakfix: pull: plug minor memory leak after using is_descendant_of() | 29 June 2020, 21:17:26 UTC |
6104867 | Junio C Hamano | 29 June 2020, 21:17:26 UTC | Merge branch 'rs/retire-strbuf-write-fd' A misdesigned strbuf_write_fd() function has been retired. * rs/retire-strbuf-write-fd: strbuf: remove unreferenced strbuf_write_fd method. bugreport.c: replace strbuf_write_fd with write_in_full | 29 June 2020, 21:17:26 UTC |
1ea1f93 | Junio C Hamano | 29 June 2020, 21:17:25 UTC | Merge branch 'dl/diff-usage-comment-update' An in-code comment in "git diff" has been updated. * dl/diff-usage-comment-update: builtin/diff: fix botched update of usage comment builtin/diff: update usage comment | 29 June 2020, 21:17:25 UTC |
1033b98 | Junio C Hamano | 29 June 2020, 21:17:24 UTC | Merge branch 'xl/upgrade-repo-format' Allow runtime upgrade of the repository format version, which needs to be done carefully. There is a rather unpleasant backward compatibility worry with the last step of this series, but it is the right thing to do in the longer term. * xl/upgrade-repo-format: check_repository_format_gently(): refuse extensions for old repositories sparse-checkout: upgrade repository to version 1 when enabling extension fetch: allow adding a filter after initial clone repository: add a helper function to perform repository format upgrade | 29 June 2020, 21:17:24 UTC |
f39ad38 | Jeff King | 25 June 2020, 19:48:37 UTC | fast-export: use local array to store anonymized oid Some older versions of gcc complain about this line: builtin/fast-export.c:412:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] put_be32(oid.hash + hashsz - 4, counter++); ^ This seems to be a false positive, as there's no type-punning at all here. oid.hash is an array of unsigned char; when we pass it to a function it decays to a pointer to unsigned char. We do take a void pointer in put_be32(), but it's immediately aliased with another pointer to unsigned char (and clearly the compiler is looking inside the inlined put_be32(), since the warning doesn't happen with -O0). This happens on gcc 4.8 and 4.9, but not later versions (I tested gcc 6, 7, 8, and 9). We can work around it by using a local array instead of an object_id struct. This is a little more intimate with the details of object_id, but for whatever reason doesn't seem to trigger the compiler warning. We can revert this patch once we decide that those gcc versions are too old to care about for a warning like this (gcc 4.8 is the default compiler for Ubuntu Trusty, which is out-of-support but not fully end-of-life'd until April 2022). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 June 2020, 21:19:23 UTC |
8a49495 | Jeff King | 25 June 2020, 19:48:35 UTC | fast-export: anonymize "master" refname Running "fast-export --anonymize" will leave "refs/heads/master" untouched in the output, for two reasons: - it helped to have some known reference point between the original and anonymized repository - since it's historically the default branch name, it doesn't leak any information Now that we can ask fast-export to retain particular tokens, we have a much better tool for the first one (because it works for any ref, not just master). For the second, the notion of "default branch name" is likely to become configurable soon, at which point the name _does_ leak information. Let's drop this special case in preparation. Note that we have to adjust the test a bit, since it relied on using the name "master" in the anonymized repos. We could just use --anonymize-map=master to keep the same output, but then we wouldn't know if it works because of our hard-coded master or because of the explicit map. So let's flip the test a bit, and confirm that we anonymize "master", but keep "other" in the output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 June 2020, 21:19:23 UTC |
65b5d9f | Jeff King | 25 June 2020, 19:48:32 UTC | fast-export: allow seeding the anonymized mapping After you anonymize a repository, it can be hard to find which commits correspond between the original and the result, and thus hard to reproduce commands that triggered bugs in the original. Let's make it possible to seed the anonymization map. This lets users either: - mark names to be retained as-is, if they don't consider them secret (in which case their original commands would just work) - map names to new values, which lets them adapt the reproduction recipe to the new names without revealing the originals The implementation is fairly straight-forward. We already store each anonymized token in a hashmap (so that the same token appearing twice is converted to the same result). We can just introduce a new "seed" hashmap which is consulted first. This does make a few more promises to the user about how we'll anonymize things (e.g., token-splitting pathnames). But it's unlikely that we'd want to change those rules, even if the actual anonymization of a single token changes. And it makes things much easier for the user, who can unblind only a directory name without having to specify each path within it. One alternative to this approach would be to anonymize as we see fit, and then dump the whole refname and pathname mappings to a file. This does work, but it's a bit awkward to use (you have to manually dig the items you care about out of the mapping). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 June 2020, 21:19:23 UTC |
f402ea6 | Junio C Hamano | 25 June 2020, 19:36:26 UTC | The fifth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> | 25 June 2020, 19:36:26 UTC |
f33b5bd | Junio C Hamano | 25 June 2020, 19:27:48 UTC | Merge branch 'pb/t4014-unslave' A branch name used in a test has been clarified to match what is going on. * pb/t4014-unslave: t4014: do not use "slave branch" nomenclature | 25 June 2020, 19:27:48 UTC |