From: Jonathan Nieder <jrnieder@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH] reset: Libify reset_index_file and print_new_head_line
Date: Fri, 10 Jun 2011 05:35:32 -0500 [thread overview]
Message-ID: <20110610103532.GA32119@elie> (raw)
In-Reply-To: <1307546728-11202-1-git-send-email-artagnon@gmail.com>
Hi Ram,
Ramkumar Ramachandra wrote:
> This patch lays the foundation for libifying reset by starting with
> two "easy" methods. I'll be using print_new_head_line in the
> sequencer series while implementing --abort.
It should be easier to review this one with a caller in mind to give
an indication about whether the API is right. More generally, the
excitement of patches exposing new library code comes when you can see
the header with a pleasant API, ideally followed by an example or two
to see how it plays out in practice. See "git log --grep=API junio/pu"
for a few recent examples of this.
> --- /dev/null
> +++ b/reset.c
> @@ -0,0 +1,81 @@
> +#include "builtin.h"
> +#include "refs.h"
> +#include "diff.h"
> +#include "diffcore.h"
> +#include "tree.h"
> +#include "branch.h"
> +#include "tree.h"
> +#include "unpack-trees.h"
> +#include "reset.h"
Are these all needed? E.g., where is diffcore used?
> --- /dev/null
> +++ b/reset.h
> @@ -0,0 +1,11 @@
> +#ifndef RESET_H
> +#define RESET_H
> +
> +#include "commit.h"
We can avoid unnecessarily rebuilding (if COMPUTE_HEADER_DEPENDENCIES
is set) for callers that do not use commit.h when commit.h changes by
just declaring
struct commit;
Leaving out the declaration altogether would _almost_ work but the
declaration is needed for type in the function declaration and a later
definition of "struct commit" to refer to the same type.
Actually more important than the above is avoiding mutual dependencies
between header files, but the above makes for a more entertaining
story about why to avoid unnecessary #includes.
> +
> +enum reset_type { MIXED, SOFT, HARD, MERGE, KEEP, NONE };
The names of these identifiers (especially KEEP, MERGE, and NONE)
would have a good chance to colliding with other uses after being
exposed into a global namespace like this, no?
Maybe RESET_MIXED, RESET_SOFT, etc could avoid this while still not
being too verbose.
> +
> +int reset_index_file(const unsigned char *sha1, int reset_type, int quiet);
> +void print_new_head_line(struct commit *commit);
Warning: trivia ahead.
For some odd reason I still remember a patch from Stefan Beyer:
http://thread.gmane.org/gmane.comp.version-control.git/92023
which was probably too invasive to apply but made the whole codebase
oddly more pleasant when I tried it. It simply added "extern" at the
start of function prototypes in header files that lacked it.
Sorry I don't have any more substantial comments on this one at the
moment. Still, hope that helps.
next prev parent reply other threads:[~2011-06-10 10:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 15:25 [PATCH] reset: Libify reset_index_file and print_new_head_line Ramkumar Ramachandra
2011-06-10 10:35 ` Jonathan Nieder [this message]
2011-06-11 6:07 ` Ramkumar Ramachandra
2011-06-11 6:10 ` [PATCH v2] " Ramkumar Ramachandra
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=20110610103532.GA32119@elie \
--to=jrnieder@gmail.com \
--cc=artagnon@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).