git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Michael Dressel <MichaelTiloDressel@t-online.de>
Cc: git@vger.kernel.org
Subject: Re: branch description
Date: Tue, 22 Apr 2008 20:46:02 +0200	[thread overview]
Message-ID: <200804222046.05175.johan@herland.net> (raw)
In-Reply-To: <alpine.DEB.1.10.0804221945060.3452@pollux.milkiway.cos>

On Tuesday 22 April 2008, Michael Dressel wrote:
> On Friday 18 April 2008, Jakub Narebski wrote:
> > Let me sum up here proposals where to put branch description:
>
> what's the opinion of having a new branch object? Actually the tag
> object probably already does the job? This would spoil the elegant
> light weight current branch references. But tags are not that heavy.
>
> In this approach the tags would not reference commits but tags. And
> tags have annotation. The difference to the normal tags would be that
> these tags are referenced from refs/heads/<branch> instead of
> refs/tags.
>
> I have no clue how involved this change would become and if the
> benefit would justify the effort. I guess using proper objects for
> branches would only be justified if additional advantages could be
> achieved.
>
> Cheers,
>  	Michael

Nice idea, but it won't work, simply because branches are moving
targets, whereas tags are not.

To illustrate, here's how things are structured between the refs
(tags/branches) and the object DB:


refs/tags/lighweight  -------------------------> [commit object]

refs/tags/annotated   -----> [tag object] -----> [commit object]

refs/heads/branchname -------------------------> [commit object]


The annotated tag ref holds the SHA1 of the tag object which in turn
holds the SHA1 of the commit object, while the two other ref types
point directly at a commit object. The tag object works on the
assumption that the commit object pointed to by the tag never changes.
That's after all the whole point of a tag.

A branch - on the other hand - is _supposed_ to change. It changes by
adding a new commit on top of the current commit, and updating the
branch ref to point to the new commit. If we kept the branch description
in a tag object, and stuck this between the branch ref and the commit
object, we would suddenly have to rewrite the tag object every time we
added another commit on the branch. This would make commits much more
expensive, not to mention that for every commit you would drop the
tag object pointing to the previous commit, in effect generating one
garbage object per commit. This is clearly not what we want.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

  reply	other threads:[~2008-04-22 18:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-22 17:57 branch description Michael Dressel
2008-04-22 18:46 ` Johan Herland [this message]
2008-04-22 18:59 ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2008-04-15 16:51 Stephen Sinclair
2008-04-15 17:31 ` Russ Dill
2008-04-15 18:01   ` Brian Gernhardt
2008-04-15 19:12     ` Junio C Hamano
2008-04-15 19:19       ` Jeff King
2008-04-15 22:37         ` Jeff King
2008-04-15 22:56           ` Junio C Hamano
2008-04-15 20:53       ` Stephen Sinclair
2008-04-15 21:04         ` Brian Gernhardt
2008-04-16  1:33       ` Jakub Narebski
2008-04-16  2:55         ` Jeff King
2008-04-16  3:28         ` Stephen Sinclair
2008-04-16  5:55           ` Mike Hommey
2008-04-16  3:46         ` Matt Graham
2008-04-16  8:29           ` Johan Herland
2008-04-18 21:58             ` Jakub Narebski
2008-04-19  9:18               ` Johan Herland
2008-04-19 17:43                 ` Junio C Hamano
2008-04-19 18:09                   ` Johan Herland
2008-04-19 21:05                 ` Jakub Narebski
2008-04-16  5:27         ` Junio C Hamano
2008-04-16 19:56           ` Jakub Narebski
2008-04-15 18:36   ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200804222046.05175.johan@herland.net \
    --to=johan@herland.net \
    --cc=MichaelTiloDressel@t-online.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).