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.
Earlier today I deleted a file from a repository. I deleted it
normally, not by using `git r
On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz
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.
>
> Earlier tod
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 wr
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
wrote:
> On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz
> wrote:
>> Hello everyo
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?
Th
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
>> c
Jonathan Nieder 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 index.
>
Matthieu Moy 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 good change to begin
Matthieu Moy 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 forbidden from a
>
On 01/20/2013 01:53 PM, Junio C Hamano wrote:
> Matthieu Moy 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
Junio C Hamano writes:
> Matthieu Moy 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
On Sun, Jan 20, 2013 at 1:27 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Matthieu Moy 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 on
On Sun, Jan 20, 2013 at 7:53 PM, Junio C Hamano wrote:
> Matthieu Moy 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
>>
Piotr Krukowiecki 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 semantics without ar
Junio C Hamano writes:
> Matthieu Moy 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
Piotr Krukowiecki 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 -u", not any other forms of
"git add ...with or without other
Junio C Hamano writes:
> Piotr Krukowiecki 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 -u", not any other forms of
On Mon, Jan 21, 2013 at 10:23 AM, Junio C Hamano wrote:
> No. This is only about "git add -u", not any other forms of
> "git add ...with or without other args...".
>
> "git add -u" historically meant, and it still means, to
> "update the index with every change in the working tree", even when
> y
Junio C Hamano 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 v1.5.2.5~1^ shows th
Matthieu Moy writes:
> Junio C Hamano 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
Eric James Michael Ritz 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, Tomas Carnecky
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 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 would suggest
On Mon, Feb 25, 2013 at 8:07 PM, Matthieu Moy
wrote:
> Antoine Pelisse 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
Antoine Pelisse 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 --cached, as
Matthieu Moy writes:
> Antoine Pelisse 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 inde
26 matches
Mail list logo
