From: Denton Liu <liu.denton@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>
Subject: Re: git branch --edit-description a custom file
Date: Thu, 31 Oct 2019 11:19:20 -0700 [thread overview]
Message-ID: <20191031181920.GB70819@generichostname> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1910311119080.46@tvgsbejvaqbjf.bet>
Hi Dscho,
On Thu, Oct 31, 2019 at 11:22:16AM +0100, Johannes Schindelin wrote:
> Hi Peff,
>
> On Thu, 31 Oct 2019, Jeff King wrote:
>
> > 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".
>
> The only problem with this is that it's not really versioned, as it
> would be hard to go back to previous versions and/or share the history
> via pushing to a remote repository.
>
> But I guess that a very simple pseudo branch would do it, where
> `refs/meta/<branch-name>` would point to a commit that has a tree
> with a single file in it: `description.txt`.
So how would you envision the workflow for this? Would it be something
like,
$ git checkout feature-1
$ git branch --edit-description=ref # instead of =config
# editor opens up, :wq
# is it find to have an autogenerated commit message?
$ git show refs/meta/feature-1
commit 80dfea1dc4492aaabc80d23fbaffe86da55ee098 (refs/meta/feature-1)
Author: Denton Liu <liu.denton@gmail.com>
Date: 42 seconds ago
Update ref description
diff --git a/description.txt b/description.txt
new file mode 100644
index 0000000..ed03a4b
--- /dev/null
+++ b/description.txt
@@ -0,0 +1 @@
+this is a description
I have some open questions about this, though:
* Since we're planning on sharing these descriptions with the outside
world, how would the ref layout look like? If we're not using the
refs/remotes namespace will it make fetching and merging notes harder?
I know that collaborating with notes is a pain so how do we avoid
making the same mistake?
* On the above point, what if local descriptions are at
refs/meta/heads/feature-1 while remote descriptions are at
refs/meta/remotes/*/feature-1?
* What would a merge workflow look like? Would we have wrapper commands
for it or do users just have to checkout the description branch
themselves?
Thanks,
Denton
>
> I now like that idea a lot better than my original notes idea.
>
> Ciao,
> Dscho
next prev parent reply other threads:[~2019-10-31 18:19 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
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 [this message]
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=20191031181920.GB70819@generichostname \
--to=liu.denton@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--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.