Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch

From: Jeff King <peff@peff.net>
Date: Nov 22, 2007, 09:13 UTC
Message-ID: <20071122091356.GD7153@sigill.intra.peff.net>
In-Reply-To: <7vk5obb09a.fsf@gitster.siamese.dyndns.org>

On Wed, Nov 21, 2007 at 04:18:57PM -0800, Junio C Hamano wrote:

> What I meant was that if "git add -i" (unrestricted) shows paths
> from a set A, "git add -i paths..." should show paths from a
> subset of the set A and that subset should be defined with the
> existing ls-files pathspec semantics.

Ah, I think that is definitely the right behavior. But it does raise one more question: is going right into the 'add hunk' interface the correct behavior, or is that an orthogonal issue?

IOW, do we actually want to support:

  # go to patch menu for each file
  git-add -i -p file1 file2 ...
  # add untracked for each file
  git-add -i -a file1 file2 ...

Which is of course tricky because the '-p' is contextually dependent on the presence of '-i'.

But perhaps there is no need, since for just these two operations you can do something like:

  foreach my $file (@ARGV) {
    if(tracked($file)) {
      patch_update_file($file);
    }
    else {
      add_tracked($file);
    }
  }

Are there any other per-file operations that would make sense to start with? Or might somebody just want to path-limit _without_ starting the hunk selector?

-Peff