git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability
Date: Mon, 21 Jul 2008 00:52:06 -0700	[thread overview]
Message-ID: <7v7ibfvfmh.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7v3am3yfph.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 20 Jul 2008 22:22:02 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> That changed late 2006 when Nico allowed git-add to stage already tracked
> files as well.  We collect the paths in the work tree that match given
> pathspec, and for the directory traverser to do that job, you would need
> an empty index.
>
> 	Side note: 366bfcb (make 'git add' a first class user friendly
> 	interface to the index, 2006-12-04) is something to marvel at.  It
> 	describes the change with its documentation update fully, changes
> 	the semantics in a drastic way, with so little change.
>
>         Documentation/git-add.txt  |   53 ++++++++++++-----------
>         Documentation/tutorial.txt |   46 ++++++++++++++++++---
>         builtin-add.c              |    6 +-
>         wt-status.c                |    2 +-
>         4 files changed, 72 insertions(+), 35 deletions(-)
>
> Perhaps we can add a bit to the dir_struct we give to the traverser to
> tell it to ignore the index even if we have already read one.  That would
> be a much cleaner API enhancement than reading the index and setting aside
> while calling read_directory() which feels like a you know what I would
> call it.

Thinking about this issue a bit more, I realize that the earlier "git add -A"
change was done in a quite inefficient way (i.e. it is as unefficient as
"git add -u && git add ." modulo one fork/exec and read/write index).  For
that matter, the original "git add ." could probably be more efficient
than it currently is.

The thing is, when the user asks "git add .", we do not have to examine
all paths we encounter and perform the excluded() and dir_add_name()
processing, both of which are slower code and use slower data structure by
git standard, especially when the index is already populated.

Instead, we should be able to implement "git add $pathspec..." as:

 - read the index;

 - read_directory() to process untracked, unignored files the current way,
   that is, recursively doing readdir(), filtering them by pathspec and
   excluded(), queueing them via dir_add_name() and finally do
   add_files(); and

 - iterate over the index, filtering them by pathspec, and update only the
   modified/type changed paths but not deleted ones.

And "git add -A" will become exactly the same as above, modulo:

 - missing $pathspec means "." instead of being an error; and 

 - "interate over the index" part handles deleted ones as well,
   i.e. exactly what the current update_callback() in builtin-add.c does.

It is likely that I am too tired to do this right tonight, so I'll go to
bed and expect to find a nicely done patch in my mailbox by somebody else
;-).

  reply	other threads:[~2008-07-21  7:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-20  6:09 [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability Junio C Hamano
2008-07-20  6:09 ` [PATCH v2 2/4] git-add --all: add all files Junio C Hamano
2008-07-20  6:09   ` [PATCH v2 3/4] git-add --all: tests Junio C Hamano
2008-07-20  6:09     ` [PATCH v2 4/4] git-add --all: documentation Junio C Hamano
2008-07-21  0:56 ` [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability Johannes Schindelin
2008-07-21  0:58   ` [PATCH/RFC] git add: do not add files from a submodule Johannes Schindelin
2008-07-22 21:32     ` Johannes Schindelin
2008-07-23  6:40       ` Junio C Hamano
2008-07-23  8:13         ` Pierre Habouzit
2008-07-23 18:31           ` Junio C Hamano
2008-07-23 19:02             ` Pierre Habouzit
2008-07-23 19:10               ` Johannes Schindelin
2008-07-23 19:11                 ` Pierre Habouzit
2008-07-21  5:22   ` [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability Junio C Hamano
2008-07-21  7:52     ` Junio C Hamano [this message]
2008-07-21  8:24       ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v7ibfvfmh.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).