All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Kristian Høgsberg" <krh@redhat.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/4] This exports the update() function from builtin-add.c as
Date: Thu, 27 Sep 2007 02:05:58 -0700	[thread overview]
Message-ID: <7v7imcv5op.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 1190868632-29287-2-git-send-email-krh@redhat.com

Kristian Høgsberg <krh@redhat.com> writes:

> Signed-off-by: Kristian Høgsberg <krh@redhat.com>

Huh?  -EPARSE_TITLE_STRING

[PATCH 1/4] Add a simple option parser for use by builtin-commit.c.
[PATCH 2/4] This exports the update() function from builtin-add.c as
[PATCH 3/4] Implement git commit as a builtin command.
[PATCH 4/4] Move launch_editor() and stripspace() to new file editor.c.

Let's step back a bit.  The whole series organization is very
screwy.  Especially I do not think 4/4 should be at the end.

Reviewing your old series...

 * Enable wt-status output to a given FILE pointer.
 * Enable wt-status to run against non-standard index file.

Let's have the above two from the previous series in 'next'.

Now the following five that have been in 'pu' are from the older
series:

 * Introduce entry point for launching add--interactive.
 * Clean up stripspace a bit, use strbuf even more.
 * Add strbuf_read_file().
 * Export rerere() and launch_editor().
 * Implement git commit as a builtin command.

The changes to stripspace and strbuf_read_file() are unrelated
to making the commit command a builtin.  I have extended the
strbuf topic with these two and merged the result to 'next'.

I think the right organization for the "builtin-commit" series
should be:

 * merge strbuf topic in kh/commit topic, in order to get the
   stripspace updates and strbuf_read_file();

 * add--interactive entry point change (respin the one from the
   old series);

 * rename update() to add_files_to_cache() and export (respin
   this [2/4] with a better commit message);

 * create a separate rerere() function and export (respin part
   of old series, with proper refactoring);

   I am not happy with builtin-foo.c calling into something from
   builtin-bar.c, though.  We probably would want to move
   rerere() and add_files_to_cache() somewhere else.

 * move launch_editor() and stripspace() to create editor.c (new
   [4/4]);

 * add option parser in parse-options.[ch] (new [1/4]);

 * finally, create builtin-commit that uses the groundwork laid
   out above (new [3/4]).

I ended up doing the above up to the rerere() one myself, but
haven't done the rest.

I probably would start more aggressively asking the original
author to clean up and resubmit from now on.  I haven't managed
to scrape enough time for myself to code anything meaningful for
git recently, and instead spent too much time fixing up other
peoples code.

  parent reply	other threads:[~2007-09-27  9:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-27  4:50 [PATCH 1/4] Add a simple option parser for use by builtin-commit.c Kristian Høgsberg
2007-09-27  4:50 ` [PATCH 2/4] This exports the update() function from builtin-add.c as Kristian Høgsberg
2007-09-27  4:50   ` [PATCH 3/4] Implement git commit as a builtin command Kristian Høgsberg
2007-09-27  4:50     ` [PATCH 4/4] Move launch_editor() and stripspace() to new file editor.c Kristian Høgsberg
2007-09-27  9:05   ` Junio C Hamano [this message]
2007-10-03 22:03     ` [PATCH 2/4] This exports the update() function from builtin-add.c as Kristian Høgsberg
2007-09-27 11:47   ` Johannes Schindelin
2007-09-27 19:50     ` Junio C Hamano
2007-09-30 13:11 ` [PATCH 1/4] Add a simple option parser for use by builtin-commit.c Jonas Fonseca
2007-10-01 10:14   ` Johannes Schindelin
2007-10-01 10:31     ` Jonas Fonseca
2007-10-01 11:39       ` Johannes Schindelin
2007-10-01 15:00     ` Jeff King
2007-10-01 16:26   ` Kristian Høgsberg
2007-10-01 18:13     ` Johannes Schindelin
2007-10-03 20:11       ` Jonas Fonseca
2007-10-03 21:53         ` Kristian Høgsberg

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=7v7imcv5op.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --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 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.