# History rewriting swiss army knife 3 messages from 2006-03-24 to 2006-03-26. Participants: Petr Baudis, Junio C Hamano. Thread: https://gitlist.dev/t/3709 ## Petr Baudis, 2006-03-24 14:08 Subject: History rewriting swiss army knife Message-ID: <20060324140831.GY18185@pasky.or.cz> URL: https://gitlist.dev/e/20060324140831.GY18185%40pasky.or.cz ``` 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. ``` ## Junio C Hamano, 2006-03-24 22:47 Subject: Re: History rewriting swiss army knife Message-ID: <7vek0rzchc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vek0rzchc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060324140831.GY18185@pasky.or.cz> ``` Petr Baudis 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. ``` ## Petr Baudis, 2006-03-26 13:17 Subject: Re: History rewriting swiss army knife Message-ID: <20060326131743.GK18185@pasky.or.cz> URL: https://gitlist.dev/e/20060326131743.GK18185%40pasky.or.cz In-Reply-To: <7vek0rzchc.fsf@assigned-by-dhcp.cox.net> ``` Dear diary, on Fri, Mar 24, 2006 at 11:47:43PM CET, I got a letter where Junio C Hamano said that... > Petr Baudis 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. ```