Jakub Narebski [off-list ref] 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".
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.
Junio C Hamano wrote:
Jakub Narebski [off-list ref] writes:
quoted
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