Question on git-filter-branch

Question on git-filter-branch

[Bill Lear]

I'm testing out git-filter-branch, as I would like to use it to remove
proprietary information from our repository.

I created a test repo with "sensitive information" in a file 'A', some
other "plain" information, more sensitive stuff in file 'D', a subdirectory
of sensitive information (some of this added on a branch 'branch_1',
some added on master):

% ls -F sensitive
A  B  C  D  sensitive_stuff/

I then cloned this repo and tried the filter:

% git clone sensitive sensitive.clone
% cd sensitive.clone
% git filter-branch --index-filter 'git update-index --remove A' HEAD
Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
Ref 'refs/heads/master' was rewritten

These refs were rewritten:
% ls
A  B  C  D  sensitive_stuff

Ok, so it doesn't list the refs, so I do git status:

% git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   A
#

So, it seems to have done something to A, but I don't know what to do
next.

The man page says: "Now, you will get the rewritten history saved in
the branch newbranch (your current branch is left untouched)."  Well,
I don't see any new branch created:

% git branch -a
* master
  origin/HEAD
  origin/branch_1
  origin/master

Then next part of the man page counsels that "To set a commit ...",
but I'm not sure if that is what I want to do (I think it is).
However, I'm not sure what the 'graft-id' refers to, or if I'm
supposed to type in the command as specified, especially since this is
followed by this caution: "if the parent string is empty - which
happens when we are dealing with the initial commit - add graftcommit
as a parent".  Here, I'm unsure what graftcommit is, most especially
since the use of 'graft' first appears as 'graft-id'...

Could someone help, please?


Bill

[PATCH 1/2] fix filter-branch documentation

[Johannes Schindelin]

The man page for filter-branch still talked about writing the result
to the branch "newbranch".  This is hopefully the last place where the
old behaviour was described.

Noticed by Bill Lear.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/git-filter-branch.txt |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index c878ed3..ba9b4fb 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -180,8 +180,7 @@ A significantly faster version:
 git filter-branch --index-filter 'git update-index --remove filename' HEAD
 --------------------------------------------------------------------------
 
-Now, you will get the rewritten history saved in the branch 'newbranch'
-(your current branch is left untouched).
+Now, you will get the rewritten history saved in HEAD.
 
 To set a commit (which typically is at the tip of another
 history) to be the parent of the current initial commit, in
-- 
1.5.3.4.1223.ga973c

[PATCH 2/2] filter-branch: update current branch when rewritten

[Johannes Schindelin]

Earlier, "git filter-branch --<options> HEAD" would not update the
working tree after rewriting the branch.  This commit fixes it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	Bill, I hope this clarifies some things for you, too...

 git-filter-branch.sh     |   15 +++++++++++++++
 t/t7003-filter-branch.sh |    4 +++-
 2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a12f6c2..ffcc408 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -94,6 +94,10 @@ USAGE="[--env-filter <command>] [--tree-filter <command>] \
 
 . git-sh-setup
 
+git diff-files --quiet &&
+	git diff-index --cached --quiet HEAD ||
+	die "Cannot rewrite branch(es) with a dirty working directory."
+
 tempdir=.git-rewrite
 filter_env=
 filter_tree=
@@ -196,6 +200,9 @@ do
 	esac
 done < "$tempdir"/backup-refs
 
+ORIG_GIT_DIR="$GIT_DIR"
+ORIG_GIT_WORK_TREE="$GIT_WORK_TREE"
+ORIG_GIT_INDEX_FILE="$GIT_INDEX_FILE"
 export GIT_DIR GIT_WORK_TREE=.
 
 # These refs should be updated if their heads were rewritten
@@ -413,4 +420,12 @@ echo
 test $count -gt 0 && echo "These refs were rewritten:"
 git show-ref | grep ^"$orig_namespace"
 
+unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
+test -z "$ORIG_GIT_DIR" || GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
+test -z "$ORIG_GIT_WORK_TREE" || GIT_WORK_TREE="$ORIG_GIT_WORK_TREE" &&
+	export GIT_WORK_TREE
+test -z "$ORIG_GIT_INDEX_FILE" || GIT_INDEX_FILE="$ORIG_GIT_INDEX_FILE" &&
+	export GIT_INDEX_FILE
+git read-tree -u -m HEAD
+
 exit $ret
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index e935b20..2089351 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -41,7 +41,9 @@ test_expect_success 'rewrite, renaming a specific file' '
 '
 
 test_expect_success 'test that the file was renamed' '
-	test d = $(git show HEAD:doh)
+	test d = $(git show HEAD:doh) &&
+	test -f doh &&
+	test d = $(cat doh)
 '
 
 git tag oldD HEAD~4
-- 
1.5.3.4.1223.ga973c

Re: [PATCH 2/2] filter-branch: update current branch when rewritten

[Bill Lear]

On Wednesday, October 17, 2007 at 03:23:10 (+0100) Johannes Schindelin writes:
>
>Earlier, "git filter-branch --<options> HEAD" would not update the
>working tree after rewriting the branch.  This commit fixes it.
>
>Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>---
>
>	Bill, I hope this clarifies some things for you, too...

Thanks very much.  I hope so, too.  I'll pull this in to my tree
when it gets into the git repository (how do I know when that happens,
or do I just need to pull and inspect?).


Bill

Re: [PATCH 2/2] filter-branch: update current branch when rewritten

[Shawn O. Pearce]

Bill Lear <rael@zopyra.com> wrote:
> On Wednesday, October 17, 2007 at 03:23:10 (+0100) Johannes Schindelin writes:
> >
> >Earlier, "git filter-branch --<options> HEAD" would not update the
> >working tree after rewriting the branch.  This commit fixes it.
> >
> >Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> >---
> >
> >	Bill, I hope this clarifies some things for you, too...
> 
> Thanks very much.  I hope so, too.  I'll pull this in to my tree
> when it gets into the git repository (how do I know when that happens,
> or do I just need to pull and inspect?).

This is actually already in my maint branch:

  git://repo.or.cz/git/spearce.git
  http://repo.or.cz/r/git/spearce.git

The best way to know if a given patch has been applied is to just
fetch every so often and look.  But you are also subscribed to
the mailing list and there's usually a weekly "What's in git.git"
and a "What's cooking in git.git" messages sent describing the
recent changes.  Monitoring these can also tell you when it may be
a good time for you to pull in a more recent version.

My last What's in/What's cooking messages were sent out on Monday.
I've got a lot of stuff from folks since then going into my tree
(the above is one of them) so I'll probably wrap up this week with
another set of messages tomorrow.

Of course the maintainer could send an email for every patch that
he/she applies, but the mailing list volume is already quite high.
Junio (and myself) both prefer to not bother responding to accepted
patches when they come from regular contributors, as we know the
regular contributor will be pulling in the near future anyway.

-- 
Shawn.