The following is a hypothetical scenario meant to get better understanding about the danger of rebasing
User A makes 2 commits. He first add (stage) a text file to root directory with the word "Hello", commits it, then adds another file to same root directory with the word "world", then commits that file. Thus his final commit corresponds to a root directory with 2 files. One with the single word "Hello" and another with a single word "World"
User B does the same things and ends up with the same 2 files in his git root project, ONLY THAT HE DOES IT IN REVERSE ORDER: he first adds the file with the word "world", commits it, and then adds the file with the word "hello" and commits it.
Finally, let's assume user A pushed his project to remote repository, and then user B created a tracking branch and fetched the project that user A pushed as a branch. Given that scenario, my question -- which really attempts to simulate rebasing and hone my understanding about the perils of rebasing in virtue of that question -- is whether user B will need to merge with the branch associated with whatever user A pushed to the remote repository ?
Per what I read and understood, user A and user B's sha hash with repect to their final commit will be different and therefore will require merging, assuming that they both desire to continue their "development" work knowing that they are in sync. Am I correct ?
You are correct, the SHA-1 records the path (the entire ancestry chain, more or less) and git determines what commit(s) must be incorporated based on the commit nodes (the DAG with its raw SHA-1s).
If they actually merge (or one rebases his stuff on the other's while throwing out any "unneeded" commits), the merge will turn out to be easy after all, since that depends on file contents—or more specifically, the diff from the merge-base to each tip commit. Any resulting merge commit (as long as it's picked up by both users) will put their graphs in sync since new commits will have that new merge commit as their parent-ID.