2

I am new in git and I am find it hard to wrap my head around the fact that everything is around snapshots/commits and not individual files.
So assume that I have a tree in my repository as follows. 

C4 (HEAD,Master,Origin/Master)  
*  
C3  
*  
C2  
*  
C1

Now I branch out from here: 

B1 (HEAD, testBranch)  
*  
C4 (HEAD,Master,Origin/Master)  
*  
C3  
*  
C2  
*  
C1

In my testBranch I only modify 2 files of the whole repository. Just 2.
The development in master in the remote repository continues so eventually we have the following tree: 

                    C8(Master,Origin/Master)   
                    *   
B3(testBranch)    C7   
  *              *   
  B2           C6  
    *         *
     B1    C5   
       *  
       C4  
       *  
       C3  
       *  
       C2  
       *  
       C1

Now I have finished working on the branch and want to merge to master. But the master has moved further ahead.
But the only difference between B3 the latest of testBranch and C8 the latest of master are the changes in the 2 files that I originally started to work on when I forked the branch. But additionally testBranch is "lest behind" the master branch since other modifications have occurred.
So what will happen if I merge testBranch to master?
Will git figure out that the only changes to merge are the 2 files I originally worked on?
Will I get conflicts? Should I not do a merge but a rebase? Why?

Cratylus
  • 52,998
  • 69
  • 209
  • 339
  • Try one of the git-branching [tutorials](http://pcottle.github.io/learnGitBranching/) out there. These are some basic questions well-covered by the [resources](http://try.github.io/levels/1/challenges/1) on the web. – Christopher Jun 17 '13 at 19:46

1 Answers1

2

I am find it hard to wrap my head around the fact that everything is around snapshots/commits and not individual files.

Did you used ClearCase before?
If yes, see this question for a difference between a file-centric VCS (here a CVCS) and a DVCS like git (that I introduce here).

So what will happen if I merge testBranch to master? Will git figure out that the only changes to merge are the 2 files I originally worked on?

yes

But how does git "understand" that the different code in the branch has been made obsolete by the code in master? Due to timestamps?

Due to the fact that each commit knows its parent: that allows to find a common ancestor commit between B3 (merged to) C8: C4.

The merge operation know what has evolved since C4: only 2 files, and it will merge only those to master.

See also "What makes merging in DVCS easy?".

The merge operation know what has evolved since C4: only 2 files, and it will merge only those to master.

But B1-C5 B2-C6 are different.
E.g. a function in C5 that exists in B1 and B2 could have been deleted.
I am not sure I understand how does it figure this out and it doesn't "reinclude" the function

It does figure out and not reintroduce that function because:

  • that function existed in C4 (common ancestor)
  • that function existed in B2 (so no change there on the source branch of the merge)
  • that function no longer exist in master (but it is a change, a deletion here, which affects the destination branch of the merge)

A merge is about reporting and merging modifications from the source branch to the destination branch.
You are referring to a modification in the destination branch only, while the source branch has not evolved compared to the common ancestor:

  • that function from testBranch will be ignored by the merge since there no modification to report.
  • that deleted function in master will be kept deleted by the merge, since the merge ignores said function from testBranch (for the reason I just mentioned in the previous point: no modification since the common ancestor)

Will I get conflicts?

You could get a conflict if those two files have also changed in master (and if those changes occurred on common lines)

Should I not do a merge but a rebase? Why?

A rebase would be better if you didn't pushed yes testBranch, and have other commits to do on it (but want to do them based on a up-to-date version of master)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • But how does `git` "understand" that the different code in the branch has been made obsolete by the code in `master`? Due to timestamps? (BTW thank you so much for helping me out) – Cratylus Jun 17 '13 at 19:48
  • @Cratylus I have edited (again) the answer in order to add links to other interesting answer about git. – VonC Jun 17 '13 at 19:54
  • `The merge operation know what has evolved since C4: only 2 files, and it will merge only those to master.` But `B1-C5` `B2-C6` are different. E.g. a function in `C5` that exists in `B1` and `B2` could have been deleted.I am not sure I understand how does it figure this out and it doesn't "reinclude" the function – Cratylus Jun 17 '13 at 19:55
  • @Cratylus I have edited the answer (ter) to address your previous comment. – VonC Jun 17 '13 at 20:03
  • 1
    @Cratylus I "own" ClearCase: http://stackoverflow.com/tags/clearcase/topusers (and git too ;) http://stackoverflow.com/tags/git/topusers) – VonC Jun 17 '13 at 20:03
  • How can you do this? I need to know your secret. – Cratylus Jun 17 '13 at 20:04
  • @Cratylus I do dev support for a living, so this is just basic daily training: https://plus.google.com/u/0/106661248019508703534/posts/EKVsiHK55cB, and https://plus.google.com/u/0/106661248019508703534/posts/B2i3GZjVru5 – VonC Jun 17 '13 at 20:06
  • Thanks a lot. I wish I could also help you out, but you are 50 years ahead of me... :) – Cratylus Jun 17 '13 at 20:09
  • @Cratylus but you are helping (you *and others*) with interesting questions on this topic :) – VonC Jun 17 '13 at 20:11