On Thu, 2010-10-21 at 14:31 +0200, Thore Husfeldt wrote: > On 21 Oct 2010, at 13:20, Drew Northup wrote: > > > Ok, so what will "git stage" do when a change of a file is already > > staged and it is executed again (on new changes)? > > Presumably what it already does: nothing. But one could argue that the more public-relations minded command âgit stageâ should give better feedback. Like so: > > > $ git commit > > $ ... edit A.txt ... > > $ git stage B.txt > > git stage: Did nothing. No uncommitted changes to stage in B.txt. > > $ git stage A.txt > > $ git stage A.txt > > git stage: Did nothing. Changes in A.txt already staged. Use `git diff --staged A.txt` to see them. That's not what I asked. $ git commit $ vim A.txt $ vim B.txt $ git add B.txt $ git add A.txt $ vim B.txt $ git add B.txt The above sequence stages two changes on B.txt into the index. Literally, it adds changes to git's knowledge about B.txt twice, but does not yet commit any of it permanently to the object store. Presumably, assuming that A.txt and B.txt did not yet exist, you are suggesting the following command sequence: $ git commit $ vim A.txt $ vim B.txt $ git add B.txt $ git add A.txt $ vim B.txt $ git stage B.txt $ vim B.txt $ git stage B.txt This assumes that git SHOULD act like subversion, and I argue that there is no reason that it should. What happens if we continue as follows: $ vim A.txt $ git stage A.txt $ git commit $ vim C.txt $ vim A.txt $ git stage A.txt $ git stage C.txt Should the last two commands fail? The earlier discussion seems to suggest that they should. My point is that this does not seem to me to be a useful extension of the idiom. If anything, it seems to confuse the matter. Now, if "git stage" were an outright replacement for "git add" there might be more use (but I'd still not be happy about the corruption of the idiom). -- -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