path: root/
AgeCommit message (Collapse)Author
2010-08-27filter-branch: retire --remap-to-ancestorCsaba Henk
We can be clever and know by ourselves when we need the behavior implied by "--remap-to-ancestor". No need to encumber users by having them exposed to it as a tunable. (Option kept for backward compatibility, but it's now a no-op.) Signed-off-by: Csaba Henk <> Signed-off-by: Junio C Hamano <>
2010-02-12Merge branch 'maint'Junio C Hamano
* maint: filter-branch: Fix error message for --prune-empty --commit-filter
2010-02-12filter-branch: Fix error message for --prune-empty --commit-filterJacob Helwig
Running filter-branch with --prune-empty and --commit-filter reports: "Cannot set --prune-empty and --filter-commit at the same time". Change it to use the correct option name: --commit-filter Signed-off-by: Jacob Helwig <> Signed-off-by: Junio C Hamano <>
2010-02-03Merge branch 'ms/filter-branch-submodule'Junio C Hamano
* ms/filter-branch-submodule: filter-branch: Add tests for submodules in tree-filter filter-branch: Fix to allow replacing submodules with another content
2010-01-28filter-branch: Fix to allow replacing submodules with another contentMichal Sojka
When git filter-branch is used to replace a submodule with another content, it always fails on the first commit. Consider a repository with submod directory containing a submodule. The following command to remove the submodule and replace it with a file fails: git filter-branch --tree-filter 'rm -rf submod && git rm -q submod && mkdir submod && touch submod/file' with an error: error: submod: is a directory - add files inside instead The reason is that git diff-index, which generates the first part of the list of files updated by the tree filter, emits also the removed submodule even if it was replaced by a real directory. Signed-off-by: Michal Sojka <> Signed-off-by: Junio C Hamano <>
2010-01-26fix portability issues with $ in double quotesStephen Boyd
Using a dollar sign in double quotes isn't portable. Escape them with a backslash or replace the double quotes with single quotes. Signed-off-by: Stephen Boyd <> Signed-off-by: Junio C Hamano <>
2010-01-07Merge branch 'js/filter-branch-prime'Junio C Hamano
* js/filter-branch-prime: filter-branch: remove an unnecessary use of 'git read-tree'
2009-12-16filter-branch: remove an unnecessary use of 'git read-tree'Johannes Sixt
The intent of this particular call to 'git read-tree' was to fill an index. But in fact, it only allocated an empty index. Later in the program, the index is filled anyway by calling read-tree with specific commits, and considering that elsewhere the index is even removed (i.e., it is not relied upon that the index file exists), this first call of read-tree is completely redundant. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-11-25Merge branch 'rs/work-around-grep-opt-insanity'Junio C Hamano
* rs/work-around-grep-opt-insanity: Protect scripted Porcelains from GREP_OPTIONS insanity mergetool--lib: simplify guess_merge_tool() Conflicts:
2009-11-24Protect scripted Porcelains from GREP_OPTIONS insanityJunio C Hamano
If the user has exported the GREP_OPTIONS environment variable, the output from "grep" and "egrep" in scripted Porcelains may be different from what they expect. For example, we may want to count number of matching lines, by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use. The approach taken by this change to address this issue is to protect only our own use of grep/egrep. Because we do not unset it at the beginning of our scripts, hook scripts run from the scripted Porcelains are exposed to the same insanity this environment variable causes when grep/egrep is used to implement logic (e.g. "grep | wc -l"), and it is entirely up to the hook scripts to protect themselves. On the other hand, applypatch-msg hook may want to show offending words in the proposed commit log message using grep to the end user, and the user might want to set GREP_OPTIONS=--color to paint the match more visibly. The approach to protect only our own use without unsetting the environment variable globally will allow this use case. Signed-off-by: Junio C Hamano <>
2009-11-13filter-branch: nearest-ancestor rewriting outside subdir filterThomas Rast
Since a0e4639 (filter-branch: fix ref rewriting with --subdirectory-filter, 2008-08-12) git-filter-branch has done nearest-ancestor rewriting when using a --subdirectory-filter. However, that rewriting strategy is also a useful building block in other tasks. For example, if you want to split out a subset of files from your history, you would typically call git filter-branch -- <refs> -- <files> But this fails for all refs that do not point directly to a commit that affects <files>, because their referenced commit will not be rewritten and the ref remains untouched. The code was already there for the --subdirectory-filter case, so just introduce an option that enables it independently. Signed-off-by: Thomas Rast <> Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-11-13filter-branch: stop special-casing $filter_subdir argumentThomas Rast
Handling $filter_subdir in the usual way requires a separate case at every use, because the variable is empty when unused. Furthermore, --subdirectory-filter supplies its own '--', and if the user provided one himself, such as in git filter-branch --subdirectory-filter subdir -- --all -- subdir/file an extra '--' was used as path filter in the call to git-rev-list that determines the commits that shall be rewritten. To keep the argument handling sane, we filter $@ to contain only the non-revision arguments, and store all revisions in $ref_args. The $ref_args are easy to handle since only the SHA1s are needed; the actual branch names have already been stored in $tempdir/heads at this point. An extra separating -- is only required if the user did not provide any non-revision arguments, as the latter disambiguate the $filter_subdir following after them (or fail earlier because they are ambiguous themselves). Thanks to Johannes Sixt for suggesting this solution. Signed-off-by: Thomas Rast <> Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-08-18filter-branch: make the usage string fit on 80 chars terminals.Matthieu Moy
It used to be a single, huge line, badly wrapped by xterm. Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2009-04-23Convert to use quiet option when availableDan Loewenherz
A minor fix that eliminates usage of "2>/dev/null" when --quiet or -q has already been implemented. Signed-off-by: Dan Loewenherz <> Signed-off-by: Junio C Hamano <>
2009-03-25git-filter-branch: avoid collisions with variables in eval'ed commandsElijah Newren
Avoid using simple variable names like 'i', since user commands are eval'ed and may clash with and overwrite our values. Signed-off-by: Elijah Newren <> Acked-by: Petr Baudis <> Signed-off-by: Junio C Hamano <>
2009-03-04Improve error message for git-filter-branchJohn Tapsell
Tell the user that a backup (original) already exists, and how to solve this problem (with -f option) Signed-off-by: John Tapsell <> Signed-off-by: Junio C Hamano <>
2009-02-18filter-branch -d: Export GIT_DIR earlierLars Noschinski
The improved error handling catches a bug in filter-branch when using -d pointing to a path outside any git repository: $ git filter-branch -d /tmp/foo master fatal: Not a git repository (or any of the parent directories): .git This error message comes from git for-each-ref in line 224. GIT_DIR is set correctly by git-sh-setup (to the foo.git repository), but not exported (yet). Signed-off-by: Lars Noschinski <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2009-02-12filter-branch: Add more error-handlingEric Kidd
9273b56 (filter-branch: Fix fatal error on bare repositories, 2009-02-03) fixed a missing check of return status from an underlying command in git-filter-branch, but there still are places that do not check errors. For example, the command does not pay attention to the exit status of the command given by --commit-filter. It should abort in such a case. This attempts to fix all the remaining places that fails to checks errors. In two places, I've had to break apart pipelines in order to check the error code for the first stage of the pipeline, as discussed here: Feedback on this patch was provided by Johannes Sixt, Johannes Schindelin and Junio C Hamano. Thomas Rast helped with pipeline error handling. Signed-off-by: Eric Kidd <> Signed-off-by: Junio C Hamano <>
2009-02-07Merge branch 'js/filter-branch-submodule'Junio C Hamano
* js/filter-branch-submodule: filter-branch: do not consider diverging submodules a 'dirty worktree' filter-branch: Fix fatal error on bare repositories
2009-02-06filter-branch: do not consider diverging submodules a 'dirty worktree'Johannes Schindelin
At the end of filter-branch in a non-bare repository, the work tree is updated with "read-tree -m -u HEAD", to carry the change forward in case the current branch was rewritten. In order to avoid losing any local change during this step, filter-branch refuses to work when there are local changes in the work tree. This "read-tree -m -u HEAD" operation does not affect what commit is checked out in a submodule (iow, it does not touch .git/HEAD in a submodule checkout), and checking if there is any local change to the submodule is not useful. Staged submodules _are_ considered to be 'dirty', however, as the "read-tree -m -u HEAD" could result in loss of staged information otherwise. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2009-02-04filter-branch: Fix fatal error on bare repositoriesEric Kidd
When git filter-branch is run on a bare repository, it prints out a fatal error message: $ git filter-branch branch Rewrite 476c4839280c219c2317376b661d9d95c1727fc3 (9/9) WARNING: Ref 'refs/heads/branch' is unchanged fatal: This operation must be run in a work tree Note that this fatal error message doesn't prevent git filter-branch from exiting successfully. (Why doesn't git filter-branch actually exit with an error when a shell command fails? I'm not sure why it was designed this way.) This error message is caused by the following section of code at the end of if [ "$(is_bare_repository)" = false ]; then unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE test -z "$ORIG_GIT_DIR" || { GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR } ... elided ... git read-tree -u -m HEAD fi The problem is the call to $(is_bare_repository), which is made before GIT_DIR and GIT_WORK_TREE are restored. This call always returns "false", even when we're running in a bare repository. But this means that we will attempt to call 'git read-tree' even in a bare repository, which will fail and print an error. This patch modifies to restore the original environment variables before trying to call is_bare_repository. Signed-off-by: Junio C Hamano <>
2009-01-11filter-branch: add git_commit_non_empty_tree and --prune-empty.Pierre Habouzit
git_commit_non_empty_tree is added to the functions that can be run from commit filters. Its effect is to commit only commits actually touching the tree and that are not merge points either. The option --prune-empty is added. It defaults the commit-filter to 'git_commit_non_empty_tree "$@"', and can be used with any other combination of filters, except --commit-hook that must used 'git_commit_non_empty_tree "$@"' where one puts 'git commit-tree "$@"' usually to achieve the same result. Signed-off-by: Pierre Habouzit <> Signed-off-by: Junio C Hamano <>
2008-12-03filter-branch: use git rev-parse -qMiklos Vajna
Signed-off-by: Miklos Vajna <> Signed-off-by: Junio C Hamano <>
2008-09-03Merge branch 'tr/filter-branch'Junio C Hamano
* tr/filter-branch: revision --simplify-merges: make it a no-op without pathspec revision --simplify-merges: do not leave commits unprocessed revision --simplify-merges: use decoration instead of commit->util field Documentation: rev-list-options: move --simplify-merges documentation filter-branch: use --simplify-merges filter-branch: fix ref rewriting with --subdirectory-filter filter-branch: Extend test to show rewriting bug Topo-sort before --simplify-merges revision traversal: show full history with merge simplification revision.c: whitespace fix
2008-08-22filter-branch: Grok special characters in tag namesJohannes Sixt
The tag rewriting code used a 'sed' expression to substitute the new tag name into the corresponding field of the annotated tag object. But this is problematic if the tag name contains special characters. In particular, if the tag name contained a slash, then the 'sed' expression had a syntax error. We now protect against this by using 'printf' to assemble the tag header. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-08-13filter-branch: use --simplify-mergesThomas Rast
Use rev-list --simplify-merges everywhere. This changes the behaviour of --subdirectory-filter in cases such as O -- A -\ \ \ \- B -- M where A and B bring the same changes to the subdirectory: It now keeps both sides of the merge. Previously, the history would have been simplified to 'O -- A'. Merges of unrelated side histories that never touch the subdirectory are still removed. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2008-08-13filter-branch: fix ref rewriting with --subdirectory-filterThomas Rast
The previous ancestor discovery code failed on any refs that are (pre-rewrite) ancestors of commits marked for rewriting. This means that in a situation A -- B(topic) -- C(master) where B is dropped by --subdirectory-filter pruning, the 'topic' was not moved up to A as intended, but left unrewritten because we asked about 'git rev-list ^master topic', which does not return anything. Instead, we use the straightforward git rev-list -1 $ref -- $filter_subdir to find the right ancestor. To justify this, note that the nearest ancestor is unique: We use the output of git rev-list --parents -- $filter_subdir to rewrite commits in the first pass, before any ref rewriting. If B is a non-merge commit, the only candidate is its parent. If it is a merge, there are two cases: - All sides of the merge bring the same subdirectory contents. Then rev-list already pruned away the merge in favour for just one of its parents, so there is only one candidate. - Some merge sides, or the merge outcome, differ. Then the merge is not pruned and can be rewritten directly. So it is always safe to use rev-list -1. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2008-08-08filter-branch: be more helpful when an annotated tag changesThomas Rast
Previously, git-filter-branch failed if it attempted to update an annotated tag. Now we ignore this condition if --tag-name-filter is given, so that we can later rewrite the tag. If no such option was provided, we warn the user that he might want to run with "--tag-name-filter cat" to achieve the intended effect. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <> Allow running in bare repositoriesPetr Baudis
Commit 46eb449c restricted git-filter-branch to non-bare repositories unnecessarily; git-filter-branch can work on bare repositories just fine. Cc: Johannes Schindelin <> Signed-off-by: Petr Baudis <> Signed-off-by: Junio C Hamano <>
2008-05-28Merge inJunio C Hamano
2008-05-28Revert "filter-branch: subdirectory filter needs --full-history"Johannes Sixt
This reverts commit cfabd6eee1745cfec58cfcb794ce8847e43b888a. I had implemented it without understanding what --full-history does. Consider this history: C--M--N / / / A--B / \ / D-/ where B and C modify a path, X, in the same way so that the result is identical, and D does not modify it at all. With the path limiter X and without --full-history this is simplified to A--B i.e. only one of the paths via B or C is chosen. I had assumed that --full-history would keep both paths like this C--M / / A--B removing the path via D; but in fact it keeps the entire history. Currently, git does not have the capability to simplify to this intermediary case. However, the other extreme to keep the entire history is not wanted either in usual cases. I think we can expect that histories like the above are rare, and in the usual cases we want a simplified history. So let's remove --full-history again. (Concerning t7003, subsequent tests depend on what the test case sets up, so we can't just back out the entire test case.) Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-05-14filter-branch: fix variable export logicJeff King
filter-branch tries to restore "old" copies of some environment variables by using the construct: unset var test -z "$old_var" || var="$old_var" && export var This is just wrong. AND-list and OR-list operators && and || have equal precedence and they bind left to right. The second term, var="$old" assignment always succeeds, so we always end up exporting var. On bash and dash, exporting an unset variable has no effect. However, on some shells (such as FreeBSD's /bin/sh), the shell exports the empty value. This manifested itself in this case as git-filter-branch setting GIT_INDEX_FILE to the empty string, which in turn caused its call to git-read-tree to fail, leaving the working tree pointing at the original HEAD instead of the rewritten one. To fix this, we change the short-circuit logic to better match the intent: test -z "$old_var" || { var="$old_var" && export var } Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2008-05-06Merge branch 'bc/filter-branch'Junio C Hamano
* bc/filter-branch: support nearly proper tag name filtering
2008-03-31filter-branch: Fix renaming a directory in the
Commit d89c1df (filter-branch: don't use xargs -0, 2008-03-12) replaced a 'ls-files | xargs rm' pipeline by 'git clean'. 'git clean' however does not recurse and remove directories by default. Now, consider a tree-filter that renames a directory. 1. For the first commit everything works as expected 2. Then filter-branch checks out the files for the next commit. This leaves the new directory behind because there is no real "branch switching" involved that would notice that the directory can be removed. 3. Then filter-branch invokes 'git clean' to remove exactly those left-overs. But here it does not remove the directory. 4. The next tree-filter does not work as expected because there already exists a directory with the new name. Just add -d to 'git clean', so that empty directories are removed. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <> support nearly proper tag name filteringBrandon Casey
Add support for creating a new tag object and retaining the tag message, author, and date when rewriting tags. The gpg signature, if one exists, will be stripped. This adds nearly proper tag name filtering to filter-branch. Proper tag name filtering would include the ability to change the tagger, tag date, tag message, and _not_ strip a gpg signature if the tag did not change. Signed-off-by: Brandon Casey <> Signed-off-by: Junio C Hamano <>
2008-03-13filter-branch: use $SHELL_PATH instead of 'sh'Jeff King
On some systems, 'sh' isn't very friendly. In particular, t7003 fails on Solaris because it doesn't understand $(). Instead, use the specified SHELL_PATH to run shell code. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2008-03-13filter-branch: don't use xargs -0Jeff King
Some versions of xargs don't understand "-0"; fortunately in this case we can get the same effect by using "git clean". Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2008-03-13tr portability fixesJeff King
Specifying character ranges in tr differs between System V and POSIX. In System V, brackets are required (e.g., '[A-Z]'), whereas in POSIX they are not. We can mostly get around this by just using the bracket form for both sets, as in: tr '[A-Z] '[a-z]' in which case POSIX interpets this as "'[' becomes '['", which is OK. However, this doesn't work with multiple sequences, like: # rot13 tr '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]' where the POSIX version does not behave the same as the System V version. In this case, we must simply enumerate the sequence. This patch fixes problematic uses of tr in git scripts and test scripts in one of three ways: - if a single sequence, make sure it uses brackets - if multiple sequences, enumerate - if extra brackets (e.g., tr '[A]' 'a'), eliminate brackets Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2008-03-08filter-branch: handle "disappearing tree" case correctly in subdir filterJunio C Hamano
The subdirectory filter had a bug to notice that the commit in question did not have anything in the path-limited part of the tree. $commit:$path does not name an empty tree when $path does not appear in $commit. This should fix it. The additional test in t7003 is originally from Kevin Ballard but with fixups. Signed-off-by: Junio C Hamano <>
2008-02-16filter-branch: handle filenames that need quotingJunio C Hamano
The command used a very old fashioned construct to extract filenames out of diff-index and ended up corrupting the output. We can simply use --name-only and pipe into --stdin mode of update-index. It's been like that for the past 2 years or so since a94d994 (update-index: work with c-quoted name). Signed-off-by: Junio C Hamano <>
2008-01-31Revert "filter-branch docs: remove brackets so not to imply revision arg is ↵Junio C Hamano
optional" This reverts commit c41b439244c51b30c60953192816afc91e552578, as we decided to default to HEAD when revision parameters are missing and they are no longer mandatory.
2008-01-31filter-branch: assume HEAD if no revision suppliedBrandon Casey
filter-branch previously took the first non-option argument as the name for a new branch. Since dfd05e38, it now takes a revision or a revision range and modifies the current branch. Update to operate on HEAD by default to conform with standard git interface practice. Signed-off-by: Brandon Casey <> Signed-off-by: Junio C Hamano <>
2008-01-31filter-branch docs: remove brackets so not to imply revision arg is optionalBrandon Casey
Signed-off-by: Brandon Casey <> Signed-off-by: Junio C Hamano <> remove temporary directory on failureBrandon Casey
One of the first things filter-branch does is to create a temporary directory. This directory is eventually removed by the script during normal operation, but is not removed if the script encounters an error. Set a trap to remove it when the script terminates for any reason. Signed-off-by: Brandon Casey <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2008-01-07filter-branch: work correctly with ambiguous refnamesJunio C Hamano
'git-filter-branch branch' could fail producing the error: "Which ref do you want to rewrite?" if existed another branch or tag, which name was 'branch-something' or 'something/branch'. [jc: original report and fix were done between Dmitry Potapov and Dscho; I rewrote it using "rev-parse --symbolic-full-name"] Signed-off-by: Junio C Hamano <> more portable tr usage: use \012, not \n.Jim Meyering
I hesitate to suggest this, since GNU tr has accepted \n for 15 years, but there are supposedly a few crufty vendor-supplied versions of tr still in use. Also, all of the other uses of tr-with-newline in git use \012. Signed-off-by: Jim Meyering <> Signed-off-by: Junio C Hamano <>
2007-12-18filter-branch: Remove broken and unnecessary summary of rewritten refs.Johannes Sixt
There was an attempt to list the refs that were rewritten by filtering the output of 'git show-ref' for 'refs/original'. But it got the grep argument wrong, which did not account for the SHA1 that is listed before the ref. Moreover, right before this summary is the loop that actually does the rewriting, and the rewritten refs are listed there anyway. So this extra summary is plainly too verbose. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2007-12-18the use of 'tr' in the test suite isn't really portableH.Merijn Brand
Some versions of 'tr' only accept octal codes if entered with three digits, and therefor misinterpret the '\0' in the test suite. Some versions of 'tr' reject the (needless) use of character classes. Signed-off-by: H.Merijn Brand <> Signed-off-by: Junio C Hamano <>
2007-11-29Replace instances of export VAR=VAL with VAR=VAL; export VARJohannes Schindelin
It might be POSIX, but there are shells that do not like the expression 'export VAR=VAL'. To be on the safe side, rewrite them into 'VAR=VAL' and 'export VAR'. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2007-11-29Merge branch 'maint'Junio C Hamano
* maint: scripts: do not get confused with HEAD in work tree Improve description of git-branch -d and -D in man page.