Jonathan Nieder jrnie...@gmail.com writes:
The warning about use of 'git add -u' with no pathspec is annoying
because it serves no purpose in this case. So suppress the warning
unless there are changes outside the cwd that are not being added.
No time to review the code now. I thought about
Jonathan Nieder jrnie...@gmail.com writes:
Yes, that can work, for example like this (replacing the patch you're
replying to).
I think that would be a better approach if we were to do this. I
still have the same reservation that this is fundamentally not
worse but still hurts the users more.
Matthieu Moy matthieu@grenoble-inp.fr writes:
No time to review the code now. I thought about implementing something
like that, but did not do it because I didn't want the change in the
code to be too big. At some point, we'll have to remove the warning and
it's easier with my version
Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
No time to review the code now. I thought about implementing something
like that, but did not do it because I didn't want the change in the
code to be too big. At some point, we'll have to remove the warning and
it's
Jonathan Nieder jrnie...@gmail.com writes:
... So I
find myself being trained to ignore the warning.
... Running a full-tree diff which slows down
the code that decides whether to print a warning is a good way to
train people regarding how long to expect a plain git add -u to
take.
Ok,
Junio C Hamano wrote:
Incidentally, I am rebuilding the 'next' by kicking many of the
topics back to 'pu' (essentially, only the ones marked as Safe in
the latest issue of What's cooking are kept in 'next'), so perhaps
we can rebuild the jc/add-2.0-u-A-sans-pathspec topic with your
series at
A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:
cd src
vi foo.c
make test
git add -u
git commit
The upcoming change to 'git add -u' behavior would not affect such a
workflow: when the only changes
Jonathan Nieder jrnie...@gmail.com writes:
A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:
cd src
vi foo.c
make test
git add -u
git commit
The upcoming change to 'git add -u' behavior would not affect
Junio C Hamano wrote:
The implemenation appears to run an extra diff_files() in addition
to the one we already have to run in order to implement the add -u
to collect modified/deleted paths. Is that the best we can do?
I am wondering if we can special case the no-pathspec case to have
Junio C Hamano wrote:
The implemenation appears to run an extra diff_files() in addition
to the one we already have to run in order to implement the add -u
to collect modified/deleted paths. Is that the best we can do?
At least the following should be squashed in to avoid wasted effort in
On Tue, Mar 19, 2013 at 11:25 AM, Junio C Hamano gits...@pobox.com wrote:
I am wondering if we can special case the no-pathspec case to have
add_files_to_cache() call underlying run_diff_files() without any
pathspec, inspect the paths that are modified and/or deleted in the
update_callback,
Duy Nguyen wrote:
My concern is run full-tree diff can be expensive on large repos (one
of the reasons the user may choose to work from within a
subdirectory). We can exit as soon as we find a difference outside
$prefix. But in case we find nothing, we need to diff the whole
worktree.
Yes.
12 matches
Mail list logo
