Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: > > > 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). > > I do not think so. > > People who are taught with various means (including "git stage" alias) > understand that you prepare the contents you want to record in the commit > you are about to make by updating the contents registered in the index aka > staging area, then you do not need "git resolved". "Who are taught". This makes for Git to be more "user selective". Not that this matter much, as world domination is not our goal ;-) > You resolve, you have the desired content in your work tree, and you > register the updated contents from your work tree to the index aka staging > area, in exactly the same way as you do when you want to include updated > contents for any commit. While I don't think that "git resolved" is something really needed, the difference is with "git add ." and "git resolved ." and between "git add *" and "git resolved *", where the latter would update only resolved merge conflict resolutions, and would not pick up independent changes to the files that were not in conflict. BTW with "git add" way you have to know that "git add"-ing a file would clear 'is in merge conflict' flags (well, will hide >0 stages...). -- Jakub Narebski Poland -- 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
