git/git-filter-branch.sh, branch v1.6.4

Convert to use quiet option when available

2009-04-23T02:05:37Z

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

git-filter-branch: avoid collisions with variables in eval'ed commands

2009-03-25T23:35:52Z

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

Improve error message for git-filter-branch

2009-03-04T08:56:52Z

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

filter-branch -d: Export GIT_DIR earlier

2009-02-18T19:15:17Z

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

filter-branch: Add more error-handling

2009-02-12T02:26:52Z

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: http://kerneltrap.org/mailarchive/git/2009/1/28/4835614 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

Merge branch 'js/filter-branch-submodule'

2009-02-07T19:09:48Z

* js/filter-branch-submodule: filter-branch: do not consider diverging submodules a 'dirty worktree' filter-branch: Fix fatal error on bare repositories

filter-branch: do not consider diverging submodules a 'dirty worktree'

2009-02-06T01:48:04Z

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

filter-branch: Fix fatal error on bare repositories

2009-02-04T05:54:02Z

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 git-filter-branch.sh: 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 git-filter-branch.sh to restore the original environment variables before trying to call is_bare_repository. Signed-off-by: Junio C Hamano

filter-branch: add git_commit_non_empty_tree and --prune-empty.

2009-01-11T01:35:58Z

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

filter-branch: use git rev-parse -q

2008-12-03T22:27:17Z

Signed-off-by: Miklos Vajna Signed-off-by: Junio C Hamano