History rewriting swiss army knife

History rewriting swiss army knife

[Petr Baudis]

  Hi,

  it is not very frequent, but sometimes you really want to rewrite your
history - you need to get rid of a copyright violation or a file with
confidential information slipped through, or who knows what other good
reason you might have. As long as you are aware of the implications of
all the tree/commit ids getting different, why not.

  It's never been so easy before - I've written cg-admin-rewritehist,
which will execute your filters for each commit (which can rewrite the
tree contents, just the tree itself through the index, committer/author
information and commit message) while the script will obviously preserve
all the other information like merges, author/committer information etc.
The script will place the rewritten history on a newly created branch.

  If you are interested, you can also look at the script at

	http://kernel.org/git/?p=cogito/cogito.git;a=blob;f=cg-admin-rewritehist

but it has few Cogito dependencies.

  Have fun,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: History rewriting swiss army knife

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>   It's never been so easy before - I've written cg-admin-rewritehist,
> which will execute your filters for each commit (which can rewrite the
> tree contents, just the tree itself through the index, committer/author
> information and commit message) while the script will obviously preserve
> all the other information like merges, author/committer information etc.

Hmph.  The above description sounds like you are not allowing
the user's custom script to drop existing parent (or graft a new
one) while rewriting.  I have not looked at how you are
interfacing with user's custom script, but I sort-of expected
you to throw a commit at it from older to newer (i.e. topo-order
in reverse), along with the names of already re-written commit
objects that are parents of taht commit, and have it build a
rewritten commit and report its object name back to you.

But it sounds like a useful tool in certain situations -- I
sounded mildly negative last night, but after you gave an
example of cleaning up a half-botched import, I changed my mind.

Re: History rewriting swiss army knife

[Petr Baudis]

Dear diary, on Fri, Mar 24, 2006 at 11:47:43PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> >   It's never been so easy before - I've written cg-admin-rewritehist,
> > which will execute your filters for each commit (which can rewrite the
> > tree contents, just the tree itself through the index, committer/author
> > information and commit message) while the script will obviously preserve
> > all the other information like merges, author/committer information etc.
> 
> Hmph.  The above description sounds like you are not allowing
> the user's custom script to drop existing parent (or graft a new
> one) while rewriting.  I have not looked at how you are
> interfacing with user's custom script, but I sort-of expected
> you to throw a commit at it from older to newer (i.e. topo-order
> in reverse), along with the names of already re-written commit
> objects that are parents of taht commit, and have it build a
> rewritten commit and report its object name back to you.

There are rather several "filters" (user scripts) which are called at
various stages of the commit rewrite. In sum they are doing the same
thing as the single user script would, but cg-admin-rewritehist will
prepare some things to you so that everyone does not have to write the
common stuff again and again.

The net flexibility loss was zero, except two things:

* The parents list construction was hardcoded. Now I added a parent
  filter which gets the parent string on stdin (including the -p bits,
  but life's tough) and let it rewrite it (e.g. add stuff at the end).
  So to "etch a graft":

	cg-admin-rewritehist --parent-filter sed\ 's/^$/-p graftcommitid/' newbranch

  assuming single-root history; but you have current commit id in
  $GIT_COMMIT so you can go wild:

	cg-admin-rewritehist --parent-filter 'cat; [ "$GIT_COMMIT" = "COMMIT" ] && echo "-p GRAFTCOMMIT"' newbranch

* A new commit would be always created. Sometimes you might want to
  omit some commits. Now I added a commit filter which would be
  called instead of the git-commit-tree command.

  To remove commits authored by "Darl McBribe" from the history:

	cg-admin-rewritehist --commit-filter '
		if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ]; then
			shift
			while [ -n "$1" ]; do
				shift; echo "$1"; shift
			done
		else
			git-commit-tree "$@"
		fi' newbranch

  (note that this will handle even Darl's merges).

Thanks for the inspiration,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.