{"thread":{"id":"30921","subject":"can I always ignore a file during a merge?","startedAt":"2012-06-27T23:39:03Z","lastAt":"2012-07-05T19:49:04Z","messageCount":3,"participants":["Stephen Bannasch","Jeff King","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"194397","messageId":"p06240817cc114629c20f@[192.168.1.122]","threadId":"30921","inReplyTo":null,"subject":"can I always ignore a file during a merge?","fromName":"Stephen Bannasch","fromEmail":"stephen.bannasch@deanbrook.org","sentAt":"2012-06-27T23:39:03Z","receivedAt":"2012-06-27T23:39:03Z","isPatch":false,"sender":{"key":"stephen.bannasch@deanbrook.org","avatar":null},"body":"Is there a way to merge from branchA to branchB and from branchB to branchA while completely ignoring changes to a file that is \ntracked and exists in both branches?\n\n---- details ----\n\nI have two branches in my project (master and energy2d) automatically being built and tested on travis-ci:\n\n http://travis-ci.org/#!/concord-consortium/lab\n\nWhen failures in tests occur notifications are sent to emails in a configuration file checked into each branch:\n\n master:\n https://github.com/concord-consortium/lab/blob/master/.travis.yml\n\n energy2d:\n https://github.com/concord-consortium/lab/blob/energy2d/.travis.yml\n\nI regularly merge work in the energy2d branch into master and the Google Summero of Code student I am working with regularly \nmerges changes in master into energy2d.\n\nI would like to be able to merge both directions while completely ignoring changes in the travis-ci configuration files in each \nbranch.\n\nI have tried creating a .gitattributes file in each branch with the following content:\n\n .travis.yml merge=ours\n\nBut when interpreted by the default merge strategy \"recursive\" this only applies when there are conflicts -- however this \ncurrent difference is not seen as a conflict:\n\n $ git diff energy2d .travis.yml\n diff --git a/.travis.yml b/.travis.yml\n index 8ea58dc..ec89f91 100644\n --- a/.travis.yml\n +++ b/.travis.yml\n @@ -8,7 +8,8 @@ notifications:\n email:\n recipients:\n - stephen.bannasch@gmail.com\n - - janikpiotrek@gmail.com\n + - sfentress@concord.org\n + - rpk@pobox.com\n language: node_js\n node_js:\n - 0.6\n\nWhich means every time we merge the .travis.yml file is updated on the branch we are merging to.\n"},{"id":"194518","messageId":"20120703073847.GD16679@sigill.intra.peff.net","threadId":"30921","inReplyTo":"p06240817cc114629c20f@[192.168.1.122]","subject":"Re: can I always ignore a file during a merge?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-07-03T07:38:47Z","receivedAt":"2012-07-03T07:38:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 27, 2012 at 07:39:03PM -0400, Stephen Bannasch wrote:\n\n> Is there a way to merge from branchA to branchB and from branchB to\n> branchA while completely ignoring changes to a file that is tracked\n> and exists in both branches?\n\nNo. Fundamentally, a commit object in git consists of a content state\n(i.e., a pointer to a tree object) and a pointer to all previous history\n(i.e., zero or more \"parent\" pointers to commit objects). The semantics\nof a commit object can be thought of as \"I have looked at all of the\nhistory in all of the parent commits, and the state contained in my tree\npointer supersedes them all\".\n\nSo you could make merge B into A, but keep A's copy of the file (e.g.,\nusing the \"ours\" strategy). But that is saying that you considered the\nstate of both A and B, and decided that A's version supersedes what\nhappened in B. If you later wanted to merge from A to B, B's version of\nthe file would not even be considered as an outcome for the merge.\n\nThere isn't really a clever way to work around this via a different\nmerge strategy; it's a fundamental aspect of git's data structure for\nstoring history.\n\n-Peff\n"},{"id":"194669","messageId":"1E3C4BE2EAA245A9BEF11CC496E28B9E@PhilipOakley","threadId":"30921","inReplyTo":"20120703073847.GD16679@sigill.intra.peff.net","subject":"Re: can I always ignore a file during a merge?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-07-05T19:49:04Z","receivedAt":"2012-07-05T19:49:04Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" \nTo: \"Stephen Bannasch\" \nSent: Tuesday, July 03, 2012 8:38 AM\nSubject: Re: can I always ignore a file during a merge?\n\n\n> On Wed, Jun 27, 2012 at 07:39:03PM -0400, Stephen Bannasch wrote:\n>\n>> Is there a way to merge from branchA to branchB and from branchB to\n>> branchA while completely ignoring changes to a file that is tracked\n>> and exists in both branches?\n>\n> No. Fundamentally, a commit object in git consists of a content state\n> (i.e., a pointer to a tree object) and a pointer to all previous \n> history\n> (i.e., zero or more \"parent\" pointers to commit objects). The \n> semantics\n> of a commit object can be thought of as \"I have looked at all of the\n> history in all of the parent commits, and the state contained in my \n> tree\n> pointer supersedes them all\".\n>\n> So you could make merge B into A, but keep A's copy of the file (e.g.,\n> using the \"ours\" strategy). But that is saying that you considered the\n> state of both A and B, and decided that A's version supersedes what\n> happened in B. If you later wanted to merge from A to B, B's version \n> of\n> the file would not even be considered as an outcome for the merge.\n>\n> There isn't really a clever way to work around this via a different\n> merge strategy; it's a fundamental aspect of git's data structure for\n> storing history.\nStephen,\nOne thought, following too much reading of the manual, is to use the \nmerge --squash option, which leaves you with the index ready for a \ncommit, and then revert the undesired file using checkout -- , \nfollowed with git add , and if you want both merge parents set the \nMERGE_HEAD as required (see the man pages) before the final commit.\n\nPhilip\n\n>\n> -Peff\n> --\n"}]}