2

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 ?

WITL
  • 107
  • 1
  • 9
  • I can't understand how your question simulates rebasing – Andrew C Feb 13 '15 at 05:49
  • let's assume you cloned master branch from public remote. This branch represents a merge of 2 branches. You work on the master do a commit and attempts to push it; upon doing so you realize that some other user cloned the same master branch you did, rebased it and then did fore PUSH. Thus, after the other user's PUSH, assuming no further wirk was added, represents the same final snapshot that you cloned, but with different order of commits (i.e., linear order). My question above relates to the condition of the master branch on the remote after the push of the rebased branch. – WITL Feb 15 '15 at 03:59
  • it has the same snapshot as that which you cloned to begin with. Therefore your additional work (the aforementioned additional commit), cannot just be a fast forward commit EVEN THOUGH your work relates to a snapshot that indeed represents master as you cloned it THEN and as it is NOW in the remote. You will need to do merge with COMMITS which ALREADY exit in the current branch that you want ti push because git does not compare branches by their snapshot but by the hash which incioporates the snapshot as well as the path that lead to that snapshot – WITL Feb 15 '15 at 04:07
  • Sure, but the reverse order thing has nothing to do with it really. You'd have the exact same result if he made the changes in the same order. You'd have the exact same result if you redid the commits yourself 5 minutes later. Etc. – Andrew C Feb 15 '15 at 06:33
  • By torek's account below, the SHA-1 is different in these 2 cases --that is what I asked. You are right by saying we will have the same final result, but these 2 final results will have different hashes representing the final commit. That will require to a non fast-forward merge if we aimed to sync up the 2 branches I was eferring to in the top of this thread. – WITL Feb 16 '15 at 07:06

1 Answers1

3

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.

torek
  • 448,244
  • 59
  • 642
  • 775