Junio C Hamano <gitster@xxxxxxxxx> writes: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: >> David Abrahams <dave@xxxxxxxxxxxx> wrote: >>> >>> For example, why couldn't the "index" be called the "stage" instead? >>> That, along with knowing that "git add" was a synonym for "git stage" >>> would have flattened the learning curve considerably for me. >> >> Historical reasons... [...] > The way to update the cache was called "update-cache" then "update-index". > Because it usually is much rare to actually add a new entry to the index > than updating an existing entry in the index, the command had a safeguard > against "update-cache a-newfile" without explicit request from the user to > say "oh by the way I know I am adding new entries". "git add" came much > later to give you a shorthand for "update-index --add". Updating existing > entries in the index was still done with "update-index". > > Later Nico taught (after much discussion) "git add" to also serve as > "update-index" for existing entries in the index. > > We could have called it "git update-index" when we did that switch-over, > because the operation is exactly that --- updating the index. > > But the name somehow stuck. [...] It is a bit of pity that "git add" was overloaded to also add new contents and not only add new file (and its contents!), instead of having new command "git stage" to be porcelain version of "git update-index" porcelain. And perhaps "git resolved" to only mark resolved entries (so e.g. "git resolved ." would not add new files, nor add new contents of files which were not in conflict). Now we have to explain that "git add" adds new contents... OTOH it is perhaps good idea to emphasize differences between Git and other lesser^W SCMs. ;-) And introduce "git add -N"... -- Jakub Narebski Poland ShadeHawk on #git -- 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
