From: Junio C Hamano <gitster@pobox.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: git@vger.kernel.org, Jared Hance <jaredhance@gmail.com>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH 1/3] Use startup_info->prefix rather than prefix.
Date: Sat, 03 Mar 2012 13:44:13 -0800 [thread overview]
Message-ID: <7vbood742a.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CACsJy8DtZLCLfeHNP_eq9kVZxjV3xh3gs6pgQCi=FDZ_Je7_Gw@mail.gmail.com> (Nguyen Thai Ngoc Duy's message of "Sat, 3 Mar 2012 16:50:33 +0700")
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> This patch makes this function only usable when startup_info pointer
> is initialized. As "git" binary is the only caller, the change is ok.
> If non-builtin commands want to use this function, they need to
> initialize startup_info first.
Hrm, that explanation is understandable, but it strongly makes me suspect
that this change is making the code _more_ error prone in the longer term.
When somebody wants to add a new caller to a non-builtin, they need to
think about what prefix to pass, and would realize that they need to call
setup_git_directory() to get it. With the updated code, they can totally
forget and call it without any initialized startup_info.
Adding a totally new command is rare, new non-builtin is rarer, and adding
trace to it is even more so, so it may not be worth worrying about, but I
wonder if there is a cheap way to check such a programming mistake.
next prev parent reply other threads:[~2012-03-03 21:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-03 2:31 [PATCH 0/3] Fix some documented fixmes Jared Hance
2012-03-03 2:31 ` [PATCH 1/3] Use startup_info->prefix rather than prefix Jared Hance
2012-03-03 7:30 ` Junio C Hamano
2012-03-03 9:50 ` Nguyen Thai Ngoc Duy
2012-03-03 21:44 ` Junio C Hamano [this message]
2012-03-03 23:23 ` Jared Hance
2012-03-03 2:31 ` [PATCH 2/3] Fix memory leak in apply_patch in apply.c Jared Hance
2012-03-03 7:41 ` Junio C Hamano
2012-03-03 2:31 ` [PATCH 3/3] Add threaded versions of functions in symlinks.c Jared Hance
2012-03-03 7:55 ` Junio C Hamano
2012-03-03 14:40 ` [PATCH v2 0/3] Fix a few documents fixmes Jared Hance
2012-03-03 14:40 ` [PATCH v2 1/3] Use startup_info->prefix rather than prefix Jared Hance
2012-03-03 14:47 ` Jeff Epler
2012-03-03 14:40 ` [PATCH v2 2/3] Fix memory leak in apply_patch in apply.c Jared Hance
2012-03-03 15:05 ` Jared Hance
2012-03-03 21:51 ` Junio C Hamano
2012-03-03 14:40 ` [PATCH v2 3/3] Add threaded versions of functions in symlinks.c Jared Hance
2012-03-05 11:00 ` Thomas Rast
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=7vbood742a.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jaredhance@gmail.com \
--cc=pclouds@gmail.com \
--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.