git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Johan Herland <johan@herland.net>
Cc: git@vger.kernel.org, Matt Graham <mdg149@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Brian Gernhardt <benji@silverinsanity.com>,
	Russ Dill <russ.dill@gmail.com>,
	Stephen Sinclair <radarsat1@gmail.com>
Subject: Re: branch description
Date: Sat, 19 Apr 2008 23:05:35 +0200	[thread overview]
Message-ID: <200804192305.36780.jnareb@gmail.com> (raw)
In-Reply-To: <200804191118.50105.johan@herland.net>

On Sat, 19 April 2008, Johan Herland wrote:
> On Friday 18 April 2008, Jakub Narebski wrote:

>> Let me sum up here proposals where to put branch description:
[...]
>> 3. Put them in GIT_DIR/info/refs_description, in some format.  It makes
>>    it very easy to add support for propagation for dumb transports.
>>    Native transport probably would need some extension.  Should not
>>    interfere with the rest of git code.
>> 4. Store description after sha1 in the ref file itself.  Automatic
>>    propagation for dumb transport (whether we want it or not).  Native
>>    transport as above.  Very high probabily of interfering with the rest
>>    of code, especially shell part of Git.  Need to find a place for
>>    descriptions in pack-refs.
[...]
>> 
>> I think that the best proposal is (3), not (4) as you say.
> 
> The problem with (3) vs. (4) is that in (3) we must make sure that whenever
> a branch is moved/renamed (e.g. "git clone", "git branch -m", probably more
> as well), the corresponding description is moved/renamed as well. This is
> elegantly solved in (4). But as you say, (4) may have implementation
> difficulties of its own. I guess the first acceptable implementation will
> win.

First, git already has move corresponding reflog and per-branch
configuration when renaming a branch, so it is nothing new for (3).

Second, implementation difficulties of (4) might be made stronger by
the fact that repository with branches with descriptions should be
fetchable and clonable using both native and dumb protocols by older
versions of git, and shouldn't cause troubles after fetching.  (Assume
that git is new enough to understand packed refs).  Backward
compatibility might kill this solution; but it might not.

BTW. I have added line with description to loose ref, and a few
commands I tried didn't return (cause) any errors... so...
-- 
Jakub Narebski
Poland

  parent reply	other threads:[~2008-04-19 21:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-15 16:51 branch description 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 [this message]
2008-04-16  5:27         ` Junio C Hamano
2008-04-16 19:56           ` Jakub Narebski
2008-04-15 18:36   ` Jakub Narebski
  -- strict thread matches above, loose matches on Subject: below --
2008-04-22 17:57 Michael Dressel
2008-04-22 18:46 ` Johan Herland
2008-04-22 18:59 ` 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=200804192305.36780.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=benji@silverinsanity.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=mdg149@gmail.com \
    --cc=radarsat1@gmail.com \
    --cc=russ.dill@gmail.com \
    /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).