git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Jens Lehmann <Jens.Lehmann@web.de>,
	Heiko Voigt <hvoigt@hvoigt.net>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v3 1/2] rev-parse: add --prefix option
Date: Fri, 19 Apr 2013 12:25:24 +0100	[thread overview]
Message-ID: <20130419112524.GH2278@serenity.lan> (raw)
In-Reply-To: <CALkWK0kbXSfghZ69qypfaFF8orWy-bZLRPXcV5WMc5YQ=-18GA@mail.gmail.com>

On Fri, Apr 19, 2013 at 04:45:38PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > I'm not actually sure this is better.  I'm more afraid of the condition
> > for outputting files changing in the future than of passing
> > output_prefix around, so I'd much rather keep that condition in one
> > place.
> >
> > If you really feel strongly about it, I'd prefer to extract the if
> > condition to a function and use that directly when deciding whether to
> > print "--".
> 
> Yeah, it would probably make more sense to extract the conditional.  I
> just thought it was unnecessary to pass the argument around, but feel
> free to go either way on this one.
> 
> > [Also, you introduce a potential segfault via passing a NULL prefix to
> > strlen.]
> 
> Isn't prefix guaranteed to be set by setup_git_directory()?  If I
> wanted to check it nevertheless, I'd probably put in a die("internal
> error") before this line.  Feel free to go either way though.

It looks to me like setup_git_directory() returns NULL if we're at the
top of the working tree so we do need that check.  I suspect that's so
that "!prefix" does the right thing.

  reply	other threads:[~2013-04-19 11:25 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-07 19:55 [RFC/PATCH 0/2] submodule: drop the top-level requirement John Keeping
2013-04-07 19:55 ` [PATCH 1/2] rev-parse: add --filename-prefix option John Keeping
2013-04-07 22:14   ` Jonathan Nieder
2013-04-08  8:31     ` John Keeping
2013-04-08 15:07       ` Junio C Hamano
2013-04-08 17:36         ` John Keeping
2013-04-08 18:11           ` Junio C Hamano
2013-04-07 19:55 ` [PATCH 2/2] submodule: drop the top-level requirement John Keeping
2013-04-07 20:15 ` [RFC/PATCH 0/2] " Jens Lehmann
2013-04-09 20:29 ` [PATCH v2 " John Keeping
2013-04-09 20:29   ` [PATCH v2 1/2] rev-parse: add --filename-prefix option John Keeping
2013-04-09 20:57     ` Junio C Hamano
2013-04-09 21:28       ` John Keeping
2013-04-09 21:33         ` Junio C Hamano
2013-04-18 14:28     ` Ramkumar Ramachandra
2013-04-18 14:42       ` John Keeping
2013-04-09 20:29   ` [PATCH v2 2/2] submodule: drop the top-level requirement John Keeping
2013-04-09 21:00     ` Junio C Hamano
2013-04-09 21:29       ` John Keeping
2013-04-18 14:46     ` Ramkumar Ramachandra
2013-04-18 14:56       ` John Keeping
2013-04-18 19:50   ` [PATCH v3 0/2] " John Keeping
2013-04-18 19:50     ` [PATCH v3 1/2] rev-parse: add --prefix option John Keeping
2013-04-19  9:53       ` Ramkumar Ramachandra
2013-04-19 10:22         ` John Keeping
2013-04-19 11:15           ` Ramkumar Ramachandra
2013-04-19 11:25             ` John Keeping [this message]
2013-04-19 11:29               ` Ramkumar Ramachandra
2013-04-18 19:50     ` [PATCH v3 2/2] submodule: drop the top-level requirement John Keeping
2013-04-18 22:40       ` Junio C Hamano
2013-04-19  7:46         ` John Keeping
2013-04-19 16:45           ` Junio C Hamano
2013-04-19 19:23             ` Johannes Sixt
2013-04-19 21:03               ` Junio C Hamano
2013-04-24  8:15                 ` [PATCH] submodule: fix quoting in relative_path() John Keeping
2013-04-24 16:21                   ` Junio C Hamano
2013-04-24 16:28                     ` John Keeping
2013-04-24 19:12                       ` Johannes Sixt
2013-04-18 23:54       ` [PATCH v3 2/2] submodule: drop the top-level requirement Eric Sunshine

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=20130419112524.GH2278@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=Jens.Lehmann@web.de \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hvoigt@hvoigt.net \
    --cc=jrnieder@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).