Re: [RFC] git rm -u
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 Stage removal of deleted files. On Mon, Feb 25, 2013 at 7:54 AM, Junio C Hamano gits...@pobox.com wrote: 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, Tomas Carnecky Does `git add -A` do what you want? Thank you Tomas and Antoine. Both of these commands do what I want: stage deleted files on the index. But does the idea of a `git rm -u` still sound useful since these commands also stage changes besides deleted files? Even though I am not sure how often I would use it myself, reflect only the removals in the working tree to the index, but exclude any other kind of changes might turn out to be a useful addition to the toolchest in certain cases. I however am not yet convinced that git rm -u is a good way to express the feature at the UI. git add -u is update the index with modification and removal but ignore new files because we won't know if they are garbage or assets. What the same -u option means in the context of git rm is not very clear, at least to me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 would suggest something like: git add -r Stage removal of deleted files. Would add -r stand for add --remove? That would be weird ... git rm really seems to be a better place for removing files from the index. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 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 Stage removal of deleted files. Would add -r stand for add --remove? That would be weird ... Yes (for --remove), It would not be weird if you consider the opposite of add to be reset (and not rm). 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. Here the files are already removed, we only need to stage and the best command to stage changes is add. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 --cached, as you notice yourself, it does a remove and stage [removal], so why would it be inappropriate to stage a removal? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 exactly remove from index. And even without --cached, as you notice yourself, it does a remove and stage [removal], so why would it be inappropriate to stage a removal? I do not think git rm is a bad place to add the feature; I was questioning if -u is an appropriate option. The option -u given to git add is internally called take worktree changes, and we would need the option to git rm with that internal meaning. The superficial meaning updated that -u in add -u stands for does not really match what git rm --take-worktree-changes wants to do, as we obviously do not want to remove all updated/modified files. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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, Tomas Carnecky Does `git add -A` do what you want? Thank you Tomas and Antoine. Both of these commands do what I want: stage deleted files on the index. But does the idea of a `git rm -u` still sound useful since these commands also stage changes besides deleted files? Even though I am not sure how often I would use it myself, reflect only the removals in the working tree to the index, but exclude any other kind of changes might turn out to be a useful addition to the toolchest in certain cases. I however am not yet convinced that git rm -u is a good way to express the feature at the UI. git add -u is update the index with modification and removal but ignore new files because we won't know if they are garbage or assets. What the same -u option means in the context of git rm is not very clear, at least to me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 if we eventually try to change git add -u. Perhaps git rm -u should be forbidden from a subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. Yeah, that sounds sensible. Start with a 'git rm -u' is forbidden without arguments, give advise to use either . or :/. And stop there. The first step of git add -u migration plan would be to warn when no argument is given and update all the existing index entries, and give the same advise to use either . or :/. Keep this for three cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year. The second step would be to forbid git add -u, and keep the advise. That will make it in-line with git rm -u. 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 :/ ? -- Piotr Krukowiecki -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 semantics without argument, it has to be done carefully, and implies disallowing the argumentless version for a while (or some better idea) to avoid confusion. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 the change Did we ever agree that it is a good change to begin with? Pointers? I don't think a consensus was reached, but it has been discussed at least once in this thread: http://thread.gmane.org/gmane.comp.version-control.git/166223/focus=168238 Essentially, the discussion boiled down to it would be cool to change, but the migration won't be easy. The main argument for change is (for me) consistency. Having git add -p tree-wide and git add -u limited to . is really strange. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 or without other args git add -uRETURN historically meant, and it still means, to update the index with every change in the working tree, even when you are in a subdirectory. Back when git add -u was invented, we didn't have the :/, which lets us tell commands that take pathspecs I want everything from the top of the working tree.. If git add -uRETURN limited its operation to the current directory, after working everywhere in the working tree, cd'ing around and ending up to be in a subdirectory somwhere deep, you had to cd ../../.. git add -u, which was cumbersome. If git add -u always meant the whole tree, limiting it to the current directory with git add -u .RETURN was easy, and that is why the default was chosen to the whole tree. Because we have :/ these days, changing something that limits its action to the current directory by default to instead work on the whole tree no longer makes much sense. That is, if we _were_ to change git add -uRETURN, it would be in the opposite direction, i.e. to update the index only with the paths below the current directory. Such a change has to be done carefully. Existing users do expect the current behaviour, so we have to first _break_ their fingers and habits and train them to say add -u :/ when they mean the whole tree operation. Silently accepting add -u and changing its meaning to update the index only with the paths below the current directory will cause them trouble by leaving changes they _thought_ they added out of the index, and is an unacceptable change. The first step of migration is git add -uRETURN that loudly warns, so that uses of that form in scripts are updated before the second step to avoid a flag-day breakage and start traing fingers and habits of the users. The second step is to make add -uRETURN fail, again with a message that tells users to be explicit and add :/ or . at the end if they mean the whole tree or the current directory. After keeping Git in that secnd step for sufficiently long time to train users to type :/ or . explicitly, we can then finally switch the default of git add -uRETURN to limit it to the current directory, instead of failing the command. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 -uRETURN, not any other forms of git add ...with or without other args This part is still correct, but all the remainder of the message I am responding to is a total garbage, written from faulty memory without fact check. Sorry about noise. git add -uRETURN historically meant,... The very original git add -uRETURN done at v1.5.2-rc0~17^2 (git-add -u: match the index with working tree., 2007-04-20) did update the index with every change under the root of the working tree, no matter where you were. 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. The log message seems to suggest that this was a deliberate semantics change post release (i.e. the tree-wide was a bug); I do not recall if there was a discussion and concensus when this change was made, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 tree, even when you are in a subdirectory. But it *currently* limits itself to a subdirectory - does not work on whole tree: piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: dir2/file2.txt # modified: file1.txt # modified: ../file.txt # no changes added to commit (use git add and/or git commit -a) piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git add -u piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git status # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: dir2/file2.txt # modified: file1.txt # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: ../file.txt # piotr@PIOTR-X73 ~/dv/test/dir1 (master) $ git --version git version 1.8.0.msysgit.0 -- Piotr Krukowiecki -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 v1.5.2.5~1^ shows that git add -u . from a subdirectory was adding everything from the root. My interpretation is that v1.5.2.5~1 fixed an actual bug, without thinking about what would happen when git add -u was called without path, so the behavior is what happens to be the most natural to implement. Indeed, the behavior was actually documented only later, in v1.5.4.3~3 (Feb 21 00:29:39 2008, Clarified the meaning of git-add -u in the documentation), the previous doc said only If no paths are specified, all tracked files are updated.. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 -u. A quick test checking out and compiling v1.5.2.5~1^ shows that git add -u . from a subdirectory was adding everything from the root. My interpretation is that v1.5.2.5~1 fixed an actual bug, without thinking about what would happen when git add -u was called without path, so the behavior is what happens to be the most natural to implement. I guess at this point it does not matter that much if that was an unintended consequence of a buggy fix, or a new behaviour by design. We initially were tree-wide but later limited the operation to the current directory. I think your Check 'git diff' then run 'git add -u' example may be a good enough argument that it is a good idea to restore the originally intended tree-wide behaviour in any case. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 index. I like it. If you have time to write such a patch, I'll be happy to read it. I can leave with git add -u, but a git rm -u that would only look at deletions, and not stage existing files changes would make sense. One thing to be careful about is what to do when the command is called from a subdirectory. In general, Git commands use this convention: * git foo = tree-wide command * git foo . = restrict to current directory 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 (changing is easy, but having a correct migration plan wrt backward compatibility is not). 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 subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 good change to begin with? Pointers? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 forbidden from a subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. Yeah, that sounds sensible. Start with a 'git rm -u' is forbidden without arguments, give advise to use either . or :/. And stop there. The first step of git add -u migration plan would be to warn when no argument is given and update all the existing index entries, and give the same advise to use either . or :/. Keep this for three cycles: 3 * (8 to 10 weeks per cycle) = 27 weeks ~ 1/2 year. The second step would be to forbid git add -u, and keep the advise. That will make it in-line with git rm -u. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 change git add -u. Perhaps git rm -u should be forbidden from a subdirectory (with an error message pointing to git rm -u :/ and git rm -u .), waiting for a possible git add -u change. Yeah, that sounds sensible. Start with a 'git rm -u' is forbidden without arguments, give advise to use either . or :/. And stop there. I was unaware of any plan to change `git add -u`, but the above makes sense to me. I will use those suggestions as guidelines for the initial implementation of `git rm -u`. In particular, it will require an argument like `.` or `:/`. It sounds like the future direction of `git add -u` will play a role in how `git rm -u` should behave so that there is consistency between the two, so I will try to take a conservative approach in my implementation. Thank you both for the advice and insight. -- ejmr 南無妙法蓮華經 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 the change Did we ever agree that it is a good change to begin with? Pointers? I think you can guess but I no longer need pointers. Others may still be helped, though. The argument IIRC boils down to - git add -u was made a whole-tree operation when there weren't the :/ magic pathspec, but add -u is very often something you want to do whole tree, and (cd ../../..; git add -u) or git add -u ../../.. are too cumbersome to type. - git add -u . to limit it to the current directory is easy to type. - As we have the from the root magic pathspec these days, requiring git add -u :/ when the user really means to add everything is no longer too much of a burden, but if we suddenly changed git add -u to mean git add -u ., that is too much of a change in the semantics. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 been discussed several times here, but no one took the time to actually do the change - As we have the from the root magic pathspec these days, requiring git add -u :/ when the user really means to add everything is no longer too much of a burden, but if we suddenly changed git add -u to mean git add -u ., that is too much of a change in the semantics. And I think someone (Jeff?) pointed out that that last part is even more true for git clean, which also currently works on the current directory if not told otherwise. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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. Earlier today I deleted a file from a repository. I deleted it normally, not by using `git rm`. So when I looked at `git status` on my terminal it told me about the file no longer being there. In my sleepy state of mind I ran `git rm -u` without thinking about. I did this because I have a habit of using `git add -u`. I know `git rm` does not support that option, but I tried it anyways without thinking about it. 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. This would save users the effort of having to type out `git rm filename`, and could be useful when a user is deleting multiple files. Does this sound like a reasonable, useful feature to Git? Or is there already a way to accomplish this which I have missed out of ignorance? Any thoughts and feedback would be greatly appreciated. Does `git add -A` do what you want? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 such a patch, I'll be happy to read it. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 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. Earlier today I deleted a file from a repository. I deleted it normally, not by using `git rm`. So when I looked at `git status` on my terminal it told me about the file no longer being there. In my sleepy state of mind I ran `git rm -u` without thinking about. I did this because I have a habit of using `git add -u`. I know `git rm` does not support that option, but I tried it anyways without thinking about it. 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. This would save users the effort of having to type out `git rm filename`, and could be useful when a user is deleting multiple files. Does this sound like a reasonable, useful feature to Git? Or is there already a way to accomplish this which I have missed out of ignorance? Any thoughts and feedback would be greatly appreciated. Does `git add -A` do what you want? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 you Tomas and Antoine. Both of these commands do what I want: stage deleted files on the index. But does the idea of a `git rm -u` still sound useful since these commands also stage changes besides deleted files? -- ejmr 南無妙法蓮華經 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] git rm -u
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 the index. I like it. If you have time to write such a patch, I'll be happy to read it. Thank you for the offer Jonathan. I must go ahead and apologize for my rusty ability with C; I haven’t needed to use the language in years. But I will familiarize myself with the Git source and try to put a patch (or series of patches) together over the next week or two. -- ejmr 南無妙法蓮華經 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
