Jon Smirl <jonsmirl@xxxxxxxxx> wrote: > On 9/13/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > >Hi, > > > >On Wed, 13 Sep 2006, Jon Smirl wrote: > > > >> 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. 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. > > > >Well, the refs directory is _part_ of the repository. Think about it, if > >you do not know which branches are in the object database, you lack a lot > >of information. > > If you delete all of your heads you can recover them by following all > of the chains in the repo to find them. Doing this would recover the > abandoned branches too but it would mix them up with the active heads. > This is not a big deal but it is info that is getting stored outside > of the object db. No. Being able to get a ref back like that is like saying that I can get files back in ext2 by deleting them then running fsck and restoring the lost inodes to '/lost+found'. Sure the data is there but there's no way to tell which file is which! The name of a ref, like the name of a file, is pretty important when it comes to describing it. Just having the SHA1 ID of 100 commits is pretty useless; it could take weeks to determine which branch head is which. The refs database is an important part of the usability of a Git 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