git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Kyle J. McKay" <mackyle@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johan Herland <johan@herland.net>,
	Scott Chacon <schacon@gmail.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] notes: accept any ref for merge
Date: Thu, 4 Dec 2014 05:26:58 -0500	[thread overview]
Message-ID: <20141204102657.GA27739@peff.net> (raw)
In-Reply-To: <6b21dd7a53200ab413c67bb4667e8bc@74d39fa044aa309eaea14b9f57fe79c>

On Sat, Nov 22, 2014 at 10:04:57AM -0800, Kyle J. McKay wrote:

> > By "stealth enabler" I mean the removal of refs/notes/ restriction
> > that was originally done as a safety measure to avoid mistakes of
> > storing notes outside.  The refs/remote-notes/ future direction
> > declares that it is no longer a mistake to store notes outside
> > refs/notes/, but that does not necessarily have to mean that
> > anywhere under refs/ is fine.  It may make more sense to be explicit
> > with the code touched here to allow traditional refs/notes/ and the
> > new hierarchy only.  That way, we will still keep the "avoid
> > mistakes" safety and enable the new layout at the same time.
> 
> This is the part where I want to lobby for inclusion of this change.   
> I do not believe it is consistent with existing Git practice to  
> enforce restrictions like this (you can only display/edit/etc. notes  
> under refs/notes/*).

Yeah, this is the compelling part to me. There is literally no way to
utilize the notes codes for any ref outside of refs/notes currently. We
don't know if refs/remote-notes is the future, or refs/remotes/origin/notes,
or something else. But we can't even experiment with it in a meaningful way
because the plumbing layer is so restrictive.

The notes feature has stagnated. Not many people use it because it requires
so much magic to set up and share notes. I think it makes sense to remove a
safety feature that is making it harder to experiment with. If the worst
case is that people start actually _using_ notes and we get proliferation of
places that people are sticking them in the refs hierarchy, that is vastly
preferable IMHO to the current state, in which few people use them and there
is little support for sharing them at all.

The original patch discussion sort of fizzled, and your response here
largely slipped through the cracks. I am not sure everyone even
remembers the exact patch under discussion. Maybe a better way to
re-kickstart the discussion is to repost the patch along with a synopsis
of the previous discussion and your arguments about moving it forward.

-Peff

  reply	other threads:[~2014-12-04 10:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-19  7:39 [PATCH] notes: accept any ref for merge Scott Chacon
2014-09-19  9:39 ` Jeff King
2014-09-19 14:01   ` Johan Herland
2014-09-19 18:22     ` Junio C Hamano
2014-09-20  0:01       ` Johan Herland
2014-09-22 17:34         ` Junio C Hamano
2014-11-22 18:04       ` Kyle J. McKay
2014-12-04 10:26         ` Jeff King [this message]
2014-09-19 17:29   ` Junio C Hamano

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=20141204102657.GA27739@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=mackyle@gmail.com \
    --cc=schacon@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).