On Tue, 20 Nov 2007 10:32:39 -0800, Carl Worth wrote:
> The rev-list is not optional, and a range of a..b will not rewrite
> only b.
It has since been explained to me that the original text was intended
to describe which branch tips will get updated. In that case, my
rewrite of the documentation leaves that part out.
Even so, I'm a bit confused by what the behavior is. When I run:
git filter-branch HEAD
The output I get is:
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
And nothing else after that. That's definitely confusing.
Also confusing is that the documentation emphasizes that I should
verify the newly rewritten heads against the backups in
refs/original. But I'm not given any guidance on how to access the
refs in refs/original. I don't know of standard git tools to list
these, ("git branch", "git branch -r", and "gitk --all" don't show
them for example). I can use something like "git log
original/refs/heads/master" but it takes a fair amount of knowledge to
get to that point.
Finally, I did my filter in multiple steps and found myself having to
do lots of manual cleanup. For example, on my second run of
git-filter-branch:
Error: Namespace refs/original/ not empty
Cleanup: rm -r .git/refs/original
And that failed attempt then triggers another problem:
Error: .git-rewrite already exists, please remove it
Cleanup: rm -r .git-rewrite
The second error was nice enough to tell me how to fix the problem,
(nothing ever indicates the need to cleanup refs/original that I can
tell). But I think this second error should never occur. The
filter-branch program should cleanup after itself if it fails.
Finally, I wonder if there's a better solution to the messiness of
making backups in refs/original, correctly documenting what branch
heads get rewritten, and then hoping that the user can find the
backups, use them to verify the new heads, and then clean them up.
One idea is to have two new sub-commands for git-filter-branch. Maybe
something like:
git filter-branch --accept
git filter-branch --reject # or --undo or whatever
And these would do all the cleanup necessary.
During the intermediate state, (after filter-branch and before
"filter-branch --accept"), it would be nice if it were easier to
verify the results. For example, if filter-branch stored its backups
in refs/heads/rewrite-original/* instead of refs/original/refs/heads/*
then they would show up automatically in "gitk --all" for example.
Anyway, those are some ideas if anyone wants to hack on this further.
-Carl
Attachment:
pgpawA7bQCv0X.pgp
Description: PGP signature
