{"thread":{"id":"5548","subject":"Marking abandoned branches","startedAt":"2006-09-13T15:17:59Z","lastAt":"2006-09-14T03:37:35Z","messageCount":29,"participants":["Jon Smirl","Petr Baudis","Johannes Schindelin","Jakub Narebski","Shawn Pearce","A Large Angry SCM","Nicolas Pitre","Junio C Hamano","Martin Langhoff","Sam Vilain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26797","messageId":"9e4733910609130817r39bbf8a8x2e05461816d9d2a1@mail.gmail.com","threadId":"5548","inReplyTo":null,"subject":"Marking abandoned branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-13T15:17:59Z","receivedAt":"2006-09-13T15:17:59Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"Since branch refs are being worked on it would make sense to add an\nobject that marks a branch as being abandoned. The visualization tools\nwould use this to suppress viewing of these branches in their default\ndisplay.\n\nFor example Mozilla has 100s of branches that were abandoned five or\nmore years ago. No point in having them impact a current gitk display.\n\nYou would add an abandoned branch marker after the last commit on the\nbranch and adjust the branch ref to point at it. If you want to open\nthe branch again point the branch ref back to the last commit and let\ngit prune remove the marker.\n\nAbandoned branches are common in CVS since it is not distributed.\nPeople start working on something in the main repo and then decide it\nwas a bad idea. In the git world these branches usually don't end up\nin the main repo.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"26798","messageId":"20060913152451.GH23891@pasky.or.cz","threadId":"5548","inReplyTo":"9e4733910609130817r39bbf8a8x2e05461816d9d2a1@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-13T15:24:51Z","receivedAt":"2006-09-13T15:24:51Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter\nwhere Jon Smirl said that...\n> Abandoned branches are common in CVS since it is not distributed.\n> People start working on something in the main repo and then decide it\n> was a bad idea. In the git world these branches usually don't end up\n> in the main repo.\n\nCan't you just toss the branch away in that case? :-)\n\nYou could also stash the ref to refs/heads-abandoned/ instead of\nrefs/heads/ if you want to keep the junk around for some reason. Of\ncourse you don't get the nice marker with explanation of why is this\nabandoned and who decided that, but you can just use an empty commit for\nthe same purpose.\n\nObject classes are precious things and we shouldn't get carried away.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"26799","messageId":"Pine.LNX.4.63.0609131729500.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5548","inReplyTo":"20060913152451.GH23891@pasky.or.cz","subject":"Re: Marking abandoned branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-13T15:31:41Z","receivedAt":"2006-09-13T15:31:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Sep 2006, Petr Baudis wrote:\n\n> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter\n> where Jon Smirl said that...\n> > Abandoned branches are common in CVS since it is not distributed.\n> > People start working on something in the main repo and then decide it\n> > was a bad idea. In the git world these branches usually don't end up\n> > in the main repo.\n> \n> Can't you just toss the branch away in that case? :-)\n> \n> You could also stash the ref to refs/heads-abandoned/ instead of\n> refs/heads/ if you want to keep the junk around for some reason. Of\n> course you don't get the nice marker with explanation of why is this\n> abandoned and who decided that, but you can just use an empty commit for\n> the same purpose.\n\n... or a tag (remember, you can stash a tag into refs/abandoned/, instead \nof a commit) with the further benefit that you really cannot commit on top \nof that.\n\n> Object classes are precious things and we shouldn't get carried away.\n\nExactly.\n\nCiao,\nDscho\n"},{"id":"26800","messageId":"ee9925$6cp$1@sea.gmane.org","threadId":"5548","inReplyTo":"Pine.LNX.4.63.0609131729500.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T15:45:26Z","receivedAt":"2006-09-13T15:45:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 13 Sep 2006, Petr Baudis wrote:\n> \n>> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter\n>> where Jon Smirl said that...\n>> > Abandoned branches are common in CVS since it is not distributed.\n>> > People start working on something in the main repo and then decide it\n>> > was a bad idea. In the git world these branches usually don't end up\n>> > in the main repo.\n>> \n>> Can't you just toss the branch away in that case? :-)\n>> \n>> You could also stash the ref to refs/heads-abandoned/ instead of\n>> refs/heads/ if you want to keep the junk around for some reason. Of\n>> course you don't get the nice marker with explanation of why is this\n>> abandoned and who decided that, but you can just use an empty commit for\n>> the same purpose.\n> \n> ... or a tag (remember, you can stash a tag into refs/abandoned/, instead \n> of a commit) with the further benefit that you really cannot commit on top \n> of that.\n\nOr refs/Attic/ ;-)\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26801","messageId":"9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com","threadId":"5548","inReplyTo":"20060913152451.GH23891@pasky.or.cz","subject":"Re: Marking abandoned branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-13T15:59:53Z","receivedAt":"2006-09-13T15:59:53Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 9/13/06, Petr Baudis wrote:\n> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter\n> where Jon Smirl said that...\n> > Abandoned branches are common in CVS since it is not distributed.\n> > People start working on something in the main repo and then decide it\n> > was a bad idea. In the git world these branches usually don't end up\n> > in the main repo.\n>\n> Can't you just toss the branch away in that case? :-)\n\nIt is a historical import. Everything that was in the initial repo\nneeds to be preserved otherwise they aren't going to get rid of the\nold CVS repo.\n\n> You could also stash the ref to refs/heads-abandoned/ instead of\n> refs/heads/ if you want to keep the junk around for some reason. Of\n> course you don't get the nice marker with explanation of why is this\n> abandoned and who decided that, but you can just use an empty commit for\n> the same purpose.\n>\n> Object classes are precious things and we shouldn't get carried away.\n\nIf this is done with an object there should probably be some way to\nencode it into the existing commit object.\n\nMoving the refs into refs/abandoned would work too. We would need new\ngit commands to do this and flags on the visualization tools to\ninclude the abandoned branches. On the other hand doing this is\nrecording state about the repository in the refs directory instead of\nwriting this state into the repo itself.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"26802","messageId":"Pine.LNX.4.63.0609131804050.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5548","inReplyTo":"9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-13T16:05:19Z","receivedAt":"2006-09-13T16:05:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Sep 2006, Jon Smirl wrote:\n\n> Moving the refs into refs/abandoned would work too. We would need new\n> git commands to do this and flags on the visualization tools to\n> include the abandoned branches. On the other hand doing this is\n> recording state about the repository in the refs directory instead of\n> writing this state into the repo itself.\n\nWell, the refs directory is _part_ of the repository. Think about it, if \nyou do not know which branches are in the object database, you lack a lot \nof information.\n\nBTW the moving of a branch to a tag in refs/abandoned/ is trivial.\n\nCiao,\nDscho\n"},{"id":"26803","messageId":"20060913160939.GA29933@spearce.org","threadId":"5548","inReplyTo":"9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-13T16:09:39Z","receivedAt":"2006-09-13T16:09:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jon Smirl wrote:\n> On 9/13/06, Petr Baudis wrote:\n> >You could also stash the ref to refs/heads-abandoned/ instead of\n> >refs/heads/ if you want to keep the junk around for some reason. Of\n> >course you don't get the nice marker with explanation of why is this\n> >abandoned and who decided that, but you can just use an empty commit for\n> >the same purpose.\n> >\n> >Object classes are precious things and we shouldn't get carried away.\n> \n> If this is done with an object there should probably be some way to\n> encode it into the existing commit object.\n\nI agree completely with what Petr is saying. Allocating a new\nclass of object in Git is a *major* deal. We don't really have\nany IDs left. Tags would quite easily carry information stating\nthat the branch is considered abandoned, who abandoned it, and\nwhen the did so. The tags can also easily be saved off into a\nrefs/abandoned directory.\n \n> Moving the refs into refs/abandoned would work too. We would need new\n> git commands to do this and flags on the visualization tools to\n> include the abandoned branches.\n\nI fail to see why. If a branch is abandoned then its not merged into\nany of the active branches. If this is the case then gitk doesn't\ndisplay it when viewing an active branch. So what's the problem?\n\n> On the other hand doing this is\n> recording state about the repository in the refs directory instead of\n> writing this state into the repo itself.\n\nSame difference. The repository is a union of the objects stored\nin the objects directory and the pack files and the symbolic\nref names holding the heads of the commit chains. We're already\ntalking about some other ways to handle larger sets of refs, and\nLinus has contributed some cleanup code heading in that direction.\nThe refs *are* the repository.\n\n-- \nShawn.\n"},{"id":"26804","messageId":"ee9akc$d62$1@sea.gmane.org","threadId":"5548","inReplyTo":"9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T16:12:13Z","receivedAt":"2006-09-13T16:12:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> On 9/13/06, Petr Baudis wrote:\n>> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter\n>> where Jon Smirl said that...\n>> > Abandoned branches are common in CVS since it is not distributed.\n>> > People start working on something in the main repo and then decide it\n>> > was a bad idea. In the git world these branches usually don't end up\n>> > in the main repo.\n>>\n>> Can't you just toss the branch away in that case? :-)\n> \n> It is a historical import. Everything that was in the initial repo\n> needs to be preserved otherwise they aren't going to get rid of the\n> old CVS repo.\n\nYou can leave this in historical repository, and strip current repository\nfrom abandoned work, by the way.\n\n>> You could also stash the ref to refs/heads-abandoned/ instead of\n>> refs/heads/ if you want to keep the junk around for some reason. Of\n>> course you don't get the nice marker with explanation of why is this\n>> abandoned and who decided that, but you can just use an empty commit for\n>> the same purpose.\n> \n> If this is done with an object there should probably be some way to\n> encode it into the existing commit object.\n\nAs it was said somewhere in this thread, you can use tags (tag objects) for\nthat, i.e. tag each of the abandoned branches, explaining why branch wa\nabandoned for example, remove head refs, and move tag refs to\nrefs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in refs-abandoned/\n(the last has the advantage to not be included by default in any command,\neven when --all is given)\n \n> Moving the refs into refs/abandoned would work too. We would need new\n> git commands to do this and flags on the visualization tools to\n> include the abandoned branches. On the other hand doing this is\n> recording state about the repository in the refs directory instead of\n> writing this state into the repo itself.\n\nThere is no need for new flag. If you give --all flag to the gitk command\nline or the list of commits option field, all the refs in $GIT_DIR/refs/\nwould be included. If you will use refs-abandoned/ instead, it would be\nenough I guess to give refs-abandoned/ or refs-abandoned/*. Of course you\nwould need some change to visualisers to mar abandoned branches in\ndifferent way.\n\ngitweb as of now uses only refs/heads and refs/tags; markers are taken from\n$GIT_DIR/info/refs or \"git-ls-remotes .\" (i.e. all refs/)\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26805","messageId":"45083490.9020203@gmail.com","threadId":"5548","inReplyTo":"ee9akc$d62$1@sea.gmane.org","subject":"Re: Marking abandoned branches","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-09-13T16:40:48Z","receivedAt":"2006-09-13T16:40:48Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Jakub Narebski wrote:\n...\n> As it was said somewhere in this thread, you can use tags (tag objects) for\n> that, i.e. tag each of the abandoned branches, explaining why branch wa\n> abandoned for example, remove head refs, and move tag refs to\n> refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in refs-abandoned/\n> (the last has the advantage to not be included by default in any command,\n> even when --all is given)\n\nUsing $GIT_DIR/refs-abandoned/ means changing a number of core parts;\nthink fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and\nteach the various visualizers to ignore that prefix by default. Maybe\neven make the name a config item. *ducks*\n"},{"id":"26806","messageId":"20060913164937.GC29933@spearce.org","threadId":"5548","inReplyTo":"45083490.9020203@gmail.com","subject":"Re: Marking abandoned branches","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-13T16:49:37Z","receivedAt":"2006-09-13T16:49:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"A Large Angry SCM wrote:\n> Jakub Narebski wrote:\n> ...\n> > As it was said somewhere in this thread, you can use tags (tag objects) for\n> > that, i.e. tag each of the abandoned branches, explaining why branch wa\n> > abandoned for example, remove head refs, and move tag refs to\n> > refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in refs-abandoned/\n> > (the last has the advantage to not be included by default in any command,\n> > even when --all is given)\n> \n> Using $GIT_DIR/refs-abandoned/ means changing a number of core parts;\n> think fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and\n> teach the various visualizers to ignore that prefix by default. Maybe\n> even make the name a config item. *ducks*\n\n\nHow about using a regex or a shell wildcard in config such as:\n\n\t[core]\n\t\thideRefs = refs/abandoned/\n\t\thideRefs = refs/some-garbage-i-have/\n\n?\n\n-- \nShawn.\n"},{"id":"26807","messageId":"ee9d5j$lhd$1@sea.gmane.org","threadId":"5548","inReplyTo":"45083490.9020203@gmail.com","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T16:55:33Z","receivedAt":"2006-09-13T16:55:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"A Large Angry SCM wrote:\n\n> Jakub Narebski wrote:\n> ...\n>> As it was said somewhere in this thread, you can use tags (tag objects)\nfor\n>> that, i.e. tag each of the abandoned branches, explaining why branch wa\n>> abandoned for example, remove head refs, and move tag refs to\n>> refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in\nrefs-abandoned/\n>> (the last has the advantage to not be included by default in any command,\n>> even when --all is given)\n> \n> Using $GIT_DIR/refs-abandoned/ means changing a number of core parts;\n> think fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and\n> teach the various visualizers to ignore that prefix by default. Maybe\n> even make the name a config item. *ducks*\n\nWell, visualisers IIRC shows only requested branches. The only place where\nabandoned branches would show even when we probably don't want would be\n--all... one can try to use --all --not refs/abandoned/*\n\nI wonder if using the \"hidden\" directory for abandoned branches \n(i.e. refs/.abandoned) would work...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26808","messageId":"9e4733910609131022y19327efy541ac451bdf4b009@mail.gmail.com","threadId":"5548","inReplyTo":"Pine.LNX.4.63.0609131804050.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Marking abandoned branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-13T17:22:09Z","receivedAt":"2006-09-13T17:22:09Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 9/13/06, Johannes Schindelin wrote:\n> Hi,\n>\n> On Wed, 13 Sep 2006, Jon Smirl wrote:\n>\n> > Moving the refs into refs/abandoned would work too. We would need new\n> > git commands to do this and flags on the visualization tools to\n> > include the abandoned branches. On the other hand doing this is\n> > recording state about the repository in the refs directory instead of\n> > writing this state into the repo itself.\n>\n> Well, the refs directory is _part_ of the repository. Think about it, if\n> you do not know which branches are in the object database, you lack a lot\n> of information.\n\nIf you delete all of your heads you can recover them by following all\nof the chains in the repo to find them. Doing this would recover the\nabandoned branches too but it would mix them up with the active heads.\nThis is not a big deal but it is info that is getting stored outside\nof the object db.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"26809","messageId":"9e4733910609131024v28ccce5cx7dd427a55002bc4f@mail.gmail.com","threadId":"5548","inReplyTo":"ee9d5j$lhd$1@sea.gmane.org","subject":"Re: Marking abandoned branches","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2006-09-13T17:24:41Z","receivedAt":"2006-09-13T17:24:41Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 9/13/06, Jakub Narebski wrote:\n> A Large Angry SCM wrote:\n>\n> > Jakub Narebski wrote:\n> > ...\n> >> As it was said somewhere in this thread, you can use tags (tag objects)\n> for\n> >> that, i.e. tag each of the abandoned branches, explaining why branch wa\n> >> abandoned for example, remove head refs, and move tag refs to\n> >> refs/abandoned or refs/tags-abandoned/ or refs/Attic/ or in\n> refs-abandoned/\n> >> (the last has the advantage to not be included by default in any command,\n> >> even when --all is given)\n> >\n> > Using $GIT_DIR/refs-abandoned/ means changing a number of core parts;\n> > think fsck and friends. Better to decide on a name in $GIT_DIR/refs/ and\n> > teach the various visualizers to ignore that prefix by default. Maybe\n> > even make the name a config item. *ducks*\n>\n> Well, visualisers IIRC shows only requested branches. The only place where\n> abandoned branches would show even when we probably don't want would be\n> --all... one can try to use --all --not refs/abandoned/*\n\nIn order to make the tools easier to use I would turn this around and\nmake --all show all active branches and the use something like\n--include /refs/abandoned to include the abandoned ones.\n\n>\n> I wonder if using the \"hidden\" directory for abandoned branches\n> (i.e. refs/.abandoned) would work...\n> --\n> Jakub Narebski\n> Warsaw, Poland\n> ShadeHawk on #git\n>\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"26810","messageId":"20060913173212.GD29933@spearce.org","threadId":"5548","inReplyTo":"9e4733910609131022y19327efy541ac451bdf4b009@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-13T17:32:12Z","receivedAt":"2006-09-13T17:32:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jon Smirl wrote:\n> On 9/13/06, Johannes Schindelin wrote:\n> >Hi,\n> >\n> >On Wed, 13 Sep 2006, Jon Smirl wrote:\n> >\n> >> Moving the refs into refs/abandoned would work too. We would need new\n> >> git commands to do this and flags on the visualization tools to\n> >> include the abandoned branches. On the other hand doing this is\n> >> recording state about the repository in the refs directory instead of\n> >> writing this state into the repo itself.\n> >\n> >Well, the refs directory is _part_ of the repository. Think about it, if\n> >you do not know which branches are in the object database, you lack a lot\n> >of information.\n> \n> If you delete all of your heads you can recover them by following all\n> of the chains in the repo to find them. Doing this would recover the\n> abandoned branches too but it would mix them up with the active heads.\n> This is not a big deal but it is info that is getting stored outside\n> of the object db.\n\nNo. Being able to get a ref back like that is like saying that I\ncan get files back in ext2 by deleting them then running fsck and\nrestoring the lost inodes to '/lost+found'. Sure the data is there\nbut there's no way to tell which file is which!\n\nThe name of a ref, like the name of a file, is pretty important\nwhen it comes to describing it. Just having the SHA1 ID of 100\ncommits is pretty useless; it could take weeks to determine which\nbranch head is which. The refs database is an important part of\nthe usability of a Git repository.\n\n-- \nShawn.\n"},{"id":"26811","messageId":"ee9g3g$vmg$1@sea.gmane.org","threadId":"5548","inReplyTo":"9e4733910609131024v28ccce5cx7dd427a55002bc4f@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T17:45:38Z","receivedAt":"2006-09-13T17:45:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Smirl wrote:\n\n> On 9/13/06, Jakub Narebski wrote:\n\n>> Well, visualisers IIRC shows only requested branches. The only place where\n>> abandoned branches would show even when we probably don't want would be\n>> --all... one can try to use --all --not refs/abandoned/*\n> \n> In order to make the tools easier to use I would turn this around and\n> make --all show all active branches and the use something like\n> --include refs/abandoned to include the abandoned ones.\n\nNot that easy. Usually one have only refs/heads and refs/tags... unless\none use --use-separate-remotes, and then one has refs/remotes/...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26812","messageId":"Pine.LNX.4.64.0609131344420.2627@xanadu.home","threadId":"5548","inReplyTo":"9e4733910609131022y19327efy541ac451bdf4b009@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-09-13T17:46:41Z","receivedAt":"2006-09-13T17:46:41Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 13 Sep 2006, Jon Smirl wrote:\n\n> If you delete all of your heads you can recover them by following all\n> of the chains in the repo to find them. Doing this would recover the\n> abandoned branches too but it would mix them up with the active heads.\n\nWell, just don't do that then. ;-)\n\n> This is not a big deal but it is info that is getting stored outside\n> of the object db.\n\nSure, but the object db is useless without them anyway.\n\n\nNicolas\n"},{"id":"26813","messageId":"7vmz93a9v9.fsf@assigned-by-dhcp.cox.net","threadId":"5548","inReplyTo":"Pine.LNX.4.63.0609131729500.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Marking abandoned branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-13T18:40:10Z","receivedAt":"2006-09-13T18:40:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Dear diary, on Wed, Sep 13, 2006 at 05:17:59PM CEST, I got a letter\n>> where Jon Smirl said that...\n>> > Abandoned branches are common in CVS since it is not distributed.\n>> > People start working on something in the main repo and then decide it\n>> > was a bad idea. In the git world these branches usually don't end up\n>> > in the main repo.\n>> \n>> Can't you just toss the branch away in that case? :-)\n>> \n>> You could also stash the ref to refs/heads-abandoned/ instead of\n>> refs/heads/ if you want to keep the junk around for some reason. Of\n>> course you don't get the nice marker with explanation of why is this\n>> abandoned and who decided that, but you can just use an empty commit for\n>> the same purpose.\n>\n> ... or a tag (remember, you can stash a tag into refs/abandoned/, instead \n> of a commit) with the further benefit that you really cannot commit on top \n> of that.\n\nUsing tag has an added benefit that you now have a place to say\nwhy you dropped it. So what we would need to support this is an\nagreed-upon name under $GIT_DIR/refs/ that is omitted from\ndisplay by convention across Porcelains (the core side should\nnot ignore them because even when you are abandoning them, you\ndo not want to lose them),\n"},{"id":"26814","messageId":"ee9jv6$ga0$1@sea.gmane.org","threadId":"5548","inReplyTo":"7vmz93a9v9.fsf@assigned-by-dhcp.cox.net","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T18:51:36Z","receivedAt":"2006-09-13T18:51:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Using tag has an added benefit that you now have a place to say\n> why you dropped it. So what we would need to support this is an\n> agreed-upon name under $GIT_DIR/refs/ that is omitted from\n> display by convention across Porcelains (the core side should\n> not ignore them because even when you are abandoning them, you\n> do not want to lose them),\n\nI think that using hidden directory (dot-directory), e.g.\n$GIT_DIR/refs/.abandoned/ is a good idea... unless it conflicts somewhat\nwith the way lock files are named...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26815","messageId":"7vfyeva90e.fsf@assigned-by-dhcp.cox.net","threadId":"5548","inReplyTo":"20060913164937.GC29933@spearce.org","subject":"Re: Marking abandoned branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-13T18:58:41Z","receivedAt":"2006-09-13T18:58:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> How about using a regex or a shell wildcard in config such as:\n>\n> \t[core]\n> \t\thideRefs = refs/abandoned/\n> \t\thideRefs = refs/some-garbage-i-have/\n\nA suggestion to say \"[core] anything\" is out; this does _not_\nbelong to the core at all.\n\nDepending on how much abandoned you want to make the abondond\nrefs, you can do one of the following:\n\n - If you just do not want visualizers to clutter what you are\n usually interested in viewing by default, teach visualizers\n to ignore that refs/ hierarchy. Right now visualizers either\n use \"ls-remote .\" (e.g. gitk) or walking refs directory\n itself (e.g. gitweb) to find what refs are available. Filter\n that and you are done. If we were to do show-refs helper and\n if all the visualizers use it (we would need something like\n that when the refs/ work Linus is doing hits the mainline --\n walking refs directory to find available refs becomes\n officially unsupported when that happens), I am not opposed\n to give it --ignore=refs/abandoned option. Similarly for\n ls-remote but _NOT_ peek-remote (the former is Porcelain-ish,\n the latter is core).\n\n - If you do not want to have even clone look at them, you need\n to have two repositories: with-clutter and main. You call\n the current Mozilla full-import repository the former, make a\n copy of it and remove unwanted refs from it and repack. Call\n that main and have people work on it.\n\n People who want to look at old, failed experiments can pull\n from with-clutter repository in two ways. Either they can\n pull into their clone of 'main', or they make a separate\n clone using --reference option to cut the download time and\n to keep the cluttered part separate.\n"},{"id":"26816","messageId":"7vbqpja8wz.fsf@assigned-by-dhcp.cox.net","threadId":"5548","inReplyTo":"ee9jv6$ga0$1@sea.gmane.org","subject":"Re: Marking abandoned branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-13T19:00:44Z","receivedAt":"2006-09-13T19:00:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> Using tag has an added benefit that you now have a place to say\n>> why you dropped it. So what we would need to support this is an\n>> agreed-upon name under $GIT_DIR/refs/ that is omitted from\n>> display by convention across Porcelains (the core side should\n>> not ignore them because even when you are abandoning them, you\n>> do not want to lose them),\n>\n> I think that using hidden directory (dot-directory), e.g.\n> $GIT_DIR/refs/.abandoned/ is a good idea... unless it conflicts somewhat\n> with the way lock files are named...\n\nNames are not interesting. Visualizers ignoring them\nconsistently is.\n\nBy the way, does gitweb still walk $GIT_DIR/refs hierarchy by\nhand to find out the set of refs? When Linus is done with his\nrefs/ work, that way would become unsupported. You would need\nto read from \"ls-remote $GIT_DIR\".\n"},{"id":"26820","messageId":"ee9mff$qd1$1@sea.gmane.org","threadId":"5548","inReplyTo":"7vbqpja8wz.fsf@assigned-by-dhcp.cox.net","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T19:34:24Z","receivedAt":"2006-09-13T19:34:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> By the way, does gitweb still walk $GIT_DIR/refs hierarchy by\n> hand to find out the set of refs?  When Linus is done with his\n> refs/ work, that way would become unsupported.  You would need\n> to read from \"ls-remote $GIT_DIR\".\n\nStill, unfortunately. We could change git_get_references to use\n'git ls-remotes $GIT_DIR' (or 'git --git-dir=$GIT_DIR ls-remotes .'),\nand use git_get_references(\"refs/heads\") in git_heads (and git_summary), \nand git_get_references(\"refs/tags\") in git_tags. This _could_ be slower\nthan current implementation. git-show-refs would help a bit, but I'd rather\nhave git-show-refs in released version of git before using it in gitweb.\n\nMoreover, git currently reads appropriate ref directly in\ngit_get_hash_by_ref, not supporting even symrefs, not to mention packed\nrefs. One solution would be to add support for symrefs and packed refs\ndirectly in gitweb (Git.pm can help here), another to use git core command\n(git-rev-parse?) but that can make gitweb slower (additional fork).\n\nI hope that Linus work will be left to mature first in 'pu', then in 'next'\nbranch... wouldn't refs cache (similar to current index for files) be\nbetter idea?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26821","messageId":"46a038f90609131331p25923440w45eb49b56933f24b@mail.gmail.com","threadId":"5548","inReplyTo":"9e4733910609131022y19327efy541ac451bdf4b009@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-09-13T20:31:06Z","receivedAt":"2006-09-13T20:31:06Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Hi Jon!\n\nI guess what people are pointing at is that you can:\n\n - run your import\n - publish that as mozilla-historical.git\n - copy that to mozilla.git\n - rm all the old heads from mozilla.git\n - rm all the 'new' heads from mozilla-historical.git\n - run git-repack -a -d on both\n - make the historical repo read-only\n\nlater, it is trivial to 'archive' branch. Similarly, other projects\nrun a repo-per-developer or perhaps thematic repos. No point in\npainting 'policy' when usage practices suffice.\n\nBy the way, gitk doesn't show all the branches by default. You have to\npass --all, which stands for... all ;-)\n\nmaybe gitk should have --recent-heads. However, I use\n--since=3.months.ago all the time, and it works great.\n\ncheers,\n\n\nmartin\n"},{"id":"26824","messageId":"ee9qhf$71n$1@sea.gmane.org","threadId":"5548","inReplyTo":"46a038f90609131331p25923440w45eb49b56933f24b@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T20:43:45Z","receivedAt":"2006-09-13T20:43:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Martin Langhoff wrote:\n\n> I guess what people are pointing at is that you can:\n> \n>  - run your import\n>  - publish that as mozilla-historical.git\n>  - copy that to mozilla.git\n>  - rm all the old heads from mozilla.git\n>  - rm all the 'new' heads from mozilla-historical.git\n>  - run git-repack -a -d on both\n>  - make the historical repo read-only\n\nInstead of copying mozilla-historical.git to mozilla.git,\nit would be better to clone using --shared option\n(which sets up appropriate alternates file). Of course both\nrepositories should be on the same machine for this to work,\nand no, one wouldn't need to copy/clone them both.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26823","messageId":"20060913204349.GI23891@pasky.or.cz","threadId":"5548","inReplyTo":"ee9mff$qd1$1@sea.gmane.org","subject":"Re: Marking abandoned branches","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-13T20:43:49Z","receivedAt":"2006-09-13T20:43:49Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Sep 13, 2006 at 09:34:24PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> I hope that Linus work will be left to mature first in 'pu', then in 'next'\n> branch...\n\n Yes, me too - I still need to fix Cogito. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"26825","messageId":"7vhczb7ay9.fsf@assigned-by-dhcp.cox.net","threadId":"5548","inReplyTo":"ee9mff$qd1$1@sea.gmane.org","subject":"Re: Marking abandoned branches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-13T20:45:02Z","receivedAt":"2006-09-13T20:45:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Moreover, git currently reads appropriate ref directly in\n> git_get_hash_by_ref, not supporting even symrefs, not to mention packed\n> refs. One solution would be to add support for symrefs and packed refs\n> directly in gitweb (Git.pm can help here), another to use git core command\n> (git-rev-parse?) but that can make gitweb slower (additional fork).\n\nThe only use of that function is in git_get_refs_list to read\nrefs by hand, one-by-one. This calling function needs to be\nupdated to use the core more effectively to adjust to Linus's\nrefs/ anyway, so I think git_get_hash_by_ref is too low level\nimplementation detail to worry about. What we want is a core\nsupport that git_get_refs_list can use to get the list of refs\nand information associated with them efficiently.\n\nNow git_get_refs_list is called from four places, three\nfunctions. git_summary does two separate calls to refs/tags and\nrefs/heads. git_tags and git_heads do one call each for their\nown hierarchy. What this suggests is that the core support we\nwill give needs a way to specify what subset of refs/* to\ninclude. peek-remote allows you to do this and it is fairly\nefficient for local case (although it could be made more\nefficient by not using the general git_connect() framework if we\nwant a faster local-only command), but it gives back only the\nobject names. git_get_refs_list wants more than that. So what\ndoes it want to know? [*1*]\n\nLooking at parse_ref [*2*]:\n\n - object name\n - type\n - for a 'tag':\n - what is tagged (type and object name)\n - the tag name\n - the tagger information (name, time, and zone)\n - comment but except PGP signature\n - if it directly [*3*] tags a 'commit':\n - its age based on the commit timestamp\n - for a 'commit':\n - the refname itself\n - the first line of the log message\n - commit timestamp\n - the age based on the commit timestamp\n - for others:\n - the refname itself\n\nThe parse_ref implementation itself uses two helpers: parse_tag\nand parse_commit, and are used to show a single tag or commit\nfrom git_tag and git_commit request.\n\nSo it appears to me that show-ref needs to have at least:\n\n (1) A way to specify what refs to show, via --tags, --heads,\n --all, and explicit refname parameters.\n\n (2) Output format specifier to give information of interest for\n each object, which includes the header fields and body of a\n tag and a commit object. For a tag object, the same for\n the object the tag refers to needs to be availble.\n\nThe strawman man-page I sent out about a month ago satisfies the\nabove except the unpeeling of tag needed in the latter part of\n(2).\n\nI'll try to code the one specified by the original strawman up\nsometime today; we can discuss enhancements after that.\n\n> I hope that Linus work will be left to mature first in 'pu', then in 'next'\n> branch...\n\nThat's the general idea. A new topic always starts out in their\nown topic branch, and when I have enough time to look at it in\nisolation and I feel confident enough that it is in testable\nshape together with what are already in 'next', it is merged\ninto 'next'. I did not have enough concentration last night so\nLinus's refs/ spent the night in 'pu'. Hopefully I'll have\nenergy to look at it enough today to decide if it can be merged\nto 'next', or other fix-ups are needed.\n\nIt may break 'gitweb' and possibly others. I offhand do not\nknow what other things (including git Porcelainish) look at\nrefs/ directly; they obviously need fixing before the refs/ work\nhits 'master', or maybe even 'next'.\n\n> ... wouldn't refs cache (similar to current index for files) be\n> better idea?\n\nThe ideal is to make a fast and easy way for Porcelains to\naccess what they want to know about the refs without knowing\ntheir implementation. We already provide ways to do so except\nthat they may not be fast nor easy. And the \"may not be fast\"\npart is what triggers 'cache would be better' reaction, but the\nright thing to do is not to work it around with a clutch, but to\ndesign what an appropriate core side support is and implement\nit.\n\n\n[*1*] Here, I am essentially designing what show-ref command\nshould look like. I was hoping that Porcelain people who are\nusers of the core to do this sort of \"requirement design\" and\npresent a proposal based on their actual needs. Unfortunately\nit never happened. Let me set an example by showing how it\nshould be done here.\n\n[*2*] This is called only once from git_get_refs, so we can get\nrid of this function when we rewrite git_get_refs.\n\n[*3*] If we rewrite this part using \"foo^{}\", gitweb would lose\nthe ability to distinguish a tag that points directly at a\ncommit and a tag that points at a tag that points at a commit.\nI do not think anybody currently appreciates it right now but\nlater we might miss it if we did so.\n\nThere unfortunately is no way to use rev^{whatever} syntax to\nsay \"peel the onion only one level\".\n"},{"id":"26827","messageId":"ee9rl3$c4o$1@sea.gmane.org","threadId":"5548","inReplyTo":"7vhczb7ay9.fsf@assigned-by-dhcp.cox.net","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T21:02:46Z","receivedAt":"2006-09-13T21:02:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>> ... wouldn't refs cache (similar to current index for files) be\n>> better idea?\n> \n> The ideal is to make a fast and easy way for Porcelains to\n> access what they want to know about the refs without knowing\n> their implementation.  We already provide ways to do so except\n> that they may not be fast nor easy.  And the \"may not be fast\"\n> part is what triggers 'cache would be better' reaction, but the\n> right thing to do is not to work it around with a clutch, but to\n> design what an appropriate core side support is and implement\n> it.\n\nThe 'cache would be better' is because it is obviously backward\ncompatibile (which helps the porcelains and history viewers),\navoids some trouble with deleting (and renaming) branches, can\nbe fast (when used), and we can use symlinks/symrefs with it I guess. \n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26831","messageId":"ee9s1r$c4o$2@sea.gmane.org","threadId":"5548","inReplyTo":"7vhczb7ay9.fsf@assigned-by-dhcp.cox.net","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T21:09:33Z","receivedAt":"2006-09-13T21:09:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> I'll try to code the one specified by the original strawman up\n> sometime today; we can discuss enhancements after that.\n\nI was thinking about implementing git-show-refs, \"borrowing\" format\nparsing part from rpm (parseFormat function in rpmdb/header.c), but\nwhat I had not found in core git was the function which parses object\ninto any_object like union; there is function which parses object,\nbut it extracts and returns only the common part as an object struct. \nAnd any_object union is local to object.c\n\nI also thought that if format doesn't require object parsing (sha1id,\ntype, name and size we can get without parsing) then do not do parsing,\nbut I wonder if this is really worth it.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26836","messageId":"ee9tcl$h98$2@sea.gmane.org","threadId":"5548","inReplyTo":"7vhczb7ay9.fsf@assigned-by-dhcp.cox.net","subject":"Re: Marking abandoned branches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-13T21:32:24Z","receivedAt":"2006-09-13T21:32:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> What this suggests is that the core support we\n> will give needs a way to specify what subset of refs/* to\n> include.  peek-remote allows you to do this and it is fairly\n> efficient for local case (although it could be made more\n> efficient by not using the general git_connect() framework if we\n> want a faster local-only command), but it gives back only the\n> object names.\n\nWhat is the difference between peek-remote and ls-remotes in the\nlocal case, by the way?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26862","messageId":"4508CE7F.8080703@vilain.net","threadId":"5548","inReplyTo":"9e4733910609130859v347a7a9ew5c3ebc982bf9b07b@mail.gmail.com","subject":"Re: Marking abandoned branches","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-09-14T03:37:35Z","receivedAt":"2006-09-14T03:37:35Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jon Smirl wrote:\n> It is a historical import. Everything that was in the initial repo\n> needs to be preserved otherwise they aren't going to get rid of the\n> old CVS repo.\n> \n\nYou can tag a tree which contains the raw RCS files used for the import;\nthen they'll be available forever!\n\nSam\n"}]}