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 ...
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 |
---|---|---|---|---|
441c4a4 | Junio C Hamano | 04 September 2015, 17:25:47 UTC | Git 2.2.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 04 September 2015, 17:26:23 UTC |
f54cb05 | Junio C Hamano | 04 September 2015, 17:25:23 UTC | Merge branch 'jk/long-paths' into maint-2.2 | 04 September 2015, 17:25:23 UTC |
78f23bd | Jeff King | 19 August 2015, 18:12:48 UTC | show-branch: use a strbuf for reflog descriptions When we show "branch@{0}", we format into a fixed-size buffer using sprintf. This can overflow if you have long branch names. We can fix it by using a temporary strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 04 September 2015, 16:48:26 UTC |
5015f01 | Jeff King | 19 August 2015, 18:12:45 UTC | read_info_alternates: handle paths larger than PATH_MAX This function assumes that the relative_base path passed into it is no larger than PATH_MAX, and writes into a fixed-size buffer. However, this path may not have actually come from the filesystem; for example, add_submodule_odb generates a path using a strbuf and passes it in. This is hard to trigger in practice, though, because the long submodule directory would have to exist on disk before we would try to open its info/alternates file. We can easily avoid the bug, though, by simply creating the filename on the heap. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 04 September 2015, 16:36:51 UTC |
c29edfe | Jeff King | 19 August 2015, 18:12:41 UTC | notes: use a strbuf in add_non_note When we are loading a notes tree into our internal hash table, we also collect any files that are clearly non-notes. We format the name of the file into a PATH_MAX buffer, but unlike true notes (which cannot be larger than a fanned-out sha1 hash), these tree entries can be arbitrarily long, overflowing our buffer. We can fix this by switching to a strbuf. It doesn't even cost us an extra allocation, as we can simply hand ownership of the buffer over to the non-note struct. This is of moderate security interest, as you might fetch notes trees from an untrusted remote. However, we do not do so by default, so you would have to manually fetch into the notes namespace. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 04 September 2015, 16:36:28 UTC |
f514ef9 | Jeff King | 19 August 2015, 18:12:37 UTC | verify_absent: allow filenames longer than PATH_MAX When unpack-trees wants to know whether a path will overwrite anything in the working tree, we use lstat() to see if there is anything there. But if we are going to write "foo/bar", we can't just lstat("foo/bar"); we need to look for leading prefixes (e.g., "foo"). So we use the lstat cache to find the length of the leading prefix, and copy the filename up to that length into a temporary buffer (since the original name is const, we cannot just stick a NUL in it). The copy we make goes into a PATH_MAX-sized buffer, which will overflow if the prefix is longer than PATH_MAX. How this happens is a little tricky, since in theory PATH_MAX is the biggest path we will have read from the filesystem. But this can happen if: - the compiled-in PATH_MAX does not accurately reflect what the filesystem is capable of - the leading prefix is not _quite_ what is on disk; it contains the next element from the name we are checking. So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb" exists, the prefix of interest is "aaa/bbb/ccc". If "aaa/bbb" approaches PATH_MAX, then "ccc" can overflow it. So this can be triggered, but it's hard to do. In particular, you cannot just "git clone" a bogus repo. The verify_absent checks happen before unpack-trees writes anything to the filesystem, so there are never any leading prefixes during the initial checkout, and the bug doesn't trigger. And by definition, these files are larger than PATH_MAX, so writing them will fail, and clone will complain (though it may write a partial path, which will cause a subsequent "git checkout" to hit the bug). We can fix it by creating the temporary path on the heap. The extra malloc overhead is not important, as we are already making at least one stat() call (and probably more for the prefix discovery). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 04 September 2015, 15:50:50 UTC |
fdf96a2 | Junio C Hamano | 12 January 2015, 22:06:12 UTC | Git 2.2.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 January 2015, 22:06:12 UTC |
9f16184 | Junio C Hamano | 12 January 2015, 22:02:54 UTC | Merge branch 'jk/read-packed-refs-without-path-max' into maint * jk/read-packed-refs-without-path-max: read_packed_refs: use skip_prefix instead of static array read_packed_refs: pass strbuf to parse_ref_line read_packed_refs: use a strbuf for reading lines | 12 January 2015, 22:02:54 UTC |
d0879b3 | Junio C Hamano | 12 January 2015, 22:02:19 UTC | Merge branch 'mg/add-ignore-errors' into maint * mg/add-ignore-errors: add: ignore only ignored files | 12 January 2015, 22:02:19 UTC |
efc028b | Junio C Hamano | 12 January 2015, 22:02:05 UTC | Merge branch 'mh/find-uniq-abbrev' into maint * mh/find-uniq-abbrev: sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev | 12 January 2015, 22:02:05 UTC |
9ea21fa | Junio C Hamano | 12 January 2015, 22:01:18 UTC | Merge branch 'jk/approxidate-avoid-y-d-m-over-future-dates' into maint * jk/approxidate-avoid-y-d-m-over-future-dates: approxidate: allow ISO-like dates far in the future pass TIME_DATE_NOW to approxidate future-check | 12 January 2015, 22:01:18 UTC |
ba1edc9 | Junio C Hamano | 12 January 2015, 22:00:16 UTC | Merge branch 'rw/apply-does-not-take-ignore-date' into maint * rw/apply-does-not-take-ignore-date: git-am.txt: --ignore-date flag is not passed to git-apply | 12 January 2015, 22:00:16 UTC |
417a5b2 | Junio C Hamano | 12 January 2015, 20:19:17 UTC | Merge branch 'jk/for-each-reflog-ent-reverse' into maint * jk/for-each-reflog-ent-reverse: for_each_reflog_ent_reverse: turn leftover check into assertion for_each_reflog_ent_reverse: fix newlines on block boundaries | 12 January 2015, 20:19:17 UTC |
7ba4626 | Junio C Hamano | 07 January 2015, 21:28:10 UTC | Merge branch 'maint-2.1' into maint * maint-2.1: is_hfs_dotgit: loosen over-eager match of \u{..47} | 07 January 2015, 21:28:10 UTC |
3c84ac8 | Junio C Hamano | 07 January 2015, 21:27:56 UTC | Merge branch 'maint-2.0' into maint-2.1 * maint-2.0: is_hfs_dotgit: loosen over-eager match of \u{..47} | 07 January 2015, 21:27:56 UTC |
282616c | Junio C Hamano | 07 January 2015, 21:27:19 UTC | Merge branch 'maint-1.9' into maint-2.0 * maint-1.9: is_hfs_dotgit: loosen over-eager match of \u{..47} | 07 January 2015, 21:27:19 UTC |
64a03e9 | Junio C Hamano | 07 January 2015, 21:27:13 UTC | Merge branch 'maint-1.8.5' into maint-1.9 * maint-1.8.5: is_hfs_dotgit: loosen over-eager match of \u{..47} | 07 January 2015, 21:27:13 UTC |
3d8a54e | Junio C Hamano | 07 January 2015, 21:26:35 UTC | Merge branch 'jk/dotgit-case-maint-1.8.5' into maint-1.8.5 * jk/dotgit-case-maint-1.8.5: is_hfs_dotgit: loosen over-eager match of \u{..47} | 07 January 2015, 21:26:35 UTC |
6aaf956 | Jeff King | 23 December 2014, 08:45:36 UTC | is_hfs_dotgit: loosen over-eager match of \u{..47} Our is_hfs_dotgit function relies on the hackily-implemented next_hfs_char to give us the next character that an HFS+ filename comparison would look at. It's hacky because it doesn't implement the full case-folding table of HFS+; it gives us just enough to see if the path matches ".git". At the end of next_hfs_char, we use tolower() to convert our 32-bit code point to lowercase. Our tolower() implementation only takes an 8-bit char, though; it throws away the upper 24 bits. This means we can't have any false negatives for is_hfs_dotgit. We only care about matching 7-bit ASCII characters in ".git", and we will correctly process 'G' or 'g'. However, we _can_ have false positives. Because we throw away the upper bits, code point \u{0147} (for example) will look like 'G' and get downcased to 'g'. It's not known whether a sequence of code points whose truncation ends up as ".git" is meaningful in any language, but it does not hurt to be more accurate here. We can just pass out the full 32-bit code point, and compare it manually to the upper and lowercase characters we care about. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 29 December 2014, 20:06:27 UTC |
c2e8e4b | Junio C Hamano | 22 December 2014, 20:20:38 UTC | Prepare for 2.2.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 22 December 2014, 20:20:38 UTC |
57815a4 | Junio C Hamano | 22 December 2014, 20:18:35 UTC | Merge branch 'jk/rebuild-perl-scripts-with-no-perl-seting-change' into maint The build procedure did not bother fixing perl and python scripts when NO_PERL and NO_PYTHON build-time configuration changed. * jk/rebuild-perl-scripts-with-no-perl-seting-change: Makefile: have python scripts depend on NO_PYTHON setting Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros Makefile: have perl scripts depend on NO_PERL setting | 22 December 2014, 20:18:35 UTC |
7d37ed1 | Junio C Hamano | 22 December 2014, 20:18:25 UTC | Merge branch 'jk/no-perl-tests' into maint Some tests that depend on perl lacked PERL prerequisite to protect them, breaking build with NO_PERL configuration. * jk/no-perl-tests: t960[34]: mark cvsimport tests as requiring perl t0090: mark add-interactive test with PERL prerequisite | 22 December 2014, 20:18:26 UTC |
ebae81e | Junio C Hamano | 22 December 2014, 20:18:16 UTC | Merge branch 'po/everyday-doc' into maint "Everyday" document had a broken link. * po/everyday-doc: Documentation: change "gitlink" typo in git-push | 22 December 2014, 20:18:17 UTC |
0eeb9b8 | Junio C Hamano | 22 December 2014, 20:18:08 UTC | Merge branch 'jk/push-simple' into maint Git 2.0 was supposed to make the "simple" mode for the default of "git push", but it didn't. * jk/push-simple: push: truly use "simple" as default, not "upstream" | 22 December 2014, 20:18:08 UTC |
e524fb4 | Junio C Hamano | 22 December 2014, 20:18:00 UTC | Merge branch 'mh/config-flip-xbit-back-after-checking' into maint "git init" (hence "git clone") initialized the per-repository configuration file .git/config with x-bit by mistake. * mh/config-flip-xbit-back-after-checking: create_default_files(): don't set u+x bit on $GIT_DIR/config | 22 December 2014, 20:18:00 UTC |
0b5c641 | Junio C Hamano | 22 December 2014, 20:17:34 UTC | Merge branch 'jk/gitweb-with-newer-cgi-multi-param' into maint "gitweb" used to depend on a behaviour that was deprecated by recent CGI.pm. * jk/gitweb-with-newer-cgi-multi-param: gitweb: hack around CGI's list-context param() handling | 22 December 2014, 20:17:34 UTC |
8d51343 | Junio C Hamano | 22 December 2014, 20:17:32 UTC | Merge branch 'rs/receive-pack-use-labs' into maint * rs/receive-pack-use-labs: use labs() for variables of type long instead of abs() | 22 December 2014, 20:17:32 UTC |
e8c2351 | Junio C Hamano | 22 December 2014, 20:17:23 UTC | Merge branch 'rs/maint-config-use-labs' into maint * rs/maint-config-use-labs: use labs() for variables of type long instead of abs() | 22 December 2014, 20:17:23 UTC |
8390d5c | Junio C Hamano | 22 December 2014, 20:17:13 UTC | Merge branch 'js/windows-open-eisdir-error' into maint open() emulated on Windows platforms did not give EISDIR upon an attempt to open a directory for writing. * js/windows-open-eisdir-error: Windows: correct detection of EISDIR in mingw_open() | 22 December 2014, 20:17:13 UTC |
5d509d5 | Junio C Hamano | 22 December 2014, 20:16:58 UTC | Merge branch 'jk/colors-fix' into maint "git config --get-color" did not parse its command line arguments carefully. * jk/colors-fix: t4026: test "normal" color config: fix parsing of "git config --get-color some.key -1" docs: describe ANSI 256-color mode | 22 December 2014, 20:16:58 UTC |
447c39a | Junio C Hamano | 22 December 2014, 20:16:29 UTC | Merge branch 'jk/checkout-from-tree' into maint "git checkout $treeish $path", when $path in the index and the working tree already matched what is in $treeish at the $path, still overwrote the $path unnecessarily. * jk/checkout-from-tree: checkout $tree: do not throw away unchanged index entries | 22 December 2014, 20:16:30 UTC |
bef111d | Alexander Kuleshov | 19 December 2014, 08:37:47 UTC | clean: typofix Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 22 December 2014, 17:57:42 UTC |
9b7cbb3 | Junio C Hamano | 17 December 2014, 19:49:34 UTC | Git 2.2.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:49:34 UTC |
77933f4 | Junio C Hamano | 17 December 2014, 19:46:57 UTC | Sync with v2.1.4 * maint-2.1: Git 2.1.4 Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index | 17 December 2014, 19:46:57 UTC |
8e36a6d | Junio C Hamano | 17 December 2014, 19:44:59 UTC | Git 2.1.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:44:59 UTC |
58f1d95 | Junio C Hamano | 17 December 2014, 19:42:28 UTC | Sync with v2.0.5 * maint-2.0: Git 2.0.5 Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index | 17 December 2014, 19:42:28 UTC |
9a8c2b6 | Junio C Hamano | 17 December 2014, 19:30:46 UTC | Git 2.0.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:30:46 UTC |
5e519fb | Junio C Hamano | 17 December 2014, 19:28:02 UTC | Sync with v1.9.5 * maint-1.9: Git 1.9.5 Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index | 17 December 2014, 19:28:54 UTC |
8333263 | Junio C Hamano | 17 December 2014, 19:22:32 UTC | Git 1.9.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:22:32 UTC |
6898b79 | Junio C Hamano | 17 December 2014, 19:20:31 UTC | Sync with v1.8.5.6 * maint-1.8.5: Git 1.8.5.6 fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index | 17 December 2014, 19:20:31 UTC |
5c8213a | Junio C Hamano | 17 December 2014, 19:18:45 UTC | Git 1.8.5.6 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:18:45 UTC |
2aa9100 | Junio C Hamano | 17 December 2014, 19:11:15 UTC | Merge branch 'dotgit-case-maint-1.8.5' into maint-1.8.5 * dotgit-case-maint-1.8.5: fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index | 17 December 2014, 19:11:15 UTC |
d08c13b | Johannes Schindelin | 10 December 2014, 21:28:27 UTC | fsck: complain about NTFS ".git" aliases in trees Now that the index can block pathnames that can be mistaken to mean ".git" on NTFS and FAT32, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectNTFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about NTFS. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on NTFS themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git or git~1, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectNTFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:45 UTC |
2b4c6ef | Johannes Schindelin | 16 December 2014, 22:46:59 UTC | read-cache: optionally disallow NTFS .git variants The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for NTFS and FAT32; let's use it in verify_path(). We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on NTFS nor FAT32. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectNTFS config option. Though this is expected to be most useful on Windows, we allow it to be set everywhere, as NTFS may be mounted on other platforms. The variable does default to on for Windows, though. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:45 UTC |
1d1d69b | Johannes Schindelin | 16 December 2014, 22:31:03 UTC | path: add is_ntfs_dotgit() helper We do not allow paths with a ".git" component to be added to the index, as that would mean repository contents could overwrite our repository files. However, asking "is this path the same as .git" is not as simple as strcmp() on some filesystems. On NTFS (and FAT32), there exist so-called "short names" for backwards-compatibility: 8.3 compliant names that refer to the same files as their long names. As ".git" is not an 8.3 compliant name, a short name is generated automatically, typically "git~1". Depending on the Windows version, any combination of trailing spaces and periods are ignored, too, so that both "git~1." and ".git." still refer to the Git directory. The reason is that 8.3 stores file names shorter than 8 characters with trailing spaces. So literally, it does not matter for the short name whether it is padded with spaces or whether it is shorter than 8 characters, it is considered to be the exact same. The period is the separator between file name and file extension, and again, an empty extension consists just of spaces in 8.3 format. So technically, we would need only take care of the equivalent of this regex: (\.git {0,4}|git~1 {0,3})\. {0,3} However, there are indications that at least some Windows versions might be more lenient and accept arbitrary combinations of trailing spaces and periods and strip them out. So we're playing it real safe here. Besides, there can be little doubt about the intention behind using file names matching even the more lenient pattern specified above, therefore we should be fine with disallowing such patterns. Extra care is taken to catch names such as '.\\.git\\booh' because the backslash is marked as a directory separator only on Windows, and we want to use this new helper function also in fsck on other platforms. A big thank you goes to Ed Thomson and an unnamed Microsoft engineer for the detailed analysis performed to come up with the corresponding fixes for libgit2. This commit adds a function to detect whether a given file name can refer to the Git directory by mistake. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:45 UTC |
a18fcc9 | Jeff King | 15 December 2014, 23:21:57 UTC | fsck: complain about HFS+ ".git" aliases in trees Now that the index can block pathnames that case-fold to ".git" on HFS+, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectHFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about HFS+. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on HFS+ themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git with invisible Unicode code-points mixed in, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectHFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:45 UTC |
a42643a | Jeff King | 15 December 2014, 23:15:20 UTC | read-cache: optionally disallow HFS+ .git variants The point of disallowing ".git" in the index is that we would never want to accidentally overwrite files in the repository directory. But this means we need to respect the filesystem's idea of when two paths are equal. The prior commit added a helper to make such a comparison for HFS+; let's use it in verify_path. We make this check optional for two reasons: 1. It restricts the set of allowable filenames, which is unnecessary for people who are not on HFS+. In practice this probably doesn't matter, though, as the restricted names are rather obscure and almost certainly would never come up in practice. 2. It has a minor performance penalty for every path we insert into the index. This patch ties the check to the core.protectHFS config option. Though this is expected to be most useful on OS X, we allow it to be set everywhere, as HFS+ may be mounted on other platforms. The variable does default to on for OS X, though. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:44 UTC |
6162a1d | Jeff King | 15 December 2014, 22:56:59 UTC | utf8: add is_hfs_dotgit() helper We do not allow paths with a ".git" component to be added to the index, as that would mean repository contents could overwrite our repository files. However, asking "is this path the same as .git" is not as simple as strcmp() on some filesystems. HFS+'s case-folding does more than just fold uppercase into lowercase (which we already handle with strcasecmp). It may also skip past certain "ignored" Unicode code points, so that (for example) ".gi\u200ct" is mapped ot ".git". The full list of folds can be found in the tables at: https://www.opensource.apple.com/source/xnu/xnu-1504.15.3/bsd/hfs/hfscommon/Unicode/UCStringCompareData.h Implementing a full "is this path the same as that path" comparison would require us importing the whole set of tables. However, what we want to do is much simpler: we only care about checking ".git". We know that 'G' is the only thing that folds to 'g', and so on, so we really only need to deal with the set of ignored code points, which is much smaller. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:39 UTC |
76e86fc | Jeff King | 24 November 2014, 18:40:44 UTC | fsck: notice .git case-insensitively We complain about ".git" in a tree because it cannot be loaded into the index or checked out. Since we now also reject ".GIT" case-insensitively, fsck should notice the same, so that errors do not propagate. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:39 UTC |
450870c | Jeff King | 24 November 2014, 18:40:11 UTC | t1450: refactor ".", "..", and ".git" fsck tests We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:39 UTC |
cc2fc7c | Jeff King | 24 November 2014, 18:39:12 UTC | verify_dotfile(): reject .git case-insensitively We do not allow ".git" to enter into the index as a path component, because checking out the result to the working tree may causes confusion for subsequent git commands. However, on case-insensitive file systems, ".Git" or ".GIT" is the same. We should catch and prevent those, too. Note that technically we could allow this for repos on case-sensitive filesystems. But there's not much point. It's unlikely that anybody cares, and it creates a repository that is unexpectedly non-portable to other systems. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:04:31 UTC |
96b50cc | Jeff King | 24 November 2014, 18:37:56 UTC | read-tree: add tests for confusing paths like ".." and ".git" We should prevent nonsense paths from entering the index in the first place, as they can cause confusing results if they are ever checked out into the working tree. We already do so, but we never tested it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 19:00:37 UTC |
4616918 | Jeff King | 24 November 2014, 18:36:51 UTC | unpack-trees: propagate errors adding entries to the index When unpack_trees tries to write an entry to the index, add_index_entry may report an error to stderr, but we ignore its return value. This leads to us returning a successful exit code for an operation that partially failed. Let's make sure to propagate this code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 December 2014, 18:57:53 UTC |
ea41783 | Jeff King | 10 December 2014, 10:40:36 UTC | read_packed_refs: use skip_prefix instead of static array We want to recognize the packed-refs header and skip to the "traits" part of the line. We currently do it by feeding sizeof() a static const array to strncmp. However, it's a bit simpler to just skip_prefix, which expresses the intention more directly, and without remembering to account for the NUL-terminator in each sizeof() call. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 10 December 2014, 17:40:33 UTC |
6a49870 | Jeff King | 10 December 2014, 10:40:19 UTC | read_packed_refs: pass strbuf to parse_ref_line Now that we have a strbuf in read_packed_refs, we can pass it straight to the line parser, which saves us an extra strlen. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 10 December 2014, 17:28:54 UTC |
10c497a | Jeff King | 10 December 2014, 10:40:07 UTC | read_packed_refs: use a strbuf for reading lines Current code uses a fixed PATH_MAX-sized buffer for reading packed-refs lines. This is a reasonable guess, in the sense that git generally cannot work with refs larger than PATH_MAX. However, there are a few cases where it is not great: 1. Some systems may have a low value of PATH_MAX, but can actually handle larger paths in practice. Fixing this code path probably isn't enough to make them work completely with long refs, but it is a step in the right direction. 2. We use fgets, which will happily give us half a line on the first read, and then the rest of the line on the second. This is probably OK in practice, because our refline parser is careful enough to look for the trailing newline on the first line. The second line may look like a peeled line to us, but since "^" is illegal in refnames, it is not likely to come up. Still, it does not hurt to be more careful. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 10 December 2014, 17:27:24 UTC |
0cef4e7 | Ronald Wampler | 09 December 2014, 17:28:18 UTC | git-am.txt: --ignore-date flag is not passed to git-apply Signed-off-by: Ronald Wampler <rdwampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 December 2014, 22:25:53 UTC |
8213d87 | Junio C Hamano | 05 December 2014, 19:38:24 UTC | Merge branch 'maint' of git://github.com/git-l10n/git-po into maint * 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: fix typos | 05 December 2014, 19:38:24 UTC |
1b74f64 | Junio C Hamano | 05 December 2014, 19:38:19 UTC | Start post 2.2 cycle Signed-off-by: Junio C Hamano <gitster@pobox.com> | 05 December 2014, 19:38:19 UTC |
69216bf | Jeff King | 05 December 2014, 01:32:44 UTC | for_each_reflog_ent_reverse: turn leftover check into assertion Our loop should always process all lines, even if we hit the beginning of the file. We have a conditional after the loop ends to double-check that there is nothing left and to process it. But this should never happen, and is a sign of a logic bug in the loop. Let's turn it into a BUG assertion. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 05 December 2014, 19:11:52 UTC |
e5e73ff | Jeff King | 05 December 2014, 01:28:54 UTC | for_each_reflog_ent_reverse: fix newlines on block boundaries When we read a reflog file in reverse, we read whole chunks of BUFSIZ bytes, then loop over the buffer, parsing any lines we find. We find the beginning of each line by looking for the newline from the previous line. If we don't find one, we know that we are either at the beginning of the file, or that we have to read another block. In the latter case, we stuff away what we have into a strbuf, read another block, and continue our parse. But we missed one case here. If we did find a newline, and it is at the beginning of the block, we must also stuff that newline into the strbuf, as it belongs to the block we are about to read. The minimal fix here would be to add this special case to the conditional that checks whether we found a newline. But we can make the flow a little clearer by rearranging a bit: we first handle lines that we are going to show, and then at the end of each loop, stuff away any leftovers if necessary. That lets us fold this special-case in with the more common "we ended in the middle of a line" case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 05 December 2014, 19:11:35 UTC |
00a6fa0 | Jeff King | 27 November 2014, 03:43:06 UTC | push: truly use "simple" as default, not "upstream" The plan for the push.default transition had all along been to use the "simple" method rather than "upstream" as a default if the user did not specify their own push.default value. Commit 11037ee (push: switch default from "matching" to "simple", 2013-01-04) tried to implement that by moving PUSH_DEFAULT_UNSPECIFIED in our switch statement to fall-through to the PUSH_DEFAULT_SIMPLE case. When the commit that became 11037ee was originally written, that would have been enough. We would fall through to calling setup_push_upstream() with the "simple" parameter set to 1. However, it was delayed for a while until we were ready to make the transition in Git 2.0. And in the meantime, commit ed2b182 (push: change `simple` to accommodate triangular workflows, 2013-06-19) threw a monkey wrench into the works. That commit drops the "simple" parameter to setup_push_upstream, and instead checks whether the global "push_default" is PUSH_DEFAULT_SIMPLE. This is right when the user has explicitly configured push.default to simple, but wrong when we are a fall-through for the "unspecified" case. We never noticed because our push.default tests do not cover the case of the variable being totally unset; they only check the "simple" behavior itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 01 December 2014, 02:11:25 UTC |
ff51f56 | Jiang Xin | 29 November 2014, 02:44:48 UTC | Merge branch 'master' of https://github.com/ralfth/git-po-de * 'master' of https://github.com/ralfth/git-po-de: l10n: de.po: fix typos | 29 November 2014, 02:44:48 UTC |
ae1dcc5 | Hartmut Henkel | 23 November 2014, 15:19:49 UTC | l10n: de.po: fix typos Signed-off-by: Hartmut Henkel <hartmut_henkel@gmx.de> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> | 28 November 2014, 18:08:50 UTC |
b260d26 | Junio C Hamano | 26 November 2014, 21:18:34 UTC | Git 2.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 26 November 2014, 21:18:34 UTC |
a2b450d | Marc Branchaud | 21 November 2014, 23:10:04 UTC | RelNotes: spelling & grammar tweaks Signed-off-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 26 November 2014, 21:18:04 UTC |
61e704e | Mike Hommey | 26 November 2014, 10:12:47 UTC | sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev An example where this happens is when doing an ls-tree on a tree that contains a commit link. In that case, find_unique_abbrev is called to get a non-abbreviated hex sha1, but still, a lookup is done as to whether the sha1 is in the repository (which ends up looking for a loose object in .git/objects), while the result of that lookup is not used when returning a non-abbreviated hex sha1. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 26 November 2014, 18:51:05 UTC |
652e759 | Junio C Hamano | 21 November 2014, 20:10:56 UTC | Git 2.2.0-rc3 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 November 2014, 20:10:56 UTC |
1d31e5a | Michael J Gruber | 21 November 2014, 16:08:19 UTC | add: ignore only ignored files "git add foo bar" adds neither foo nor bar when bar is ignored, but dies to let the user recheck their command invocation. This becomes less helpful when "git add foo.*" is subject to shell expansion and some of the expanded files are ignored. "git add --ignore-errors" is supposed to ignore errors when indexing some files and adds the others. It does ignore errors from actual indexing attempts, but does not ignore the error "file is ignored" as outlined above. This is unexpected. Change "git add foo bar" to add foo when bar is ignored, but issue a warning and return a failure code as before the change. That is, in the case of trying to add ignored files we now act the same way (with or without "--ignore-errors") in which we act for more severe indexing errors when "--ignore-errors" is specified. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 November 2014, 18:19:14 UTC |
cb35722 | Jeff King | 20 November 2014, 15:16:09 UTC | t4026: test "normal" color If the user specifiers "normal" for a foreground color, this should be a noop (while this may sound useless, it is the only way to specify an unchanged foreground color followed by a specific background color). We also check that color "-1" does the same thing. This is not documented, but has worked forever, so let's make sure we keep supporting it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 20 November 2014, 18:54:10 UTC |
d0e08d6 | Jeff King | 20 November 2014, 15:15:51 UTC | config: fix parsing of "git config --get-color some.key -1" Most of git-config's command line options use OPT_BIT to choose an action, and then parse the non-option arguments in a context-dependent way. However, --get-color and --get-colorbool are unlike the rest of the options, in that they are OPT_STRING, taking the option name as a parameter. This generally works, because we then use the presence of those strings to set an action bit anyway. But it does mean that the option-parser will continue looking for options even after the key (because it is not a non-option; it is an argument to an option). And running: git config --get-color some.key -1 (to use "-1" as the default color spec) will barf, claiming that "-1" is not an option. Instead, we should treat --get-color and --get-colorbool as action bits, just like --add, --get, and all the other actions, and then check that the non-option arguments we got are sane. This fixes the weirdness above, and makes those two options like all the others. This "fixes" a test in t4026, which checked that feeding "-2" as a color should fail (it does fail, but prior to this patch, because parseopt barfed, not because we actually ever tried to parse the color). This also catches other errors, like: git config --get-color some.key black blue which previously silently ignored "blue" (and now will complain that you gave too many arguments). There are some possible regressions, though. We now disallow these, which currently do what you would expect: # specifying other options after the action git config --get-color some.key --file whatever # using long-arg syntax git config --get-color=some.key However, we have never advertised these in the documentation, and in fact they did not work in some older versions of git. The behavior was apparently switched as an accidental side effect of d64ec16 (git config: reorganize to use parseopt, 2009-02-21). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 20 November 2014, 18:52:23 UTC |
0edad17 | Jeff King | 20 November 2014, 15:15:31 UTC | docs: describe ANSI 256-color mode Our color specifications have supported the 256-color ANSI extension for years, but we never documented it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 20 November 2014, 18:13:25 UTC |
7ba2ba7 | Jiang Xin | 20 November 2014, 08:12:34 UTC | l10n: remove a superfluous translation for push.c Ralf reported that '--recurse-submodules' option in push.c should not be translated [1]. Before his commit is merged, remove superfluous translations for push.c. [1] http://www.spinics.net/lists/git/msg241964.html Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 20 November 2014, 08:23:43 UTC |
e6c1c39 | Ralf Thielow | 20 November 2014, 06:15:15 UTC | l10n: de.po: translate 2 messages Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> | 20 November 2014, 06:16:18 UTC |
388a439 | Ralf Thielow | 18 November 2014, 18:06:51 UTC | l10n: de.po: translate 2 new messages Signed-off-by: Phillip Sz <phillip.szelat@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> | 20 November 2014, 06:16:18 UTC |
9aeb4c2 | Jiang Xin | 20 November 2014, 02:53:48 UTC | l10n: batch updates for one trivial change In order to catch up with the release of Git 2.2.0 final, make a batch l10n update for the new l10n change brought by commit d52adf1 (trailer: display a trailer without its trailing newline). Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 20 November 2014, 02:53:48 UTC |
e3f9cab | Jiang Xin | 20 November 2014, 02:03:10 UTC | l10n: git.pot: v2.2.0 round 2 (1 updated) Generate po/git.pot from v2.2.0-rc2-23-gca0107e for git v2.2.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 20 November 2014, 02:03:10 UTC |
ca0107e | Junio C Hamano | 19 November 2014, 21:48:01 UTC | Merge branch 'sv/submitting-final-patch' * sv/submitting-final-patch: SubmittingPatches: final submission is To: maintainer and CC: list | 19 November 2014, 21:48:01 UTC |
eeb92d7 | Junio C Hamano | 19 November 2014, 21:47:59 UTC | Merge branch 'sn/tutorial-status-output-example' * sn/tutorial-status-output-example: gittutorial: fix output of 'git status' | 19 November 2014, 21:47:59 UTC |
bfd6b53 | Junio C Hamano | 19 November 2014, 21:47:55 UTC | Merge branch 'mh/doc-remote-helper-xref' * mh/doc-remote-helper-xref: doc: add some crossrefs between manual pages | 19 November 2014, 21:47:56 UTC |
f00e081 | Junio C Hamano | 19 November 2014, 21:47:53 UTC | Merge branch 'tb/no-relative-file-url' * tb/no-relative-file-url: t5705: the file:// URL should be absolute | 19 November 2014, 21:47:53 UTC |
d4c4f18 | Junio C Hamano | 19 November 2014, 21:47:49 UTC | Merge branch 'cc/interpret-trailers' Small fixes to a new experimental command already in 'master'. * cc/interpret-trailers: trailer: display a trailer without its trailing newline trailer: ignore comment lines inside the trailers | 19 November 2014, 21:47:52 UTC |
13dbf46 | Jeff King | 18 November 2014, 17:10:22 UTC | gitweb: hack around CGI's list-context param() handling As of CGI.pm's 4.08 release, the behavior to call CGI::param() in a list context is deprecated (because it can be potentially unsafe if called inside a hash constructor). This causes gitweb to issue a warning for some of our code, which in turn causes the tests to fail. Our use is in fact _not_ one of the dangerous cases, as we are intentionally using a list context. The recommended route by 4.08 is to use the new CGI::multi_param() call to make it explicit that we know what we are doing. However, that function is only available in 4.08, which is about a month old; we cannot rely on having it. One option would be to set $CGI::LIST_CONTEXT_WARN globally, which turns off the warning. However, that would eliminate the protection these newer releases are trying to provide. We want to annotate each site as OK using the new function. So instead, let's check whether CGI provides the multi_param() function, and if not, provide an implementation that just wraps param(). That will work on both old and new versions of CGI. Sadly, we cannot just check defined(\&CGI::multi_param), because CGI uses the autoload feature, which claims that all functions are defined. Instead, we just do a version check. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 November 2014, 19:23:10 UTC |
ca2051d | Jonathan Nieder | 18 November 2014, 18:43:47 UTC | Makefile: have python scripts depend on NO_PYTHON setting Like the perl scripts, python scripts need a dependency to ensure they are rebuilt when switching between the "dummy" versions that run without Python and the real thing. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 November 2014, 19:15:50 UTC |
64c07db | Jonathan Nieder | 18 November 2014, 18:38:38 UTC | Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros SCRIPT_PERL_GEN is defined as $(patsubst %.perl,%,$(SCRIPT_PERL)) for use in targets like build-perl-script used by makefiles in subdirectories that override SCRIPT_PERL (see v1.8.2-rc0~17^2, "git-remote-mediawiki: use toplevel's Makefile", 2013-02-08). The same expression is used in the rules that actually write the generated perl scripts, and since these rules were introduced before SCRIPT_PERL_GEN, they use the longhand instead of that macro. Use the macro to make reading easier. Likewise for SCRIPT_SH_GEN. The Python rules already got the same simplification in v1.8.4-rc0~162^2~8 (2013-05-24). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 November 2014, 19:15:04 UTC |
e69b1ce | Junio C Hamano | 18 November 2014, 18:27:46 UTC | Merge git://github.com/git-l10n/git-po * 'master' of git://github.com/git-l10n/git-po: l10n: Update Catalan translation | 18 November 2014, 18:27:46 UTC |
0cfd333 | Junio C Hamano | 18 November 2014, 18:19:38 UTC | Merge branch 'jc/doc-commit-only' * jc/doc-commit-only: Documentation/git-commit: clarify that --only/--include records the working tree contents | 18 November 2014, 18:19:42 UTC |
4d86216 | Junio C Hamano | 18 November 2014, 18:18:28 UTC | Merge branch 'ta/tutorial-modernize' * ta/tutorial-modernize: gittutorial.txt: remove reference to ancient Git version | 18 November 2014, 18:18:28 UTC |
3f78278 | Junio C Hamano | 18 November 2014, 18:16:54 UTC | Merge branch 'da/difftool' Fix-up to a new feature in 'master'. * da/difftool: difftool: honor --trust-exit-code for builtin tools | 18 November 2014, 18:16:55 UTC |
880ef58 | Jeff King | 18 November 2014, 17:29:32 UTC | t960[34]: mark cvsimport tests as requiring perl Git-cvsimport is written in perl, which understandably causes the tests to fail if you build with NO_PERL (which will avoid building cvsimport at all). The earlier cvsimport tests in t9600-t9602 are all marked with a PERL prerequisite, but these ones are not. The one in t9603 was likely not noticed because it is an expected failure anyway. The ones in t9604 have been around for a long time, but it is likely that the combination of NO_PERL and having cvsps installed is rare enough that nobody noticed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 November 2014, 18:16:09 UTC |
5a97639 | Jeff King | 18 November 2014, 17:22:31 UTC | t0090: mark add-interactive test with PERL prerequisite The add-interactive system is built in perl. If you build with NO_PERL, running "git commit --interactive" will exit with an error and the test will fail. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 November 2014, 18:16:06 UTC |
e204b00 | Jeff King | 18 November 2014, 17:43:09 UTC | Makefile: have perl scripts depend on NO_PERL setting If NO_PERL is not set, our perl scripts are built as usual. If it is set, then we build "dummy" versions that tell you git was built without perl support and exit gracefully. However, if you switch to NO_PERL in a directory with existing build artifacts, we do not notice that the files need rebuilt. We see only that they are newer than the "unimplemented.sh" wrapper and assume they are done. So doing: make make NO_PERL=Nope would result in a git-add--interactive script that uses perl (and running the test suite would make use of it). Instead, we should trigger a rebuild of the perl scripts anytime NO_PERL changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 November 2014, 18:15:14 UTC |
1f32ecf | Michael Haggerty | 18 November 2014, 13:50:24 UTC | create_default_files(): don't set u+x bit on $GIT_DIR/config Since time immemorial, the test of whether to set "core.filemode" has been done by trying to toggle the u+x bit on $GIT_DIR/config, which we know always exists, and then testing whether the change "took". I find it somewhat odd to use the config file for this test, but whatever. The test code didn't set the u+x bit back to its original state itself, instead relying on the subsequent call to git_config_set() to re-write the config file with correct permissions. But ever since daa22c6f8d config: preserve config file permissions on edits (2014-05-06) git_config_set() copies the permissions from the old config file to the new one. This is a good change in and of itself, but it invalidates the create_default_files()'s assumption, causing "git init" to leave the executable bit set on $GIT_DIR/config. Reset the permissions on $GIT_DIR/config when we are done with the test in create_default_files(). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 November 2014, 18:10:54 UTC |
b3e4c47 | Alex Henrie | 18 November 2014, 03:22:48 UTC | l10n: Update Catalan translation Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> | 18 November 2014, 03:22:48 UTC |
ea4f93e | Junio C Hamano | 17 November 2014, 17:28:23 UTC | Merge branch 'master' of git://github.com/git-l10n/git-po * 'master' of git://github.com/git-l10n/git-po: l10n: de.po: translate 62 new messages l10n: de.po: Fixup one translation l10n: de.po: use imperative form for command options | 17 November 2014, 17:28:23 UTC |
366c8d4 | brian m. carlson | 17 November 2014, 00:49:00 UTC | Documentation: change "gitlink" typo in git-push The git-push manual page used "gitlink" in one place instead of "linkgit". Fix this so the link renders correctly. Noticed-by: Dan Allen <dan.j.allen@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 November 2014, 17:27:47 UTC |
31a8aa1 | René Scharfe | 15 November 2014, 13:27:21 UTC | use labs() for variables of type long instead of abs() Using abs() on long values can cause truncation, so use labs() instead. Reported by Clang 3.5 (-Wabsolute-value, enabled by -Wall). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 November 2014, 16:57:07 UTC |
83915ba | René Scharfe | 15 November 2014, 13:27:21 UTC | use labs() for variables of type long instead of abs() Using abs() on long values can cause truncation, so use labs() instead. Reported by Clang 3.5 (-Wabsolute-value, enabled by -Wall). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 November 2014, 16:54:34 UTC |
ba6fad0 | Johannes Sixt | 16 November 2014, 21:06:26 UTC | Windows: correct detection of EISDIR in mingw_open() According to the Linux open(2) man page, open() must return EISDIR if a directory was attempted to be opened for writing. Our emulation in mingw_open() does not get this right: it checks only for O_CREAT. Fix it to check for a write request. This fixes a failure in reflog handling, which opens files with O_APPEND|O_WRONLY, but without O_CREAT, and expects EISDIR when the named file happens to be a directory. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 November 2014, 16:45:50 UTC |
d544b2d | Ralf Thielow | 30 October 2014, 08:00:47 UTC | l10n: de.po: translate 62 new messages Translate 62 new messages came from git.pot update in 16742b0 (l10n: git.pot: proposed updates for v2.2.0 (+62)). Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> | 15 November 2014, 17:22:05 UTC |