Re: can I always ignore a file during a merge?

From: "Jeff King" <redacted>
To: "Stephen Bannasch" <redacted>
Sent: Tuesday, July 03, 2012 8:38 AM
Subject: Re: can I always ignore a file during a merge?

On Wed, Jun 27, 2012 at 07:39:03PM -0400, Stephen Bannasch wrote:

quoted

Is there a way to merge from branchA to branchB and from branchB to
branchA while completely ignoring changes to a file that is tracked
and exists in both branches?

No. Fundamentally, a commit object in git consists of a content state
(i.e., a pointer to a tree object) and a pointer to all previous 
history
(i.e., zero or more "parent" pointers to commit objects). The 
semantics
of a commit object can be thought of as "I have looked at all of the
history in all of the parent commits, and the state contained in my 
tree
pointer supersedes them all".

So you could make merge B into A, but keep A's copy of the file (e.g.,
using the "ours" strategy). But that is saying that you considered the
state of both A and B, and decided that A's version supersedes what
happened in B. If you later wanted to merge from A to B, B's version 
of
the file would not even be considered as an outcome for the merge.

There isn't really a clever way to work around this via a different
merge strategy; it's a fundamental aspect of git's data structure for
storing history.

Stephen,
One thought, following too much reading of the manual,  is to use the 
merge --squash option, which leaves you with the index ready for a 
commit, and then revert the undesired file using checkout -- <file>, 
followed with git add <file>, and if you want both merge parents set the 
MERGE_HEAD as required (see the man pages) before the final commit.

Philip

-Peff
--