{"thread":{"id":"13219","subject":"Re: branch description","startedAt":"2008-04-22T17:57:36Z","lastAt":"2008-04-22T18:59:16Z","messageCount":3,"participants":["Michael Dressel","Johan Herland","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"75000","messageId":"alpine.DEB.1.10.0804221945060.3452@pollux.milkiway.cos","threadId":"13219","inReplyTo":null,"subject":"Re: branch description","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2008-04-22T17:57:36Z","receivedAt":"2008-04-22T17:57:36Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"\nOn Friday 18 April 2008, Jakub Narebski wrote:\n> Let me sum up here proposals where to put branch description:\n\nwhat's the opinion of having a new branch object? Actually the tag object \nprobably already does the job? This would spoil the elegant light weight \ncurrent branch references. But tags are not that heavy.\n\nIn this approach the tags would not reference commits but tags. And tags \nhave annotation. The difference to the normal tags would be that these \ntags are referenced from refs/heads/ instead of refs/tags.\n\nI have no clue how involved this change would become and if the benefit \nwould justify the effort. I guess using proper objects for branches \nwould only be justified if additional advantages could be achieved.\n\nCheers,\n \tMichael\n"},{"id":"75003","messageId":"200804222046.05175.johan@herland.net","threadId":"13219","inReplyTo":"alpine.DEB.1.10.0804221945060.3452@pollux.milkiway.cos","subject":"Re: branch description","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-04-22T18:46:02Z","receivedAt":"2008-04-22T18:46:02Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tuesday 22 April 2008, Michael Dressel wrote:\n> On Friday 18 April 2008, Jakub Narebski wrote:\n> > Let me sum up here proposals where to put branch description:\n>\n> what's the opinion of having a new branch object? Actually the tag\n> object probably already does the job? This would spoil the elegant\n> light weight current branch references. But tags are not that heavy.\n>\n> In this approach the tags would not reference commits but tags. And\n> tags have annotation. The difference to the normal tags would be that\n> these tags are referenced from refs/heads/ instead of\n> refs/tags.\n>\n> I have no clue how involved this change would become and if the\n> benefit would justify the effort. I guess using proper objects for\n> branches would only be justified if additional advantages could be\n> achieved.\n>\n> Cheers,\n> \tMichael\n\nNice idea, but it won't work, simply because branches are moving\ntargets, whereas tags are not.\n\nTo illustrate, here's how things are structured between the refs\n(tags/branches) and the object DB:\n\n\nrefs/tags/lighweight -------------------------> [commit object]\n\nrefs/tags/annotated -----> [tag object] -----> [commit object]\n\nrefs/heads/branchname -------------------------> [commit object]\n\n\nThe annotated tag ref holds the SHA1 of the tag object which in turn\nholds the SHA1 of the commit object, while the two other ref types\npoint directly at a commit object. The tag object works on the\nassumption that the commit object pointed to by the tag never changes.\nThat's after all the whole point of a tag.\n\nA branch - on the other hand - is _supposed_ to change. It changes by\nadding a new commit on top of the current commit, and updating the\nbranch ref to point to the new commit. If we kept the branch description\nin a tag object, and stuck this between the branch ref and the commit\nobject, we would suddenly have to rewrite the tag object every time we\nadded another commit on the branch. This would make commits much more\nexpensive, not to mention that for every commit you would drop the\ntag object pointing to the previous commit, in effect generating one\ngarbage object per commit. This is clearly not what we want.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"75005","messageId":"m33apdra0w.fsf@localhost.localdomain","threadId":"13219","inReplyTo":"alpine.DEB.1.10.0804221945060.3452@pollux.milkiway.cos","subject":"Re: branch description","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-22T18:59:16Z","receivedAt":"2008-04-22T18:59:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael Dressel writes:\n\n> On Friday 18 April 2008, Jakub Narebski wrote:\n\n> > Let me sum up here proposals where to put branch description:\n> >\n> > [...]\n> \n> what's the opinion of having a new branch object? Actually the tag\n> object probably already does the job? This would spoil the elegant\n> light weight current branch references. But tags are not that heavy.\n> \n> In this approach the tags would not reference commits but tags. And\n> tags have annotation. The difference to the normal tags would be that\n> these tags are referenced from refs/heads/ instead of\n> refs/tags.\n> \n> I have no clue how involved this change would become and if the\n> benefit would justify the effort. I guess using proper objects for\n> branches would only be justified if additional advantages could be\n> achieved.\n\nThis won't work. With described (annotated) branches, there are two\npieces of data associated with a branch:\n * commit it points to (branch head)\n * description of a branch\n\nBranch head changes frequently (commit, reset, bisect, rebase), while\ndescription should change rarely. Those two pieces of data are\nindependent. Tag object would unnecessary join/fuse those two\ntogether.\n\n\nAlso, for exach commit on a branch, or for each moving of branch ref\n(reset, amend, bisect), you would have to create tag object, which\nwould accumulate only to be garbage collected some time in the\nfuture...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}