Jon Smirl <jonsmirl@xxxxxxxxx> wrote: > On 9/13/06, Petr Baudis <pasky@xxxxxxx> wrote: > >You could also stash the ref to refs/heads-abandoned/ instead of > >refs/heads/ if you want to keep the junk around for some reason. Of > >course you don't get the nice marker with explanation of why is this > >abandoned and who decided that, but you can just use an empty commit for > >the same purpose. > > > >Object classes are precious things and we shouldn't get carried away. > > If this is done with an object there should probably be some way to > encode it into the existing commit object. I agree completely with what Petr is saying. Allocating a new class of object in Git is a *major* deal. We don't really have any IDs left. Tags would quite easily carry information stating that the branch is considered abandoned, who abandoned it, and when the did so. The tags can also easily be saved off into a refs/abandoned directory. > Moving the refs into refs/abandoned would work too. We would need new > git commands to do this and flags on the visualization tools to > include the abandoned branches. I fail to see why. If a branch is abandoned then its not merged into any of the active branches. If this is the case then gitk doesn't display it when viewing an active branch. So what's the problem? > On the other hand doing this is > recording state about the repository in the refs directory instead of > writing this state into the repo itself. Same difference. The repository is a union of the objects stored in the objects directory and the pack files and the symbolic ref names holding the heads of the commit chains. We're already talking about some other ways to handle larger sets of refs, and Linus has contributed some cleanup code heading in that direction. The refs *are* the repository. -- Shawn. - 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