All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Denton Liu <liu.denton@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git branch --edit-description a custom file
Date: Thu, 31 Oct 2019 02:18:32 -0400	[thread overview]
Message-ID: <20191031061832.GA20830@sigill.intra.peff.net> (raw)
In-Reply-To: <20191030224328.GB44961@generichostname>

On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:

> On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
> Dscho brought up in the GGG thread[1] that perhaps we want to treat
> branch descriptions like notes and have them all under something like
> `refs/notes/branches`. This would certainly solve my problem of
> having versioned descriptions and it would probably do it in a much more
> general way than having a versioned included config.
> 
> Anyone see any potential problems with this approach?

I don't think it would be `refs/notes/`, as that is assumed to contain
mappings of object ids (and if I understand correctly, this would be a
mapping of branch names to data.

You could just have "refs/meta/descriptions/foo" pointing to a blob
which contains the description of "refs/heads/foo". That makes it easy
to edit descriptions, even if you don't like using "git branch
--edit-description".

You could also have "refs/meta/descriptions" to point to a _single_ blob
with all of the descriptions. It could even be in the existing config
format. And then you could include it with "[include] blob = ...". That
doesn't exist yet, but it would be easy to add (it was something I had
always considered when writing the config-include code, but there was
never really a good use; and you do have to be careful about pointing to
untrusted blobs). That's a convoluted way to get where you want, but I
wonder if integrating to the existing config system would have any
benefits. I haven't really thought it through.

(Of course that's also only one step away from having a versioned config
file in your .git directory, but it might possibly be a bit easier to
manage, since it would always be committed).

That's mostly off-the-top-of-my-head rambling, so please disregard
anything that seems totally off-base. :)

-Peff

  reply	other threads:[~2019-10-31  6:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30 18:39 git branch --edit-description a custom file Denton Liu
2019-10-30 20:28 ` Jeff King
2019-10-30 22:43   ` Denton Liu
2019-10-31  6:18     ` Jeff King [this message]
2019-10-31 10:22       ` Johannes Schindelin
2019-10-31 11:00         ` Phillip Wood
2019-10-31 11:30           ` Johannes Schindelin
2019-10-31 13:45             ` Philip Oakley
2019-10-31 15:42               ` Jeff King
2019-11-03 17:56                 ` Philip Oakley
2019-11-04 19:50                   ` Jeff King
2019-11-04  3:21                 ` Junio C Hamano
2019-10-31 18:19         ` Denton Liu
2019-10-31 19:53           ` Phillip Wood
2019-10-31 20:07             ` Jeff King
2019-11-01 12:29               ` Phillip Wood
2019-11-01 16:49                 ` Jeff King
2019-11-01 20:35                   ` Phillip Wood
2019-11-02  4:53               ` Junio C Hamano
2019-10-31 17:35       ` Denton Liu
2019-10-31 18:06         ` Jeff King

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=20191031061832.GA20830@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=liu.denton@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 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.