git/git-filter-branch.sh, branch v2.8.2

Merge branch 'jk/filter-branch-no-index'

2016-01-29T00:10:12Z

A recent optimization to filter-branch in v2.7.0 introduced a regression when --prune-empty filter is used, which has been corrected. * jk/filter-branch-no-index: filter-branch: resolve $commit^{tree} in no-index case

filter-branch: resolve $commit^{tree} in no-index case

2016-01-19T22:20:56Z

Commit 348d4f2 (filter-branch: skip index read/write when possible, 2015-11-06) taught filter-branch to optimize out the final "git write-tree" when we know we haven't touched the tree with any of our filters. It does by simply putting the literal text "$commit^{tree}" into the "$tree" variable, avoiding a useless rev-parse call. However, when we pass this to git_commit_non_empty_tree(), it gets confused; it resolves "$commit^{tree}" itself, and compares our string to the 40-hex sha1, which obviously doesn't match. As a result, "--prune-empty" (or any custom filter using git_commit_non_empty_tree) will fail to drop an empty commit (when filter-branch is used without a tree or index filter). Let's resolve $tree to the 40-hex ourselves, so that git_commit_non_empty_tree can work. Unfortunately, this is a bit slower due to the extra process overhead: $ cd t/perf && ./run 348d4f2 HEAD p7000-filter-branch.sh [...] Test 348d4f2 HEAD -------------------------------------------------------------- 7000.2: noop filter 3.76(0.24+0.26) 4.54(0.28+0.24) +20.7% We could try to make git_commit_non_empty_tree more clever. However, the value of $tree here is technically user-visible. The user can provide arbitrary shell code at this stage, which could itself have a similar assumption to what is in git_commit_non_empty_tree. So the conservative choice to fix this regression is to take the 20% hit and give the pre-348d4f2 behavior. We still end up much faster than before the optimization: $ cd t/perf && ./run 348d4f2^ HEAD p7000-filter-branch.sh [...] Test 348d4f2^ HEAD -------------------------------------------------------------- 7000.2: noop filter 9.51(4.32+0.40) 4.51(0.28+0.23) -52.6% Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/filter-branch-no-index'

2015-12-04T19:19:10Z

Speed up filter-branch for cases where we only care about rewriting commits, not tree data. * jk/filter-branch-no-index: filter-branch: skip index read/write when possible

Merge branch 'maint'

2015-12-01T22:32:38Z

* maint: http: treat config options sslCAPath and sslCAInfo as paths Documentation/diff: give --word-diff-regex=. example filter-branch: deal with object name vs. pathname ambiguity in tree-filter check-ignore: correct documentation about output git-p4: clean up after p4 submit failure git-p4: work with a detached head git-p4: add option to system() to return subshell status git-p4: add failing test for submit from detached head remote-http(s): support SOCKS proxies t5813: avoid creating urls that break on cygwin Escape Git's exec path in contrib/rerere-train.sh script allow hooks to ignore their standard input stream rebase-i-exec: Allow space in SHELL_PATH Documentation: make environment variable formatting more consistent

filter-branch: deal with object name vs. pathname ambiguity in tree-filter

2015-11-24T23:37:50Z

'git filter-branch' fails complaining about an ambiguous argument, if a tree-filter renames a path and the new pathname happens to match an existing object name. After the tree-filter has been applied, 'git filter-branch' looks for changed paths by running: git diff-index -r --name-only --ignore-submodules $commit which then, because of the lack of disambiguating double-dash, can't decide whether to treat '$commit' as revision or path and errors out. Add that disambiguating double-dash after 'git diff-index's revision argument to make sure that '$commit' is interpreted as a revision. Signed-off-by: SZEDER Gábor Signed-off-by: Jeff King

filter-branch: skip index read/write when possible

2015-11-06T17:35:49Z

If the user specifies an index filter but not a tree filter, filter-branch cleverly avoids checking out the tree entirely. But we don't do the next level of optimization: if you have no index or tree filter, we do not need to read the index at all. This can greatly speed up cases where we are only changing the commit objects (e.g., cementing a graft into place). Here are numbers from the newly-added perf test: Test HEAD^ HEAD --------------------------------------------------------------- 7000.2: noop filter 13.81(4.95+0.83) 5.43(0.42+0.43) -60.7% Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jk/filter-branch-use-of-sed-on-incomplete-line'

2015-10-16T21:42:47Z

A recent "filter-branch --msg-filter" broke skipping of the commit object header, which is fixed. * jk/filter-branch-use-of-sed-on-incomplete-line: filter-branch: remove multi-line headers in msg filter

filter-branch: remove multi-line headers in msg filter

2015-10-12T18:23:19Z

df062010 (filter-branch: avoid passing commit message through sed) introduced a regression when filtering commits with multi-line headers, if the header contains a blank line. An example of this is a gpg-signed commit: $ git cat-file commit signed-commit tree 3d4038e029712da9fc59a72afbfcc90418451630 parent 110eac945dc1713b27bdf49e74e5805db66971f0 author A U Thor 1112912413 -0700 committer C O Mitter 1112912413 -0700 gpgsig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlYXADwACgkQE7b1Hs3eQw23CACgldB/InRyDgQwyiFyMMm3zFpj pUsAnA+f3aMUsd9mNroloSmlOgL6jIMO =0Hgm -----END PGP SIGNATURE----- Adding gpg As a consequence, "filter-branch --msg-filter cat" (which should leave the commit message unchanged) spills the signature (after the internal blank line) into the original commit message. The reason is that although the signature is indented, making the line a whitespace only line, the "read" call is splitting the line based on the shell's IFS, which defaults to . The leading space is consumed and $header_line is empty, causing the "skip header lines" loop to exit. The rest of the commit object is then re-used as the rewritten commit message, causing the new message to include the signature of the original commit. Set IFS to an empty string for the "read" call, thus disabling the word splitting, which causes $header_line to be set to the non-empty value ' '. This allows the loop to fully consume the header lines before emitting the original, intact commit message. [jc: this is literally based on MJG's suggestion] Signed-off-by: Michael J Gruber Signed-off-by: James McCoy Signed-off-by: Junio C Hamano

filter-branch: make report-progress more readable

2015-09-21T22:19:06Z

The name of some variables that are used very locally in this function were overly long; they were making the lines harder to read and the longer names didn't add much more information. Signed-off-by: Junio C Hamano

filter-branch: add passed/remaining seconds on progress

2015-09-21T22:19:06Z

adds seconds progress and estimated seconds time if getting the current timestamp is supported by the date +%s command Signed-off-by: Gabor Bernat Signed-off-by: Junio C Hamano