On Sunday 20 March 2011, Hallvard B Furuseth wrote:
> Thomas Rast writes:
> >Johan Herland wrote:
> >> Looking at git-rebase.sh (where it _is_ implemented), it seems to be a
> >> matter of feeding "old_sha1 new_sha1" pairs into a "rewritten" file,
> >> and then passing that file to the stdin of "git notes copy
> >> --for-rewrite=filter- branch" (followed by passing the same file to
> >> the "post-rewrite" hook).
>
> That appends to the notes history instead of replacing it, which seems
> broken to me. So I'm doing fast-export <notes> | edit; fast-import.
Yeah, Rewriting the notes history along with the "real" history requires a
bit more work. In reality, though, if the notes history is not interesting
in itself, you can first do the notes rewrite I describe above, next prune
the notes tree ("git notes prune") to remove the old notes from the notes
tree, then finally drop the entire notes history except the last commit
(using grafts + filter-branch, or using commit-tree to simply wrapping the
notes tree object in a new parent-less notes commit).
> > I had a patch for this back when post-rewrite was invented,
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/139919/focus=1
> > 39917
> >
> > but Hannes replied that it should grow a real notes filter, and while
> > I dropped it there, I tend to agree with him. Feel free to pick it up
> > again.
>
> A notes filter would be nice, but I don't understand why there's no
> post-rewrite hook or option to let us get at the rewrite info before
> it is deleted. For one thing a notes filter might not do just what is
> intended (as above), but one might want the mapping info for other
> things too. E.g. just to save it in case there are mailings floating
> around which refer to old commit IDs.
We should probably apply Thomas' post-rewrite patch in any case. It gives
the post-rewrite hook access to both the old and new commit IDs, so should
have all the info you need to do whatever you want with the repo.
Note that after filter-branch is done, you should still be able to access
the old objects (by using the old commit IDs directly), at least until the
next "git gc".
> In any case, thanks for the answers. I guess I can live with copying
> the git-filter-branch script when needed, it's not as if I run that
> every day.
Yeah, using filter-branch on an everyday basis would sound like a
fundamental workflow problem. ;)
Have fun! :)
...Johan
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html