query regarding git merge

query regarding git merge

[rohit gupta]

Hi,
I am confused with git merge working.

Suppose I have these 3 files in master branch-
a.txt
b.txt
d.txt

I create a branch, add c.txt to it and commit. So its final contents 
are-
a.txt
b.txt
c.txt
d.txt

Then, I checkout master branch, delete a.txt, add e.txt and commit. So 
final contents are-
b.txt
d.txt
e.txt

Now when I merge branch in master,
its result is-
b.txt
c.txt
d.txt
e.txt

Now suppose in branch, a.txt was needed for its working. And in master 
branch's latest commit a.txt was removed because maybe it wasn't needed 
or it was introducing bugs.
Now, git merge removes that a.txt
So now branch functionality wouldn't work. 
Isn't that wrong??

Re: query regarding git merge

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Sun, Dec 13, 2015 at 05:55:59PM +0000, rohit gupta wrote:
> Hi,
> I am confused with git merge working.
> 
> Suppose I have these 3 files in master branch-
> a.txt
> b.txt
> d.txt
> 
> I create a branch, add c.txt to it and commit. So its final contents
> are-
> a.txt
> b.txt
> c.txt
> d.txt
> 
> Then, I checkout master branch, delete a.txt, add e.txt and commit. So
> final contents are-
> b.txt
> d.txt
> e.txt
> 
> Now when I merge branch in master,
> its result is-
> b.txt
> c.txt
> d.txt
> e.txt
> 
> Now suppose in branch, a.txt was needed for its working. And in master
> branch's latest commit a.txt was removed because maybe it wasn't needed
> or it was introducing bugs.
> Now, git merge removes that a.txt
> So now branch functionality wouldn't work.
> Isn't that wrong??

Instead of thinking of Git as merging two sets of files, think of it as
merging two sets of changes.  Git computes a merge base based on one or
more ancestors of both branches.  During a merge, Git takes the
differences on each side and combines them.  Logically, if a change is
made on one side but not the other, it will be preserved in the merge.

So in your case, you deleted a.txt on one side and did not modify it on
the other.  Git applied that change to the result of the merge.  Git has
no way of knowing that a.txt is still required in the result.

This is a very common question that comes up in a variety of different
forms.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: query regarding git merge

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

[Please don't top-post.]

On Mon, Dec 14, 2015 at 12:03:18AM +0530, Rohit Gupta wrote:
> Thanks brian. I understood my mistake in understanding the working of git
> merge.
> But isn't it wrong? As after merging, branch's logic can't work. How to get
> that right then ?

If you know that the merge didn't go the way you wanted, you can either
add a follow-up commit, or you can do "git commit --amend" on the merge
after making the necessary changes.  In such a case, it may be useful to
add a note to the commit message stating that you modified it from the
original merge.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: query regarding git merge

[Jeff King]

On Sun, Dec 13, 2015 at 07:23:17PM +0000, brian m. carlson wrote:

> On Mon, Dec 14, 2015 at 12:03:18AM +0530, Rohit Gupta wrote:
> > Thanks brian. I understood my mistake in understanding the working of git
> > merge.
> > But isn't it wrong? As after merging, branch's logic can't work. How to get
> > that right then ?
> 
> If you know that the merge didn't go the way you wanted, you can either
> add a follow-up commit, or you can do "git commit --amend" on the merge
> after making the necessary changes.  In such a case, it may be useful to
> add a note to the commit message stating that you modified it from the
> original merge.

And a fundamental takeaway here is that git-merge can only find
_textual_ conflicts. It is up to the user to determine that the merge
didn't introduce any _semantic_ conflicts. For example, by building and
testing the result, which is out of git's scope.

-Peff