All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/3] Different views on a repository
Date: Wed, 24 Feb 2010 09:42:35 -0800	[thread overview]
Message-ID: <20100224174235.GA20567@spearce.org> (raw)
In-Reply-To: <92fea2335b73265b04d64fcc217055e1170f5e16.1267029680.git.agruen@suse.de>

Andreas Gruenbacher <agruen@suse.de> wrote:
> Add --view options in upload-pack and receive-pack so that a repository
> on the server side can be made to look like several independent
> repositories on the client side.

Before saying this is good... I'd like to know how a repository owner
is supposed to set these options on the user started invocations
of other remote side program.

Right now, I don't see how this is too different from just
doing the following on a client:

  git init
  git remote add origin URL
  git config remote.origin.fetch refs/heads/one/*:refs/remotes/origin/*

and therefore shouldn't just be handled on the *client* side of the
connection, as part of the remote setup and push matching refs rules.

(Of course, the push matching ref logic is messy too... adding yet
more into that pile might also be ugly.)

> +const char *view_to_ref(const char *refname, const char *view)
> +{
> +	static char *buffer;
...
> +	buffer = xrealloc(buffer, prefix_len + view_len + suffix_len + 1);
> +	sprintf(buffer, "%.*s%s%s", prefix_len, refname, view, suffix);
> +	return buffer;

I'd rather not use a static buffer like this.  Why not alloc and let
the caller free?  Or have the caller pass in a strbuf you populate
for them?

-- 
Shawn.

  parent reply	other threads:[~2010-02-24 17:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 16:41 [RFC][PATCH 0/3] Different views on a repository Andreas Gruenbacher
2010-02-24 15:33 ` [PATCH 1/3] receive-pack: Two small code cleanups Andreas Gruenbacher
2010-02-24 15:57   ` [PATCH 2/3] Different views on a repository Andreas Gruenbacher
2010-02-24 16:14     ` [PATCH 3/3] Different views on a repository: HEAD mapping Andreas Gruenbacher
2010-02-24 17:42     ` Shawn O. Pearce [this message]
2010-02-25  9:01     ` [PATCH 2/3] Different views on a repository Michael J Gruber
2010-02-25  9:25       ` Andreas Gruenbacher
2010-02-25 12:30         ` Michael J Gruber
2010-02-25 14:35           ` Andreas Gruenbacher
2010-02-25 17:28             ` Junio C Hamano
2010-02-26  0:45               ` Andreas Gruenbacher
2010-02-26 21:35                 ` Andreas Gruenbacher
2010-02-24 17:29   ` [PATCH 1/3] receive-pack: Two small code cleanups Shawn O. Pearce
2010-02-25 20:13 ` [RFC][PATCH 0/3] Different views on a repository James Pickens
2010-02-26  4:30 ` Adam Brewster
     [not found] ` <c376da901002252012s507a6921q922e606bdce4b4fa@mail.gmail.com>
2010-02-26 12:01   ` Andreas Gruenbacher

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=20100224174235.GA20567@spearce.org \
    --to=spearce@spearce.org \
    --cc=agruen@suse.de \
    --cc=git@vger.kernel.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 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.