{"thread":{"id":"10105","subject":"merging .gitignore","startedAt":"2007-10-01T13:03:14Z","lastAt":"2007-10-03T19:38:56Z","messageCount":20,"participants":["martin f krafft","Andy Parkins","Johannes Schindelin","Junio C Hamano","Pierre Habouzit","Johan Herland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"54482","messageId":"20071001130314.GA5932@lapse.madduck.net","threadId":"10105","inReplyTo":null,"subject":"merging .gitignore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-01T13:03:14Z","receivedAt":"2007-10-01T13:03:14Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Dear gits (oh dear…),\n\nwe just ran into a problem in a git-managed project and I'd be\ninterested to learn how you approach this.\n\nOur main line (\"upstream\"), which tracks a remote repository, does\nnot have a .gitignore file. For new features, we use feature\nbranches, and we merge those into an integration branch (\"master\")\nand track them separately of upstream.\n\nFeature branch A has a .gitignore file, and it's been merged into\nmaster for a while. Today, feature branch B failed to merge into\nmaster because it also provides a .gitignore file. We can obviously\nresolve the conflict, but I wonder whether there is a better way to\ndeal with this since we deal with quite a large number of new\nfeature branches and it's only a matter of time until the next one\nwill conflict because of .gitignore.\n\n(and yes, this is basically a reincarnation of my case for\n.gitignore.d [http://lists.zerezo.com/git/msg627581.html]).\n\nThoughts,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nkermit: why are there so many songs about rainbows?\nfozzy: that's part of what rainbows do.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54486","messageId":"200710011448.17701.andyparkins@gmail.com","threadId":"10105","inReplyTo":"20071001130314.GA5932@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-10-01T13:48:16Z","receivedAt":"2007-10-01T13:48:16Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 October 01, martin f krafft wrote:\n\n> Feature branch A has a .gitignore file, and it's been merged into\n> master for a while. Today, feature branch B failed to merge into\n> master because it also provides a .gitignore file. We can obviously\n> resolve the conflict, but I wonder whether there is a better way to\n> deal with this since we deal with quite a large number of new\n> feature branches and it's only a matter of time until the next one\n> will conflict because of .gitignore.\n\nBut it _is_ a conflict. Conflicts have to be resolved. I'm having difficulty \nunderstanding what you think git should be doing in these cases?\n\n> (and yes, this is basically a reincarnation of my case for\n> .gitignore.d [http://lists.zerezo.com/git/msg627581.html]).\n\nI don't see that that would help. All you are doing with a gitignore.d is \nswapping lines for files, the conflicts would still exist. Presumably you \nare hoping that the separate branches will make different files in \ngitignore.d and hence can't conflict; but then you've just pushed the \nconflict to a place where it won't be seen (and also made a terrible mess of \nthe merged branch gitignore.d).\n\n branchA:.gitignore.d/branchAignores\n branchB:.gitignore.d/branchBignores\n\nOver time you would get:\n\n master:.gitignore.d/branchAignores\n master:.gitignore.d/branchBignores\n master:.gitignore.d/branchCignores\n master:.gitignore.d/branchDignores\n master:.gitignore.d/branchEignores\n master:.gitignore.d/branchFignores\n\nThen, assuming the conflicts you get now occur for a reason, you will get \nconflicts within the .gitignore.d/ directory. Let's say branchCignores adds \n*.o and branchFignores removes *.o from the ignores. Who is right? Who \nknows, and worse than that you didn't see the conflict when it happened so it \nwasn't resolved and the master branch was left with conflicts in it.\n\nOf course the conflicts in that case aren't in the form of \"<<<<<\" markers, \nbut they are no less conflicts just because they're invisible.\n\nEventually someone is going to want to combine this ever-increasing set of \nignore files into one. i.e. they'll merge them. In which case why couldn't \nyou do the merge at the correct time - when the branch was merged?\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"54487","messageId":"Pine.LNX.4.64.0710011457120.28395@racer.site","threadId":"10105","inReplyTo":"20071001130314.GA5932@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-01T13:57:52Z","receivedAt":"2007-10-01T13:57:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 1 Oct 2007, martin f krafft wrote:\n\n> Feature branch A has a .gitignore file, and it's been merged into\n> master for a while. Today, feature branch B failed to merge into\n> master because it also provides a .gitignore file.\n\nYou might be interested in writing a merge driver. See \nDocumentation/gitattributes.txt.\n\nHth,\nDscho\n"},{"id":"54587","messageId":"20071002195148.GA14171@lapse.madduck.net","threadId":"10105","inReplyTo":"Pine.LNX.4.64.0710011457120.28395@racer.site","subject":"Re: merging .gitignore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-02T19:51:48Z","receivedAt":"2007-10-02T19:51:48Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Johannes Schindelin [2007.10.01.1457 +0100]:\n> You might be interested in writing a merge driver. See \n> Documentation/gitattributes.txt.\n\nThis is an excellent idea; thanks.\n\n\n\nalso sprach Andy Parkins [2007.10.01.1448 +0100]:\n> Then, assuming the conflicts you get now occur for a reason, you\n> will get conflicts within the .gitignore.d/ directory. Let's say\n> branchCignores adds *.o and branchFignores removes *.o from the\n> ignores. Who is right? Who knows, and worse than that you didn't\n> see the conflict when it happened so it wasn't resolved and the\n> master branch was left with conflicts in it.\n\nWell, with gitignore I am ready to say that merges should be\nresolved in an additive way. Remember that I am talking about an\nintergration branch, and if feature branches A and B used to ignore\n.o files, and now B suddenly does not ignore them anymore, the only\nreal reason I can think of is that it was rewritten in a languages\nother than C*. So then you *still* want to ignore .o files in the\nintegration branch.\n\nBasically I am saying that it should be\n\n cat $gitignore_files | sort -u\n\nand obviously, this is something for a specific merge driver, as\nJohannes suggested.\n\nThanks for the feedback,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \nminchinhampton (n.): the expression on a man's face when he has just\nzipped up his trousers without due care and attention.\n -- douglas adams, the meaning of liff\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54589","messageId":"7vodfhjnpe.fsf@gitster.siamese.dyndns.org","threadId":"10105","inReplyTo":"20071002195148.GA14171@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-02T19:55:41Z","receivedAt":"2007-10-02T19:55:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"martin f krafft writes:\n\n> Basically I am saying that it should be\n>\n> cat $gitignore_files | sort -u\n>\n> and obviously, this is something for a specific merge driver, as\n> Johannes suggested.\n\nPerhaps you can use the existing union merge there.\n"},{"id":"54593","messageId":"20071002201318.GD16776@artemis.corp","threadId":"10105","inReplyTo":"20071002195148.GA14171@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-02T20:13:18Z","receivedAt":"2007-10-02T20:13:18Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Oct 02, 2007 at 07:51:48PM +0000, martin f krafft wrote:\n> Well, with gitignore I am ready to say that merges should be\n> resolved in an additive way. Remember that I am talking about an\n> intergration branch, and if feature branches A and B used to ignore\n> .o files, and now B suddenly does not ignore them anymore, the only\n> real reason I can think of is that it was rewritten in a languages\n> other than C*. So then you *still* want to ignore .o files in the\n> integration branch.\n> \n> Basically I am saying that it should be\n> \n> cat $gitignore_files | sort -u\n\n Except that this would not work, just take that example (for the sake\nof conciseness I put lines as members of a set):\n\n\n Common ancestor content: (bar, foo, quux)\n Left child: (bar, baz, foo, quux)\n Right child: (bar, quux)\n\n This one is a conflict, and if you apply your method, the merge always\n\"works\" (as in has no cases where it fails) and would yield a result\nlike:\n\n (bar, baz, foo, quux) whereas it's probably (bar, baz, quux) that\nwould be the proper one (aka left branch added a new ignore `baz` and\nthe right one removed it).\n\n The proper way for gitignore is probably to work on the sets\noperations, like diff does with lines, but without taking ordering into\naccount. What gets harder is when your lists are:\n\n Ancestor: (aa*, aaa, bbb)\n Left child: (aa*, bbb) <-- remove aaa because aa* covers it\n Right child: (aaa, aabcd, bbb, cc*) <-- remove aa* and be explicit\n\n The proper result is probably: (aaa, aabcd, bbb, cc*) but is in fact a\ncase of conflict, because the \"left\" child could have used the fact that\naa* was present and hide say a aaXXX that the right child did not had,\nand the merge would be wrong.\n\n Of course, .gitignore aren't _that_ important and if you ignore one\nless file, or one too many, git will continue to behave properly, but\nwell, merge implementations aren't _that_ trivial.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54596","messageId":"20071002202023.GA16010@lapse.madduck.net","threadId":"10105","inReplyTo":"7vodfhjnpe.fsf@gitster.siamese.dyndns.org","subject":"Re: merging .gitignore","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-10-02T20:20:23Z","receivedAt":"2007-10-02T20:20:23Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Junio C Hamano [2007.10.02.2055 +0100]:\n> Perhaps you can use the existing union merge there.\n\nMany thanks for the pointer, I did not even have time to look at\ngitattributes.txt yet...\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"self-denial is the shining sore\n on the leprous body of christianity.\"\n -- oscar wilde\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"54600","messageId":"20071002204748.GA19710@artemis.corp","threadId":"10105","inReplyTo":"20071002201318.GD16776@artemis.corp","subject":"Re: merging .gitignore","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-02T20:47:48Z","receivedAt":"2007-10-02T20:47:48Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On mar, oct 02, 2007 at 08:13:18 +0000, Pierre Habouzit wrote:\n> Ancestor: (aa*, aaa, bbb)\n> Left child: (aa*, bbb) <-- remove aaa because aa* covers it\n> Right child: (aaa, aabcd, bbb, cc*) <-- remove aa* and be explicit\n> \n> The proper result is probably: (aaa, aabcd, bbb, cc*) but is in fact a\n> case of conflict, because the \"left\" child could have used the fact that\n> aa* was present and hide say a aaXXX that the right child did not had,\n> and the merge would be wrong.\n\n Okay this example blows, I believe this one is better:\n\n (a*)\n / \\\n (ab*) (ac*)\n \\ /\n ????\n\n gitignore are subsets of the set of words. if S is the ancestor set,\nS1 and S2 the left and right sets. let Δ1 and Δ2 be S1 \\ S and S2 \\ S\nrespectively. I think there is a conflict if\n Δ1 n Δ2 != 0 and (Δ1 is not a subset of Δ2) and (Δ2 is not a subset of Δ1)\n\n If the condition holds, then I believe that the \"merged\" .gitignore\nwould be: (S1 u S2) \\ (Δ1 u Δ2)\n\n Though, don't take my word for it, I've only sketched this on a small\npiece of paper, and have no rigorous proof.\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54603","messageId":"20071002205618.GA19097@lapse.madduck.net","threadId":"10105","inReplyTo":"20071002204748.GA19710@artemis.corp","subject":"Re: merging .gitignore","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2007-10-02T20:56:18Z","receivedAt":"2007-10-02T20:56:18Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"also sprach Pierre Habouzit [2007.10.02.2147 +0100]:\n> (a*)\n> / \\\n> (ab*) (ac*)\n> \\ /\n> ????\n\n(a*, ab*, ac*)\n\n-- \n .''`. martin f. krafft \n: :' : proud Debian developer, author, administrator, and user\n`. `'` http://people.debian.org/~madduck - http://debiansystem.info\n `- Debian - when you have better things to do than fixing systems\n \n\"once ... in the wilds of afghanistan, i lost my corkscrew, and we\n were forced to live on nothing but food and water for days.\"\n -- w. c. fields, \"my little chickadee\"\n"},{"id":"54607","messageId":"20071002210252.GB19710@artemis.corp","threadId":"10105","inReplyTo":"20071002204748.GA19710@artemis.corp","subject":"Re: merging .gitignore","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-02T21:02:52Z","receivedAt":"2007-10-02T21:02:52Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Oct 02, 2007 at 08:47:48PM +0000, Pierre Habouzit wrote:\n> On mar, oct 02, 2007 at 08:13:18 +0000, Pierre Habouzit wrote:\n> > Ancestor: (aa*, aaa, bbb)\n> > Left child: (aa*, bbb) <-- remove aaa because aa* covers it\n> > Right child: (aaa, aabcd, bbb, cc*) <-- remove aa* and be explicit\n> > \n> > The proper result is probably: (aaa, aabcd, bbb, cc*) but is in fact a\n> > case of conflict, because the \"left\" child could have used the fact that\n> > aa* was present and hide say a aaXXX that the right child did not had,\n> > and the merge would be wrong.\n> \n> Okay this example blows, I believe this one is better:\n> \n> (a*)\n> / \\\n> (ab*) (ac*)\n> \\ /\n> ????\n> \n> gitignore are subsets of the set of words. if S is the ancestor set,\n> S1 and S2 the left and right sets. let Δ1 and Δ2 be S1 \\ S and S2 \\ S\n I meant S \\ S1 and S \\ S2 in fact here ...\n> respectively. I think there is a conflict if\n> Δ1 n Δ2 != 0 and (Δ1 is not a subset of Δ2) and (Δ2 is not a subset of Δ1)\n> \n> If the condition holds, then I believe that the \"merged\" .gitignore\n> would be: (S1 u S2) \\ (Δ1 u Δ2)\n\n after some more thoughts, as basically merging the complementary of\nthe sets I talk about here should yield the same \"conflicts\" (as it's\nthe dual problem), I suppose that the same restrictions should be\nchecked wrt the \"added\" deltas between S -> S1 (aka S1 \\ S for real this\ntime) and S -> S2 (aka S2 \\ S).\n\n so if Δ(0,n) is Sn \\ S and Δ(n, 0) is S \\ Sn, it would mean that if:\n\n { Δ(0,1) n Δ(0,2) == 0 || ∃ i ∋ (1,2), Δ(0,i) ⊆ Δ(0, 3 - i) }\n&& { Δ(1,0) n Δ(2,0) == 0 || ∃ i ∋ (1,2), Δ(i,0) ⊆ Δ(3 - i, 0) }\n\n Then the correct merge (without conflicts) would be:\n\n (S u Δ(1,0) u Δ(2,0)) \\ (Δ(0,1) u Δ(0,2)) aka S + what was added -\nwhat was removed.\n\n in fact, I think that wrt the sets usual operations, there is a\nconflict if the expression I just wrote does not commutes wrt the \\ or\nsth very similar.\n\n Anyway, I'm going pretty off topic here, so I'll shut up now :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54609","messageId":"20071002210748.GC19710@artemis.corp","threadId":"10105","inReplyTo":"20071002205618.GA19097@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-02T21:07:48Z","receivedAt":"2007-10-02T21:07:48Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Oct 02, 2007 at 08:56:18PM +0000, martin f krafft wrote:\n> also sprach Pierre Habouzit [2007.10.02.2147 +0100]:\n> > (a*)\n> > / \\\n> > (ab*) (ac*)\n> > \\ /\n> > ????\n> \n> (a*, ab*, ac*)\n\n Definitely not. a* -> ab* is making a?* unignored for any value of ?\nexcept b. So adding a* is definitely invalid.\n\n So your final merge is definitely invalid. I'd say that it's likely\nthat the final merge is (ab*, ac*) but on the left branch the ab* could\nhave been chosen because the programmer added a thing named ac.c, so the\nmerge would still have (probably little but still some) chances to be invalid.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54615","messageId":"20071002214919.GA21260@lapse.madduck.net","threadId":"10105","inReplyTo":"20071002210748.GC19710@artemis.corp","subject":"Re: merging .gitignore","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2007-10-02T21:49:19Z","receivedAt":"2007-10-02T21:49:19Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"also sprach Pierre Habouzit [2007.10.02.2207 +0100]:\n> > > (a*)\n> > > / \\\n> > > (ab*) (ac*)\n> > > \\ /\n> > > ????\n> > \n> > (a*, ab*, ac*)\n> \n> Definitely not. a* -> ab* is making a?* unignored for any value of ?\n> except b. So adding a* is definitely invalid.\n\nIn left, ab* is still ignored, in right ac* is still ignored, and in\nthe integration branch, they're all ignored. We don't merge up in\nthis model...\n\n-- \n .''`. martin f. krafft \n: :' : proud Debian developer, author, administrator, and user\n`. `'` http://people.debian.org/~madduck - http://debiansystem.info\n `- Debian - when you have better things to do than fixing systems\n \n\"if there's anything more important than my ego,\n i want it caught and shot now.\"\n -- zaphod beeblebrox\n"},{"id":"54618","messageId":"20071002220749.GE19710@artemis.corp","threadId":"10105","inReplyTo":"20071002214919.GA21260@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-02T22:07:49Z","receivedAt":"2007-10-02T22:07:49Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Oct 02, 2007 at 09:49:19PM +0000, martin f krafft wrote:\n> also sprach Pierre Habouzit [2007.10.02.2207 +0100]:\n> > > > (a*)\n> > > > / \\\n> > > > (ab*) (ac*)\n> > > > \\ /\n> > > > ????\n> > > \n> > > (a*, ab*, ac*)\n> > \n> > Definitely not. a* -> ab* is making a?* unignored for any value of ?\n> > except b. So adding a* is definitely invalid.\n> \n> In left, ab* is still ignored, in right ac* is still ignored, and in\n> the integration branch, they're all ignored. We don't merge up in\n> this model...\n\n err maybe you didn't get my little picture\n\n (a*)\n / \\\n v v\n(ab*) (ac*)\n \\ /\n v v\n ????\n\n This is a perfectly sensible history. Or I miss sth on your end.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54675","messageId":"200710030923.22767.andyparkins@gmail.com","threadId":"10105","inReplyTo":"20071002195148.GA14171@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-10-03T08:23:20Z","receivedAt":"2007-10-03T08:23:20Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 October 02, martin f krafft wrote:\n\n> Well, with gitignore I am ready to say that merges should be\n> resolved in an additive way. Remember that I am talking about an\n> intergration branch, and if feature branches A and B used to ignore\n> .o files, and now B suddenly does not ignore them anymore, the only\n\nOkay; *.o was obviously not a good example. A more detailed one: how about a \nchange like this to a makefile (excuse bastardised diff format)\n\ndiff Makefile\n-include depends.make\n+include depends.mak\n\ndiff .gitignore\n-depends.make\n+depends.mak\n\n> cat $gitignore_files | sort -u\n\nNow, say there is another branch that makes exactly this change but \nchooses \"depends.inc\" as the filename. Your \"additive only\" merge \nof .gitignore will not flag the conflict and will leave a .gitignore with\n\ndepends.mak\ndepends.inc\n\nThe makefile conflict will have been resolved one way or the other but the \ngitignore conflict will not. While it's not a serious fault it is wrong, and \nno one was signalled that it was wrong.\n\nI am still having difficult seeing why you want to hide conflicts \nin .gitignore. It's just as possible to get and resolve conflicts in \ngitignore as in any other file.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"54680","messageId":"20071003084259.GA25838@lapse.madduck.net","threadId":"10105","inReplyTo":"20071002220749.GE19710@artemis.corp","subject":"Re: merging .gitignore","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2007-10-03T08:42:59Z","receivedAt":"2007-10-03T08:42:59Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"also sprach Pierre Habouzit [2007.10.02.2307 +0100]:\n> (a*)\n> / \\\n> v v\n> (ab*) (ac*)\n> \\ /\n> v v\n> ????\n> \n> This is a perfectly sensible history. Or I miss sth on your end.\n\nSo these are revs, not branches?\n\n-- \n .''`. martin f. krafft \n: :' : proud Debian developer, author, administrator, and user\n`. `'` http://people.debian.org/~madduck - http://debiansystem.info\n `- Debian - when you have better things to do than fixing systems\n \nseen on an advertising for an elaborate swiss men's watch:\n \"almost as complicated as a woman. except it's on time\"\n"},{"id":"54682","messageId":"20071003085845.GB12042@artemis.corp","threadId":"10105","inReplyTo":"20071003084259.GA25838@lapse.madduck.net","subject":"Re: merging .gitignore","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-03T08:58:45Z","receivedAt":"2007-10-03T08:58:45Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Wed, Oct 03, 2007 at 08:42:59AM +0000, martin f krafft wrote:\n> also sprach Pierre Habouzit [2007.10.02.2307 +0100]:\n> > (a*)\n> > / \\\n> > v v\n> > (ab*) (ac*)\n> > \\ /\n> > v v\n> > ????\n> > \n> > This is a perfectly sensible history. Or I miss sth on your end.\n> \n> So these are revs, not branches?\n\n Yes, those are the contents of the .gitignores on refs, on top is the\ncommon ancestor, and you have two branches that you want to merge into\none. I pretend that if in one branch the content of the .gitignore was\na* and becomes ab* and than on the other it was a* and became ac*, then\nyou cannot know how to merge.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"54685","messageId":"200710031128.56472.johan@herland.net","threadId":"10105","inReplyTo":"200710030923.22767.andyparkins@gmail.com","subject":"Re: merging .gitignore","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-10-03T09:28:56Z","receivedAt":"2007-10-03T09:28:56Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 03 October 2007, Andy Parkins wrote:\n> I am still having difficult seeing why you want to hide conflicts \n> in .gitignore. It's just as possible to get and resolve conflicts in \n> gitignore as in any other file.\n\nAgreed. What about the following:\n\n- No special merge rules for .gitignore\n\n- Teach the .gitignore parser to ignore conflict markers (i.e. regard them \nas comments)\n\n\nThis way, the user will have to merge .gitignore like any other file, but if \nfor some reason, the user is not able to do so (say, git needs to \nconsult .gitignore before the user has had a chance to resolve the \nconflict), the fallback result will be similar to a union merge, which \nshouldn't be extremely harmful in .gitignore's case.\n\nI do not think we really want to create an auto-merge algorithm \nfor .gitignore, and then depend on this auto-merge algorithm to _always_ \nsucceed with the _correct_ result and _no_ conflicts. These algorithms tend \nto be extremely tricky to get right, especially for the \"always correct\" \nrequirement.\n\n\nMercurial had a similar problem some months ago. They have their tag \ndefinitions stored in a versioned file in the working tree (.hgtags IIRC). \nBut the repo tag state (i.e. Mercurial's opinion at any time as to _which_ \ntags are defined and _where_ they point) is not deduced from the copy in \nyour current working tree at all. (That would of course limit you to only \nba able to refer to tags defined earlier on the particular branch you're \ncurrently on.) Instead the repo tag state was found by consulting \nthe \"head-most\" copy of the .hgtags file (for some definition \nof \"head-most\" including non-obvious things like which branch has the most \nrecent commit, etc). The end result was that you could get some _really_ \ninteresting behaviour depending on the order in which you commited totally \nunrelated changes to two different branches which happened to have \ndifferent .hgtags files. (E.g.: Given two branches A, B, and - in .hgtags \non branch A - tag Foo is defined to point at rev X, and - in .hgtags on \nbranch B - Foo points at rev Y. Now, whether you got rev X or rev Y when \nyou checked out Foo, depended on which of branch A or branch B had the most \nrecent (totally unrelated, i.e. not even touching .hgtags) commit.)\n\nI (and others) pointed out this bug on their ML, and instead of fixing the \nbraindeadness of allowing branched tag definitions in the repo in the first \nplace, they set about trying to create an auto-merge algorithm for deducing \nthe repo tag state from the various versions/branches of .hgtags found in \nthe repo. I didn't stick around for long enough to see how well this \nauto-merge algorithm works (the misdesign of tags in Mercurial was one of \nthe reasons I started looking at git), but I would be surprised if \nMercurial today has a simple and straightforward way of deducing the repo \ntag state that _always_ gives _correct_ (i.e. unsurprising) results, even \nin the corner cases.\n\n\n\nHave fun! :)\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"54704","messageId":"Pine.LNX.4.64.0710031314530.28395@racer.site","threadId":"10105","inReplyTo":"200710031128.56472.johan@herland.net","subject":"Re: merging .gitignore","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-03T12:41:23Z","receivedAt":"2007-10-03T12:41:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 3 Oct 2007, Johan Herland wrote:\n\n> - Teach the .gitignore parser to ignore conflict markers (i.e. regard them \n> as comments)\n\nYou might be delighted to know that in practice, it works already (because \nyou usually do not have a file named \"<<<<<< blablub\" or \"======\" or \n\">>>>>> blablub\"...\n\nCiao,\nDscho\n"},{"id":"54705","messageId":"200710031506.23938.johan@herland.net","threadId":"10105","inReplyTo":"Pine.LNX.4.64.0710031314530.28395@racer.site","subject":"Re: merging .gitignore","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-10-03T13:06:23Z","receivedAt":"2007-10-03T13:06:23Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 03 October 2007, Johannes Schindelin wrote:\n> On Wed, 3 Oct 2007, Johan Herland wrote:\n> > - Teach the .gitignore parser to ignore conflict markers (i.e. regard them \n> > as comments)\n> \n> You might be delighted to know that in practice, it works already (because \n> you usually do not have a file named \"<<<<<< blablub\" or \"======\" or \n> \">>>>>> blablub\"...\n\nI suspected so... ;)\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"54741","messageId":"7vejgcdm3z.fsf@gitster.siamese.dyndns.org","threadId":"10105","inReplyTo":"200710031506.23938.johan@herland.net","subject":"Re: merging .gitignore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-03T19:38:56Z","receivedAt":"2007-10-03T19:38:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> On Wednesday 03 October 2007, Johannes Schindelin wrote:\n>> On Wed, 3 Oct 2007, Johan Herland wrote:\n>> > - Teach the .gitignore parser to ignore conflict markers (i.e. regard them \n>> > as comments)\n>> \n>> You might be delighted to know that in practice, it works already (because \n>> you usually do not have a file named \"<<<<<< blablub\" or \"======\" or \n>> \">>>>>> blablub\"...\n>\n> I suspected so... ;)\n\nYeah, and that is one of the reasons why we made gitignore and\ngitattributes one-entry-per-line format.\n"}]}