On Thu, Jul 03, 2008 at 07:38:21PM -0400, Adam Brewster wrote:
> There's still plenty of potential for improvements, like a --gc mode
> to clean up basis files, a --rewind option to undo an incorrect
> --update, or improvements in the way it calculates intersections, but
> I think that with these changes the system is as simple as possible
> while maximizing flexibility, utility, and usability.
I was thinking about Mark's approach, and I think there are two distinct
differences from yours:
1. he updates the basis upon bundle creation, rather than as a
separate step (and I have already commented on this)
2. he stores the basis in the refs hierarchy
I actually think '2' makes a lot of sense. Storing the basis as refs
gets you:
- an easy implementation; you use existing git tools
- correct reachability analysis, since the refs will be taken into
account by git-fsck, meaning you won't ever accidentally prune
your basis objects
- free logging of your basis history, in the form of reflogs
- free gc in the usual reflog way
IIRC, Mark suggested putting them under refs/remotes/<bundle>, and you
objected that you didn't want to clutter that hierarchy. If that is a
problem, you can always use refs/basis/<bundle>, which will be ignored
by gitk and "git branch -a", but will be correctly handled by other
tools.
And then suddenly your perl script gets a lot simpler, and is either a
short shell script, or even better, can be written in C as part of
git-bundle. So you would have something like "git bundle --update-basis
<basis>" instead of "git-basis", and a config option like
"bundle.autoUpdateBasis" to update the basis whenever you create a
bundle.
-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
