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

From: Philip Oakley <philipoakley@iee.org>
Date: Jul 5, 2012, 19:49 UTC
Message-ID: <1E3C4BE2EAA245A9BEF11CC496E28B9E@PhilipOakley>
In-Reply-To: <20120703073847.GD16679@sigill.intra.peff.net>

From: "Jeff King" <peff@peff.net>
To: "Stephen Bannasch" <stephen.bannasch@deanbrook.org>
Sent: Tuesday, July 03, 2012 8:38 AM
Subject: Re: can I always ignore a file during a merge?

Show 26 quoted lines

> On Wed, Jun 27, 2012 at 07:39:03PM -0400, Stephen Bannasch wrote:
>
>> 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
> --