On Thu, 2010-10-21 at 10:44 +0200, Michael Haggerty wrote: > On 10/18/2010 11:57 PM, Jakub Narebski wrote: > > Well, there is different suggestion: make `git stage`, `git track` and > > `git mark-resolved` to be *specializations* of `git add`, with added > > safety checks: 'git stage' would work only on files known to git / > > under version control already, 'git track' would work only on > > untracked files (and do what 'git add -N' does), and 'git mark-resolved' > > would work only on files which were part of a merge conflict. > > I think that is a great idea. The thing that I found most confusing > when learning git is that variations on a single command often have very > different effects. Ok, so what will "git stage" do when a change of a file is already staged and it is executed again (on new changes)? The point of "git add" is that it is adding the current state to the index, not that it is adding a file to version control (in contrast to most other VCS/SCM). Adding a "git stage" that acts as if "git add" permanently adds a file to version control merely confuses this issue in my opinion. (Comments about checkout will come in another message, granted I come up with the time to write them down...) -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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