{"thread":{"id":"1674","subject":"Comments in read-tree about #nALT","startedAt":"2005-08-27T06:07:17Z","lastAt":"2005-08-30T00:58:10Z","messageCount":12,"participants":["Daniel Barkalow","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7837","messageId":"Pine.LNX.4.63.0508270151590.23242@iabervon.org","threadId":"1674","inReplyTo":null,"subject":"Comments in read-tree about #nALT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-27T06:07:17Z","receivedAt":"2005-08-27T06:07:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"I've gotten to the point of having all of the entries for a given path\nready to put into the cache at the same, and now I want to convert the\nmerge functions to take their data directly, rather than in the cache, so\nthat they can take extra entries for extra ancestors.\n\nPart of threeway_merge, however, wants to search the rest of the cache for\ninterfering entries in some cases, which would have to happen differently,\nbecause I won't have the cache completely filled out beforehand. I'm\ntrying to figure out what the comments are talking about, and they seem to\nrefer to a list of the possible cases. Is that list somewhere convenient?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7840","messageId":"7vwtm726xq.fsf@assigned-by-dhcp.cox.net","threadId":"1674","inReplyTo":"Pine.LNX.4.63.0508270151590.23242@iabervon.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-27T07:08:17Z","receivedAt":"2005-08-27T07:08:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> Part of threeway_merge, however, wants to search the rest of the cache for\n> interfering entries in some cases, which would have to happen differently,\n> because I won't have the cache completely filled out beforehand. I'm\n> trying to figure out what the comments are talking about, and they seem to\n> refer to a list of the possible cases. Is that list somewhere convenient?\n\nPlease look for END_OF_CASE_TABLE in t/t1000-read-tree-m-3way.sh;\nthe table talks about some of the (ALT) not implemented, but\nsome of them are (\"git whatchanged t/t1000-read-tree-m-3way\"\nwould tell you which).\n\nTwo way cases are described in Documentation/git-read-tree.txt,\nif you care. If you were not touching the three-way case right\nnow, I'd move/copy the three way cases there as well, but that\ncan wait until after your changes.\n"},{"id":"7843","messageId":"7vy86nvjpe.fsf@assigned-by-dhcp.cox.net","threadId":"1674","inReplyTo":"7vwtm726xq.fsf@assigned-by-dhcp.cox.net","subject":"Re: Comments in read-tree about #nALT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-27T08:59:41Z","receivedAt":"2005-08-27T08:59:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Daniel Barkalow writes:\n>\n>> Part of threeway_merge, however, wants to search the rest of the cache for\n>> interfering entries in some cases, which would have to happen differently,\n>> because I won't have the cache completely filled out beforehand. I'm\n>> trying to figure out what the comments are talking about, and they seem to\n>> refer to a list of the possible cases. Is that list somewhere convenient?\n>\n> Please look for END_OF_CASE_TABLE in t/t1000-read-tree-m-3way.sh;\n> the table talks about some of the (ALT) not implemented, but\n> some of them are (\"git whatchanged t/t1000-read-tree-m-3way\"\n> would tell you which).\n>\n> Two way cases are described in Documentation/git-read-tree.txt,\n> if you care. If you were not touching the three-way case right\n> now, I'd move/copy the three way cases there as well, but that\n> can wait until after your changes.\n\nThe comments like /* 4 and 5 */ in twoway_merge refer to the\ncase table number in the Documentation/git-read-tree.txt\n\nJust in case you are wondering what all this index constraints\nare about. It used to be that the order of stages given to\n\"read-tree -m O A B\" did not have any inherent meaning, but it\nis not anymore, especially after the \"-u\" flag was introduced\nand the \"new world order\" was introduced to the merge operation.\nBefore that, we tried to do everything in the index file, and\neven merge-one-file-script tried not to touch the files in the\nworking tree at all while it worked. But that has changed, and\nthese days I believe the code assumes that A corresponds to the\ncommit the current working tree is based upon, and tries to make\nsure that the index file does not have a local modification that\nwould be lost by the result of \"read-tree -m -u O A B\" (that is,\nroughly speaking, read-tree chose B and the working tree was\nmodified since A).\n\nIf you need more information, probably the first thing to do\nwould be to run \"git whatchanged\" on read-tree, its tests and\ndocumentations to find the rough timescale of those \"new world\norder\" changes, and check the list archives.\n\nAs a software archaeologist, I've done some of that for you and\nfor myself. I hope these would help you.\n\nGee, up until now I thought my only significant contribution was\naround diff, but going through 5000+ messages made me realize I\nwas all over the place ;-).\n\n------------------------------------------------\n\n\nThis message talked about Linus' desire not to touch working\ntree at all.\n\n Date:\tSun, 1 May 2005 13:29:59 -0700 (PDT)\n From:\tLinus Torvalds \n Subject: Re: [PATCH] Really fix git-merge-one-file-script this time.\n Message-ID: \n\nThis was a question to Linus after the \"new merge world order\"\nhappened.\n\n Message-ID: <7v64wrvpt4.fsf@assigned-by-dhcp.cox.net>\n From: Junio C Hamano \n Subject: new read-tree questions.\n Date: Mon, 06 Jun 2005 01:43:03 -0700\n\nAnd these three discusses the issues. The first two are the\nmust-read responses from Linus.\n\n Message-ID: \n From: Linus Torvalds \n Subject: Re: new read-tree questions.\n Date: Mon, 6 Jun 2005 08:04:22 -0700 (PDT)\n\n Message-ID: \n From: Linus Torvalds \n Subject: Re: Last mile for 1.0\n Date: Mon, 6 Jun 2005 07:47:52 -0700 (PDT)\n\n Message-ID: <7voeajp875.fsf@assigned-by-dhcp.cox.net>\n From: Junio C Hamano \n Subject: Re: clarifying two tree merge semantics\n Date: Mon, 06 Jun 2005 12:59:58 -0700\n\nThe thread starting at this message is about emu23, which may\nnot affect directly what you are doing, but if you are\ninteresting the issues there are interesting.\n\n Message-ID: \n From: Linus Torvalds \n Subject: Handling merge conflicts a bit more gracefully..\n Date: Wed, 8 Jun 2005 13:55:23 -0700 (PDT)\n\nI've reproduced the whole message for this one, which is what\nyour question was about.\n\n Message-ID: <7voeagrp11.fsf_-_@assigned-by-dhcp.cox.net>\n From: Junio C Hamano \n Subject: [PATCH 0/3] Handling merge conflicts a bit more gracefully\n Date: Thu, 09 Jun 2005 00:02:34 -0700\n\nThis series consists of three patches.\n\n [PATCH 1/3] read-tree.c: rename local variables used in 3-way merge code.\n [PATCH 2/3] read-tree -m 3-way: loosen index requirements that is too strict.\n [PATCH 3/3] read-tree -m 3-way: handle more trivial merges internally\n\nYou may have noticed that I already described some \"alternative\nsemantics\" in the 3-way merge test script t1000. This set of\npatches implements some of them, namely the following 5 cases:\n\n O A B result index requirements\n-------------------------------------------------------------------\n 5 missing exists A==B take A must match A, if exists.\n ------------------------------------------------------------------\n 6 exists missing missing remove must not exist.\n ------------------------------------------------------------------\n 8 exists missing O==B remove must not exist.\n ------------------------------------------------------------------\n 10 exists O==A missing remove must match A and be\n up-to-date, if exists.\n ------------------------------------------------------------------\n 14 exists O==A O!=B take B if exists, must either (1)\n match A and be up-to-date,\n or (2) match B.\n-------------------------------------------------------------------\n\nThe first patch is to match the local variable names used in the\nfunctions involved to the names used in the case matrix.\n\nCase #14 is resolved identically as the old code does, but the\nindex requirement old code placed on this case was stricter than\nnecessary. In this case, satisfying the usual rule of \"match A\nand be up-to-date if exists\" is certainly OK, but additionally,\nif the original index matches the tree being merged (without\neven being up-to-date) is also permissible, because there would\nbe no information loss or work-tree clobbering if we allowed it.\nThe second patch in the series corrects this.\n\nCase #5, #6, #8, and #10 were traditionally kept unmerged in the\nindex file when read-tree is done, and resolving them was left\nto the script. By resolving these internally, we can loosen the\nindex requirements without compromising correctness for case #5.\nOther three cases could still be left for the \"script policy\"\nbecause this change does not affect the index requirements for\nthese cases, but it was simple enough to implement them and this\nwould not be too controversial a change. The third patch in the\nseries implements these changes.\n"},{"id":"7851","messageId":"Pine.LNX.4.63.0508271709530.23242@iabervon.org","threadId":"1674","inReplyTo":"7vwtm726xq.fsf@assigned-by-dhcp.cox.net","subject":"Re: Comments in read-tree about #nALT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-27T21:57:29Z","receivedAt":"2005-08-27T21:57:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 27 Aug 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n>\n> > Part of threeway_merge, however, wants to search the rest of the cache for\n> > interfering entries in some cases, which would have to happen differently,\n> > because I won't have the cache completely filled out beforehand. I'm\n> > trying to figure out what the comments are talking about, and they seem to\n> > refer to a list of the possible cases. Is that list somewhere convenient?\n>\n> Please look for END_OF_CASE_TABLE in t/t1000-read-tree-m-3way.sh;\n> the table talks about some of the (ALT) not implemented, but\n> some of them are (\"git whatchanged t/t1000-read-tree-m-3way\"\n> would tell you which).\n\nIt looks like all of them are implemented:\n\n#2ALT, #3ALT, #5ALT, and #14ALT, according to the commit comments, and the\nothers seem from the email you quote to have been done in the process of\ngetting #5ALT.\n\n> Two way cases are described in Documentation/git-read-tree.txt,\n> if you care. If you were not touching the three-way case right\n> now, I'd move/copy the three way cases there as well, but that\n> can wait until after your changes.\n\nI'd actually like to introduce Documentation/technical/trivial-merge for\nthis stuff; I think it would be good to have documentation for people who\nneed to know how the stuff works, rather than just how to use it, so we\nget a balance between reams of information that users don't want to wade\nthrough and being too vague for future developers.\n\nOkay, so it looks to me like the only cases that care about the contents\nof the index, other than in stage 0 (which is effectively another tree,\nbut already in index-form rather than tree-form), are 2 and 3, and these\nonly care because read-tree modifies the stage of entries, rather\nthan removing them and adding a stage-0 replacement entry; if it went\nthrough the add logic without SKIP_DFCHECK, that would reject the same\nthings that causes_df_conflict rejects (at the point where whichever is\nsecond is done).\n\nSo if I do the merge on tree entries (plus a stage-0 ce for the input from\nthe index), and then add the result(s) to the cache, I can skip\ncauses_df_conflict() in favor of just not using SKIP_DFCHECK. Is this\nright?\n\nAlso, there doesn't actually seem to be a DF test in t1000; I think the\nt1005 DF test covers these cases (by the emu23 path into this code). Is\nthis right?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7852","messageId":"Pine.LNX.4.63.0508271855100.23242@iabervon.org","threadId":"1674","inReplyTo":"Pine.LNX.4.63.0508271709530.23242@iabervon.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-27T23:15:51Z","receivedAt":"2005-08-27T23:15:51Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 27 Aug 2005, Daniel Barkalow wrote:\n\n> Okay, so it looks to me like the only cases that care about the contents\n> of the index, other than in stage 0 (which is effectively another tree,\n> but already in index-form rather than tree-form), are 2 and 3, and these\n> only care because read-tree modifies the stage of entries, rather\n> than removing them and adding a stage-0 replacement entry; if it went\n> through the add logic without SKIP_DFCHECK, that would reject the same\n> things that causes_df_conflict rejects (at the point where whichever is\n> second is done).\n>\n> So if I do the merge on tree entries (plus a stage-0 ce for the input from\n> the index), and then add the result(s) to the cache, I can skip\n> causes_df_conflict() in favor of just not using SKIP_DFCHECK. Is this\n> right?\n\nWhat I missed was that the effect of causes_df_conflict is to give \"no\nmerge\" for the entry, rather than giving an error overall. So I do need an\nequivalent.\n\n> Also, there doesn't actually seem to be a DF test in t1000; I think the\n> t1005 DF test covers these cases (by the emu23 path into this code). Is\n> this right?\n\nLooks like stuff all over the place fails if causes_df_conflict is messed\nup, so I should be covered.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7853","messageId":"Pine.LNX.4.58.0508271621210.3317@g5.osdl.org","threadId":"1674","inReplyTo":"Pine.LNX.4.63.0508271855100.23242@iabervon.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-27T23:35:15Z","receivedAt":"2005-08-27T23:35:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 27 Aug 2005, Daniel Barkalow wrote:\n> \n> What I missed was that the effect of causes_df_conflict is to give \"no\n> merge\" for the entry, rather than giving an error overall. So I do need an\n> equivalent.\n\nDaniel, \n I'm not 100% sure what you're trying to do, but one thing that might work \nout is to just having multiple \"stage 3\" entries with the same pathname.\n\nWe current use 4 stages:\n - stage 0 is \"resolved\"\n - stage 1 is \"original\"\n - stage 2 is \"one branch\"\n - stage 3 is \"another branch\"\n\nBut if we allowed duplicate entries per stage, I think we could easily \njust fold stage 2/3 into one stage, and just have entries in stage 2. \nThat would immediately mean that a three-way merge could be way.\n\nThe only rule would be that when you add a entry to stage 2, you must \nalways add it after any previous entry that is already in stage 2. That \nshould be easy.\n\nIn fact, this extension might even allow us to solve the \"multiple merge\nbase\" problem: we could allow multiple entries in \"stage 1\" too, ie one\nentry per merge base (and just collapse identical entries - there's no \nordering involved in stage 1 entries).\n\nSo you could merge \"n\" trees with \"m\" bases, and all without really \nchanging the current logic much at all.\n\nMaybe I'm missing something (like what you're trying to do in the first \nplace), but this _seems_ doable.\n\nOf course, \"git-merge-one-file\" gets more interesting as a result.\n\n\t\t\tLinus\n"},{"id":"7854","messageId":"Pine.LNX.4.63.0508271941090.23242@iabervon.org","threadId":"1674","inReplyTo":"Pine.LNX.4.58.0508271621210.3317@g5.osdl.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-28T00:16:35Z","receivedAt":"2005-08-28T00:16:35Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 27 Aug 2005, Linus Torvalds wrote:\n\n> On Sat, 27 Aug 2005, Daniel Barkalow wrote:\n> >\n> > What I missed was that the effect of causes_df_conflict is to give \"no\n> > merge\" for the entry, rather than giving an error overall. So I do need an\n> > equivalent.\n>\n> Daniel,\n> I'm not 100% sure what you're trying to do, but one thing that might work\n> out is to just having multiple \"stage 3\" entries with the same pathname.\n>\n> We current use 4 stages:\n> - stage 0 is \"resolved\"\n> - stage 1 is \"original\"\n> - stage 2 is \"one branch\"\n> - stage 3 is \"another branch\"\n>\n> But if we allowed duplicate entries per stage, I think we could easily\n> just fold stage 2/3 into one stage, and just have entries in stage 2.\n> That would immediately mean that a three-way merge could be way.\n>\n> The only rule would be that when you add a entry to stage 2, you must\n> always add it after any previous entry that is already in stage 2. That\n> should be easy.\n\nIt looks like stage 2 is currently special as the stage that's similar to\nthe index/HEAD/working tree. However, I don't see any problem with \nentries in stage 3, except that, if you have a non-maximal number of them\nfor some reason, it'll be impossible to determine which came from which\ntree.\n\n> In fact, this extension might even allow us to solve the \"multiple merge\n> base\" problem: we could allow multiple entries in \"stage 1\" too, ie one\n> entry per merge base (and just collapse identical entries - there's no\n> ordering involved in stage 1 entries).\n\nThat's actually the problem I was working on.\n\n> So you could merge \"n\" trees with \"m\" bases, and all without really\n> changing the current logic much at all.\n>\n> Maybe I'm missing something (like what you're trying to do in the first\n> place), but this _seems_ doable.\n\nI'd be afraid of confusing everything by removing the uniqueness\ninvariant, although I guess not too much does anything with entries in\nstages other than 0. I probably just don't find the index as intuitive as\nyou do and as the struct tree representation.\n\nI'm working on arranging the code to look at each path in sequence, with\nthe input trees as the inner loop, rather than with the loops in the other\norder; using parse_tree to parse the objects instead of read_tree; and\ndoing trivial merges before putting things in the cache, rather than\nafter. I'd been thinking that this would avoid a limit on the number of\nstages, since I hadn't considered whether multiple entries for the same\npath and stage could be allowed.\n\nI still think that my order is likely to be easier to understand and\ninvolve read-tree relying less on tricky properties of the data\nstructures, but I'll have to get it done before I can say that for sure.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7855","messageId":"Pine.LNX.4.58.0508271814410.3317@g5.osdl.org","threadId":"1674","inReplyTo":"Pine.LNX.4.63.0508271941090.23242@iabervon.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-28T01:18:52Z","receivedAt":"2005-08-28T01:18:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 27 Aug 2005, Daniel Barkalow wrote:\n> \n> It looks like stage 2 is currently special as the stage that's similar to\n> the index/HEAD/working tree.\n\nAhh, yes. We do actually want that. So yes, we should make only stage 3 \nhave the multiple entries.\n\n> I'd be afraid of confusing everything by removing the uniqueness\n> invariant, although I guess not too much does anything with entries in\n> stages other than 0. I probably just don't find the index as intuitive as\n> you do and as the struct tree representation.\n\nYes, I find the index to be very nice to work with - it basically allows\nyou to work with multiple trees in one go, instead of working one file at\na time. You just slurp in any number of trees (with some trivial rules\nabout which stage they go in), and then you can just walk through each\nfilename and efficiently handle one file at a time without re-doing the\ntree thing. Very nice.\n\n\t\t\tLinus\n"},{"id":"7859","messageId":"7virxqpqce.fsf@assigned-by-dhcp.cox.net","threadId":"1674","inReplyTo":"Pine.LNX.4.63.0508271855100.23242@iabervon.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-28T05:45:05Z","receivedAt":"2005-08-28T05:45:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> What I missed was that the effect of causes_df_conflict is to give \"no\n> merge\" for the entry, rather than giving an error overall. So I do need an\n> equivalent.\n\nCorrect.\n"},{"id":"7860","messageId":"7vd5nypqap.fsf@assigned-by-dhcp.cox.net","threadId":"1674","inReplyTo":"Pine.LNX.4.63.0508271709530.23242@iabervon.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-28T05:46:06Z","receivedAt":"2005-08-28T05:46:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> I'd actually like to introduce Documentation/technical/trivial-merge for\n> this stuff; I think it would be good to have documentation for people who\n> need to know how the stuff works, rather than just how to use it, so we\n> get a balance between reams of information that users don't want to wade\n> through and being too vague for future developers.\n\nI think that is an excellent idea to have user manual vs\ninternals manual.\n"},{"id":"7928","messageId":"7vr7cc6yrg.fsf@assigned-by-dhcp.cox.net","threadId":"1674","inReplyTo":"Pine.LNX.4.58.0508271621210.3317@g5.osdl.org","subject":"Re: Comments in read-tree about #nALT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-30T00:42:43Z","receivedAt":"2005-08-30T00:42:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Daniel, \n> I'm not 100% sure what you're trying to do, but one thing that might work \n> out is to just having multiple \"stage 3\" entries with the same pathname.\n\nMy understanding is that he is enhancing the current three-way\nmerge 'read-tree -m O A B' \"we are at A and have come from O; we\nwould like to apply changes made by somebody who went from O to\nA\" to 'read-tree -m O1,O2,O3,... A B' to mean \"any of the O_n\nare merge-base candidates\". I think having multiple \"stage 1\"\nis useful for what Daniel is doing.\n\n> But if we allowed duplicate entries per stage, I think we could easily \n> just fold stage 2/3 into one stage, and just have entries in stage 2. \n> That would immediately mean that a three-way merge could be way.\n\nI suspect you are solving a different problem here --- an\nOctopus.\n\nBut I agree that the current way of doing things in stage 2 and\nstage 3 is special casing two head merges from an Octopus, and\nthere might not be a fundamental reason for doing so. Folding\nthe current stage 2 and 3 into a single \"merge target stage\",\ntreating current stage 1 as \"merge base stage\", and allowing\nduplicate entries in both stages might turn out to make more\nsense. I suspect this would break a lot of tools initially, but\nthat is part of the process of making progress.\n\n> The only rule would be that when you add a entry to stage 2, you must \n> always add it after any previous entry that is already in stage 2. That \n> should be easy.\n\nThe same rule should apply to multiple stage 1 entries to\nrepresent multiple candidate merge bases.\n"},{"id":"7930","messageId":"Pine.LNX.4.58.0508291751200.3243@g5.osdl.org","threadId":"1674","inReplyTo":"7vr7cc6yrg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Comments in read-tree about #nALT","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-30T00:58:10Z","receivedAt":"2005-08-30T00:58:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 29 Aug 2005, Junio C Hamano wrote:\n> \n> > But if we allowed duplicate entries per stage, I think we could easily \n> > just fold stage 2/3 into one stage, and just have entries in stage 2. \n> > That would immediately mean that a three-way merge could be way.\n> \n> I suspect you are solving a different problem here --- an\n> Octopus.\n\nWell, that too, but I did mention doing the same thing for stage 1, which \nis the \"multiple merge bases\" case. \n\nIt all boils down to the same thing: we want to read in multiple trees, \nand then do merges one file at a time based on the result (and the fact \nthat we can have multiple entries for files in the different stages \nessentially just complicates \"git-merge-one-file\").\n\n> But I agree that the current way of doing things in stage 2 and\n> stage 3 is special casing two head merges from an Octopus, and\n> there might not be a fundamental reason for doing so. Folding\n> the current stage 2 and 3 into a single \"merge target stage\",\n\nDaniel pointed out that there is a real reason for stage 2 - it's used as \na special case for \"matches current index\". Apart from that, it's the same \nas stage 3.\n\nStage 3 is the one we can duplicate freely. There's can be only one branch\nthat is special in that it matches the current index, so expanding stage 3 \nfrom one to many is clearly something where all the different trees are on \nequal footing.\n\nSame goes for stage 1 - all merge bases are conceptually equally valid, \nand thus there is no reason to consider any \"ordering\" between them, and \nyou can merge any number of trees into stage 1.\n\nSo stage 0 and stage 2 are special in that they inherently have \"one\nspecial tree\" that they correspond to.\n\n\t\tLinus\n"}]}