I must say that I'm not very interested in the feature. In my opinion,
there are already many different ways to stage changes.
Assuming that the feature would be needed, I would keep it under the
scope of git-add, as it's the reference for staging. I would suggest
something like:
git add -r
Antoine Pelisse apeli...@gmail.com writes:
I must say that I'm not very interested in the feature. In my opinion,
there are already many different ways to stage changes.
Assuming that the feature would be needed, I would keep it under the
scope of git-add, as it's the reference for staging. I
On Mon, Feb 25, 2013 at 8:07 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Antoine Pelisse apeli...@gmail.com writes:
I must say that I'm not very interested in the feature. In my opinion,
there are already many different ways to stage changes.
Assuming that the feature would be
Antoine Pelisse apeli...@gmail.com writes:
git rm really seems to be a better place for removing files from the
index.
Then, I don't exactly understand the meaning of git-rm but being a
_shortcut_ for remove and stage.
git rm --cached is exactly remove from index.
And even without
Matthieu Moy matthieu@grenoble-inp.fr writes:
Antoine Pelisse apeli...@gmail.com writes:
git rm really seems to be a better place for removing files from the
index.
Then, I don't exactly understand the meaning of git-rm but being a
_shortcut_ for remove and stage.
git rm --cached is
Eric James Michael Ritz lobbyjo...@gmail.com writes:
On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
I think `git add -u` would be closer. It would stage removal of
files, but would not stage untracked files. It would stage other
type of changes though.
On Sat, Jan 19, 2013 at 10:47 PM,
On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Implementing git rm -u as a tree-wide command would create a
discrepancy with git add -u. Implementing it as a current directory
command would make the migration harder
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Do you mean git add will be disallowed without . or :/ argument?
Or will this change in future and git add without argument will me
whole tree, same as :/ ?
Let's talk conditional, not future, for now.
If the idea is to change the
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
git add -u is one of the only exceptions (with git grep). I consider
this as a bug, and think this should be changed. This has been discussed
several times here, but no one took the time to actually do
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Do you mean git add will be disallowed without . or :/ argument?
Or will this change in future and git add without argument will me
whole tree, same as :/ ?
No. This is only about git add -uRETURN, not any other forms of
git add ...with
Junio C Hamano gits...@pobox.com writes:
Piotr Krukowiecki piotr.krukowie...@gmail.com writes:
Do you mean git add will be disallowed without . or :/ argument?
Or will this change in future and git add without argument will me
whole tree, same as :/ ?
No. This is only about git add
On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano gits...@pobox.com wrote:
No. This is only about git add -uRETURN, not any other forms of
git add ...with or without other args
git add -uRETURN historically meant, and it still means, to
update the index with every change in the working
Junio C Hamano gits...@pobox.com writes:
But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
2007-08-16) changed the semantics to limit the operation to the
working tree.
Not really. It fixed git add -u path, not plain git add -u. A quick
test checking out and compiling
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
But v1.5.2.5~1 (git-add -u paths... now works from subdirectory,
2007-08-16) changed the semantics to limit the operation to the
working tree.
Not really. It fixed git add -u path, not plain git add
Jonathan Nieder jrnie...@gmail.com writes:
Eric James Michael Ritz wrote:
When I came to my senses and realized that does not work I began to
wonder if `git rm -u` should exist. If any deleted, tracked files are
not part of the index to commit then `git rm -u` would add that change
to the
Matthieu Moy matthieu@grenoble-inp.fr writes:
git add -u is one of the only exceptions (with git grep). I consider
this as a bug, and think this should be changed. This has been discussed
several times here, but no one took the time to actually do the change
Did we ever agree that it is a
Matthieu Moy matthieu@grenoble-inp.fr writes:
Implementing git rm -u as a tree-wide command would create a
discrepancy with git add -u. Implementing it as a current directory
command would make the migration harder if we eventually try to change
git add -u. Perhaps git rm -u should be
On 01/20/2013 01:53 PM, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Implementing git rm -u as a tree-wide command would create a
discrepancy with git add -u. Implementing it as a current
directory command would make the migration harder if we eventually
try to
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
git add -u is one of the only exceptions (with git grep). I consider
this as a bug, and think this should be changed. This has been discussed
several times here, but no one took the time to actually do
On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
git add -u is one of the only exceptions (with git grep). I consider
this as a bug, and think this should be changed. This has
On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz
lobbyjo...@gmail.com wrote:
Hello everyone,
I am thinking about implementing a feature but I would appreciate any
feedback before I begin, because more experienced Git developers and
users may see some major problem that I do not.
Eric James Michael Ritz wrote:
When I came to my senses and realized that does not work I began to
wonder if `git rm -u` should exist. If any deleted, tracked files are
not part of the index to commit then `git rm -u` would add that change
to the index.
I like it. If you have time to write
I think `git add -u` would be closer. It would stage removal of files,
but would not stage untracked files.
It would stage other type of changes though.
On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
tomas.carne...@gmail.com wrote:
On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz
On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
I think `git add -u` would be closer. It would stage removal of
files, but would not stage untracked files. It would stage other
type of changes though.
On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
Does `git add -A` do what you want?
Thank
On 01/19/2013 04:49 PM, Jonathan Nieder wrote:
Eric James Michael Ritz wrote:
When I came to my senses and realized that does not work I began to
wonder if `git rm -u` should exist. If any deleted, tracked files
are not part of the index to commit then `git rm -u` would add that
change to
25 matches
Mail list logo
