Yes, "discarded" here means being undone (there are in history, but topmost commit is without changes). I think that the result is similar to having pulled changes and choosing ours
merge strategy, i.e. choosing always own version over changes.
Step by step explanation of what I think happened
When ready to publish
*---*---*---A---B <--- user's master
*---*---*---X <--- public repository master
"One user of Tortoise Git would do a pull", which is fetch...
*---*---*---A---B <--- master
\
\-X <--- origin/master (remote tracking branch)
...followed by attempted merge: "have a merge conflict"...
*---*---*---A---B---[C] <--- master
\ /
\-X------/
Now there is a bit of ambiguity:
resolve the merge conflict, and then look carefully at his list of files to be committed back when he was committing the results. There were lots of files there, and he knew that the merge conflict only involved a couple of files. For his commit, he unchecked all the other files changes that he was not involved in, committed the results and pushed the commit.
My take on it is that "resolve... and then" should read "resolved... by", i.e. that said description is how user resolved merge, and not something done as separate step. Resolving merge ends with committing it:
*---*---*---A---B----B' <--- user's master
\ /
\-X------/
where B'
is result of using ours-like merge strategy, where conflicted files were taken from user's version, replacing / forgetting changes in X
Assuming that there were no other activity in public repository, the 'master' branch in it still looks like this:
*---*---*---X <--- public repository master
and push will be fast-forward and succeed:
*---*---*---A---B----B' <--- public repository master
\ /
\-X------/
When somebody else will pull new changes, he/she would see state B'
, which do not include changes from X
because of mis-merge (incorrect manual conflict resolution).