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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
