From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Git List <git@vger.kernel.org>, Johan Herland <johan@herland.net>,
Jeff King <peff@peff.net>
Subject: Re: proper remote ref namespaces
Date: Wed, 12 Aug 2015 09:10:06 -0700 [thread overview]
Message-ID: <xmqqfv3omqsh.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com> (Jacob Keller's message of "Tue, 11 Aug 2015 23:43:56 -0700")
Jacob Keller <jacob.keller@gmail.com> writes:
> Recently there was some discussion about git-notes and how we do not
> fetch notes from remotes by default. The big problem with doing so is
> because refs/remotes/* hierarchy is only setup for branches (heads),
> so we don't have any clean location to put them.
I wouldn't call this topic "proper" namespaces, though. What we
have is widely used and it shouldn't be broken. Call it "enhanced",
perhaps.
Some design boundaries:
- Moving the remote-tracking branch hierarchy from refs/remotes/$O/*
to refs/remotes/$O/heads/* would not fly, because it will break
existing repositories. Do not even waste time on pursuing
refs/remotes/$O/{heads,tags,notes...}/*
- Extending the current refs/remotes/$O/* (for branches) and doing
refs/remote-tags/$O/* (for tags) may work, would not break
existing repositories, and could to be extended further to cover
refs/remote-notes/$O and friends. It however may not look pretty
(weak objection) and more importantly, it would make it harder to
"cull" things that came from a single remote.
Just thinking aloud, perhaps we can introduce a brand new top level
hierarchy refs/remote/$O/{heads,tags,notes,...}, and give backward
compatibility by making a moral equivalent of a symbolic link from
refs/remote/$O/heads to refs/remotes/$O/. The true remote-tracknig
refs continue to live in refs/remotes/$O/* and old tools that do not
know the new layout would not be hurt. New tools that want to
ignore and look only at refs/remote/$O/* can do so through the moral
equivalent of a symbolic link. "remote remove" needs to be taught
about this single exception (i.e. "the symbolic link"), but the
places it needs to touch is limited only to two places and will not
grow.
If somebody got confused, notice that in the above description, I
said refs/remotes/ and refs/remote/. The former must stay. The
name of the latter is open to bikeshedding. Some may prefer a name
that is more distinct (refs/tracking/ or something, perhaps?). I
happen to prefer a name that is similar, but this preference is very
weak and I can persuaded to go either way.
prev parent reply other threads:[~2015-08-12 16:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 6:43 proper remote ref namespaces Jacob Keller
2015-08-12 15:18 ` Marc Branchaud
2015-08-12 19:35 ` Junio C Hamano
2015-08-12 16:10 ` Junio C Hamano [this message]
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=xmqqfv3omqsh.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jacob.keller@gmail.com \
--cc=johan@herland.net \
--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.