From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH] fmt-merge-msg: use branch.$name.description
Date: Fri, 07 Oct 2011 22:40:28 +0200 [thread overview]
Message-ID: <4E8F63BC.1060401@drmicha.warpmail.net> (raw)
In-Reply-To: <7v1uuovahm.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 07.10.2011 21:59:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> I am surprised that you seem to have missed what I meant by "branch
>> names are local"....
>> This matters, a lot, because there is no easy way to partition a
>> namespace of names descriptive for humans without a central authority
>> to negotiate conflicts.
>
> I think we are in total agreement. The branch names are local, but the
> users may want to annotate to describe _the history_ they intend to build
> on it.
>
> Various ways to convey the description when the end product (i.e. the
> history built on it) is shiped were outlined in the series, so that the
> shipper can help the receiver understand the history. The information in
> the annotation (i.e. the _value_ of branch.$name.description) is something
> the shipper wants to share with the receiver, but the mapping between the
> local name of the branch the shipper used to build that history (i.e. the
> key "$name" in branch.$name.description) is immaterial in the end result.
It just seems we judge the "local" aspect completely differently. The
point that I don't get is: How to share a branch without sharing a
branch name? You cannot. Of course you may "change the name" during the
push, or during a fetch, and at that point you know both and can map the
description.
Note that I'm not tied to the notes implementation. But versioned branch
descriptions would be nice for several purposes, for example series
cover letters, or descriptions on long lived feature branches. And I
don't see how else to have versioned descriptions.
Also, for transporting descriptions via config, you have to have an
updated git on the server side, whereas anything object/ref based would
work now, right?
Michael
next prev parent reply other threads:[~2011-10-07 20:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 6:57 [PATCH] fmt-merge-msg: use branch.$name.description Junio C Hamano
2011-10-07 8:51 ` Michael J Gruber
2011-10-07 9:16 ` Jonathan Nieder
2011-10-07 9:45 ` Michael J Gruber
2011-10-07 10:06 ` Jonathan Nieder
2011-10-07 12:14 ` Michael J Gruber
2011-10-07 19:50 ` Jonathan Nieder
2011-10-07 19:59 ` Junio C Hamano
2011-10-07 20:40 ` Michael J Gruber [this message]
2011-10-07 20:12 ` Jonathan Nieder
2011-10-07 20:59 ` Junio C Hamano
2011-10-08 0:01 ` 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=4E8F63BC.1060401@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.