git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: "Kristian Høgsberg" <krh@redhat.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
Date: Sat, 3 Nov 2007 13:56:24 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0711031328500.4362@racer.site> (raw)
In-Reply-To: <1194017589-4669-4-git-send-email-krh@redhat.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3546 bytes --]

Hi,

On Fri, 2 Nov 2007, Kristian Høgsberg wrote:

> +static char *
> +prepare_index(const char **files, const char *prefix)
> +{
> +	int fd;
> +	struct tree *tree;
> +	struct lock_file *next_index_lock;
> +
> +	fd = hold_locked_index(&lock_file, 1);
> +	if (read_cache() < 0)
> +		die("index file corrupt");
> +
> +	if (all) {
> +		add_files_to_cache(verbose, NULL, files);
> +		if (write_cache(fd, active_cache, active_nr) || close(fd))
> +			die("unable to write new_index file");
> +		return lock_file.filename;
> +	} else if (also) {
> +		add_files_to_cache(verbose, prefix, files);
> +		if (write_cache(fd, active_cache, active_nr) || close(fd))
> +			die("unable to write new_index file");
> +		return lock_file.filename;
> +	}

Unless something slips by my mind, this could be written as

	if (all || also) {
		add_files_to_cache(verbose, also ? prefix : NULL, files);
		...
	}

> +
> +	if (interactive)
> +		interactive_add();
> +
> +	if (*files == NULL) {
> +		/* Commit index as-is. */
> +		rollback_lock_file(&lock_file);
> +		return get_index_file();
> +	}

Would an interactive add not conflict with this rollback?  And indeed with 
the locked index to begin with?

> +	/* update the user index file */
> +	add_files_to_cache(verbose, prefix, files);
> +	if (write_cache(fd, active_cache, active_nr) || close(fd))
> +		die("unable to write new_index file");

Does that mean that the index is _always_ written?  Even when not 
specifying and paths on the command line?

> +	/* Uh oh, abusing lock_file to create a garbage collected file */

It's not that bad.  But I would mention that it is a temporary index which 
you are building.

> +static const char sign_off_header[] = "Signed-off-by: ";

Funny, I thought it was a footer ;-)

> +	} else if (!stat(template_file, &statbuf)) {

Should this not test "if (template_file && " first?

> +/* Find out if the message starting at position 'start' in the strbuf
> + * contains only whitespace and Signed-off-by lines. */
> +static int message_is_empty(struct strbuf *sb, int start)
> +{
> +	struct strbuf tmpl;
> +	const char *nl;
> +	int eol, i;
> +
> +	/* See if the template is just a prefix of the message. */
> +	strbuf_init(&tmpl, 0);
> +	if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
> +		stripspace(&tmpl, 1);
> +		if (start + tmpl.len <= sb->len &&
> +		    memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
> +			start += tmpl.len;
> +	}
> +	strbuf_release(&tmpl);

The release could go inside the if block, no?

> +static int run_hook(const char *index_file, const char *name, const char *arg)

Would this function not prefer to live in run-command.c?

> +{
> +	struct child_process hook;
> +	const char *argv[3], *env[2];
> +	char index[PATH_MAX];
> +
> +	argv[0] = git_path("hooks/%s", name);
> +	argv[1] = arg;
> +	argv[2] = NULL;
> +	snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
> +	env[0] = index;
> +	env[1] = NULL;
> +
> +	if (access(argv[0], X_OK) < 0)
> +		return 0;

That check logically belongs 6 lines higher...

> +	rev.abbrev = 0;
> +	rev.diff = 1;
> +	rev.diffopt.output_format =
> +		DIFF_FORMAT_SHORTSTAT | DIFF_FORMAT_SUMMARY;
> +
> +	rev.verbose_header = 1;
> +	rev.show_root_diff = 1;
> +	rev.commit_format = get_commit_format("format:%h: %s");

That's interesting.  Wouldn't have thought of that.  Reusing the log_tree 
machinery to output the summary.  Cute.

Note that one relatively low-hanging fruit will be to teach builtin-commit 
to use a cheaper "no changes?" check when no_edit = 1.

Thanks,
Dscho

  reply	other threads:[~2007-11-03 13:57 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-02 15:33 [PATCH 1/4] Add testcase for ammending and fixing author in git commit Kristian Høgsberg
2007-11-02 15:33 ` [PATCH 2/4] Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites Kristian Høgsberg
2007-11-02 15:33   ` [PATCH 3/4] Export launch_editor() and make it accept ':' as a no-op editor Kristian Høgsberg
2007-11-02 15:33     ` [PATCH 4/4] Implement git commit and status as a builtin commands Kristian Høgsberg
2007-11-03 13:56       ` Johannes Schindelin [this message]
2007-11-08 16:01         ` Kristian Høgsberg
2007-11-03 15:06       ` Björn Steinbrink
2007-11-05 18:57         ` Kristian Høgsberg
2007-11-05 19:23           ` Björn Steinbrink
2007-11-05 23:18             ` Johannes Schindelin
2007-11-06  6:59               ` Björn Steinbrink
2007-11-06 16:46                 ` Kristian Høgsberg
2007-11-06 17:08                   ` Björn Steinbrink
2007-11-06  9:12               ` Pierre Habouzit
2007-11-06  9:18                 ` Johannes Sixt
2007-11-06  9:26                   ` Pierre Habouzit
2007-11-06  9:47                     ` Andreas Ericsson
2007-11-06 16:42                 ` Kristian Høgsberg
2007-11-02 15:46     ` [PATCH 3/4] Export launch_editor() and make it accept ':' as a no-op editor Andreas Ericsson
2007-11-02 16:16       ` Kristian Høgsberg
2007-11-02 20:09   ` [PATCH 2/4] Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites Junio C Hamano
2007-11-02 20:07 ` [PATCH 1/4] Add testcase for ammending and fixing author in git commit Junio C Hamano
2007-11-02 21:13   ` Kristian Høgsberg
2007-11-02 22:33     ` Junio C Hamano

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=Pine.LNX.4.64.0711031328500.4362@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=krh@redhat.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).