On Tue, Dec 09, 2014 at 04:01:50PM +0000, Roberto Tyley wrote:
> > I also don't know if BFG keeps backup refs around (filter-branch, for
> > example, writes a copy of the original refs into refs/original; you
> > would want to delete that if you're trying to slim down the repo).
>
> The BFG reports the ref changes to the command line (and outputs a
> full list of changed object-ids in
> repo-name.git.bfg-report/[datetime]/object-id-map.old-new.txt) but
> doesn't keep refs (like refs/original) around because that would get
> in the way of the BFG's explicit intended use-case of removing
> unwanted data.
Thanks for explaining; that information may come in handy.
I actually think filter-branch's "refs/original" is a bit outdated at
this point. The information is there in the reflogs already, and
dealing with refs/original often causes confusion in my experience. It
could probably use a "git filter-branch --restore" or something to
switch each $ref to $ref@{1} (after making sure that the reflog entry
was from filter-branch, of course).
Not that I expect you to want to work on filter-branch. :) But maybe
food for thought for a BFG feature.
-Peff
--
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