Hi Denton & Dscho

On 31/10/2019 18:19, Denton Liu wrote:

Hi Dscho,

On Thu, Oct 31, 2019 at 11:22:16AM +0100, Johannes Schindelin wrote:

quoted

Hi Peff,

On Thu, 31 Oct 2019, Jeff King wrote:

quoted

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

quoted

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

Personally I'd prefer a config setting that meant --edit-description 
stored the description in a ref instead of the current config key (or 
perhaps as well as so format-patch can just get the latest branch 
description from the config key)

	# 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 [off-list ref]
	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?

I'd love to see a consensus around putting remote versions of refs/foo 
under refs/remote/<remote-name>/foo. To share notes I add a refspec that 
fetches to refs/remote/<remote-name>/notes. It is a pain that 'git pull' 
wont merge them for me though.

* 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?

Teaching 'git pull' to (configurably) merge things under 
refs/remote/<remote-name>/foo to refs/foo would be a useful addition, 
then it could merge notes and any other refs people are sharing.

Best Wishes

Phillip

Thanks,

Denton

quoted

I now like that idea a lot better than my original notes idea.

Ciao,
Dscho