git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jamey Sharp <jamey@minilop.net>,
	git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johannes Sixt <johannes.sixt@telecom.at>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCHv4 2/4] Add infrastructure for ref namespaces
Date: Thu, 2 Jun 2011 16:36:19 -0700	[thread overview]
Message-ID: <20110602233619.GA1931@leaf> (raw)
In-Reply-To: <7vfwnrdfam.fsf@alter.siamese.dyndns.org>

On Thu, Jun 02, 2011 at 03:44:33PM -0700, Junio C Hamano wrote:
> Jamey Sharp <jamey@minilop.net> writes:
> 
> > Note that namespaces which include a / will expand to a hierarchy of
> > namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
> > refs/namespaces/foo/refs/namespaces/bar/.  This makes GIT_NAMESPACE
> > behave hierarchically, and avoids ambiguity with namespaces such as
> > foo/refs/heads.
> 
> Sorry, but I fail to see what problem you are trying to solve here.  I am
> not suggesting that it would be better to do things in a way different
> from what your patch does, but what problem will you have if you stored
> the branch head for baz in refs/namespaces/foo/bar/refs/heads/baz given
> the namespace foo/bar, and how does it solve that problem to store it
> instead at refs/namespaces/foo/refs/namespaces/bar/refs/heads/baz?

Two reasons.  First, if you use GIT_NAMESPACE=foo (which puts its refs
under refs/namespaces/foo/refs/{heads,tags}), and also used
GIT_NAMESPACE=foo/refs/heads, that would put its refs under
refs/namespaces/foo/refs/heads/refs/{heads,tags}, which would make them
potentially conflict with foo's references.  So, for instance, you could
end up with directory/file conflicts in the refs directory.  Using
hierarchies avoids any possible conflicts and corner cases there.

Second, by making the namespaces hierarchical, we provide a kind of
composability, similar to that suggested by the analogy to chroots.
With the way we've constructed them, cloning a repo with
GIT_NAMESPACE=foo/bar has the same effect as cloning a repo with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar.

> > +int for_each_namespaced_ref(each_ref_fn fn, void *cb_data)
> 
> Just a naming and interface preference, but I would have called this
> for-each-ref-in-namespace, perhaps giving the namespace as a parameter.

for_each_ref_in and other variants already exist for that purpose;
for_each_namespaced_ref exists to automatically uses GIT_NAMESPACE.
Happy to rename it if you have another preference, but I don't think it
makes sense to support passing in arbitrary namespaces when the callers
only use it to access the currently requested namespace.  If some
situation arises in later code that needs to handle arbitrary
namespaces, it seems easy enough to provide a more generalized function
at that point, but doing so now would just make the existing callers
more complex by forcing them to do the call to get_git_namespace()
rather than allowing for_each_namespaced_ref to do it.

As far as naming, though, we have no preference whatsoever about the
color of the bikeshed. :)

- Josh Triplett

  reply	other threads:[~2011-06-02 23:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-01  0:24 [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers Jamey Sharp
2011-06-01  0:24 ` [PATCHv4 2/4] Add infrastructure for ref namespaces Jamey Sharp
2011-06-02 22:44   ` Junio C Hamano
2011-06-02 23:36     ` Josh Triplett [this message]
2011-06-03  2:51       ` Junio C Hamano
2011-06-03 17:26         ` Josh Triplett
2011-06-03  8:35   ` Jakub Narebski
2011-06-03 21:01     ` Josh Triplett
2011-06-08  9:41       ` Jakub Narebski
2011-06-09  3:38         ` Josh Triplett
2011-06-09  9:09           ` Jakub Narebski
2011-06-01  0:24 ` [PATCHv4 3/4] Support ref namespaces for remote repositories via upload-pack and receive-pack Jamey Sharp
2011-06-02 23:05   ` Junio C Hamano
2011-06-03  0:06     ` josh
2011-06-03 16:33       ` Junio C Hamano
2011-06-01  0:24 ` [PATCHv4 4/4] Add documentation for ref namespaces Jamey Sharp
2011-06-02 20:36 ` [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers Junio C Hamano
2011-06-02 20:57   ` Josh Triplett
2011-06-02 23:29     ` Junio C Hamano
2011-06-03  8:33 ` Jakub Narebski

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=20110602233619.GA1931@leaf \
    --to=josh@joshtriplett.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jamey@minilop.net \
    --cc=johannes.sixt@telecom.at \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    /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).