{"thread":{"id":"41735","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","startedAt":"2016-03-18T07:15:25Z","lastAt":"2016-03-18T17:16:55Z","messageCount":7,"participants":["Linus Torvalds","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281133","messageId":"CA+55aFy=-UAbVo+Xx08tBA7eTPk2B+G3=SbarVxThS57LdakPA@mail.gmail.com","threadId":"41735","inReplyTo":"56EB9B0C.4050507@nvidia.com","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2016-03-18T07:15:25Z","receivedAt":"2016-03-18T07:15:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Thu, Mar 17, 2016 at 11:07 PM, Laxman Dewangan wrote:\n>\n> For creating the repo and branch, I just followed the instruction from wiki\n> https://help.github.com/articles/create-a-repo/\n\nSo you shouldn't have created a new repo at all, you should just have\ncloned an existing one (that gets you a repo, of course).\n\nYou basically ended up starting a new project.\n\nBut I guess the github connection explains why there was a crazy\nREADME.md file there, and I can see why that documentation would make\nyou think it's the right thing to do.\n\nOh well.\n\nJust a \"git init\" wouldn't have done that kind of damage, the github\ndocumentation is just misleading in this respect.\n\nWe may have to make it really really really clear for the kernel that\npeople should not use github in any way except purely for hosting..\n\n> I jut use git (git version 2.1.4) for pushing the changes in github repo.\n>\n> There is no other tools used.\n\nI thought git didn't merge two branches that have no common base by\ndefault, but it seems it will happily do so.\n\nSo once you made the mistake of starting a new project, git merge\nended up \"helpfully\" allowing you to merge the remote tracking branch\ninto that new project, and we ended up with a silly new root.\n\n\"git pull-request\" will complain about not having a commit in common,\nbut \"git merge\" apparently does not even warn.\n\nAdding Junio and the git list. This seems like much too easy a way to screw up.\n\nJunio (and git people), the problem is that github seems to have\ncaused Laxman to think he should start a new project, and then git\nhappily merged the new root just because nobody knew better. And\nsadly, I didn't notice the history screw-up until too late, so now we\nin the kernel have a third root commit (the first two are\nintentional): commit a101ad945113 was merged by commit e5451c8f8330.\n\nSo how about a patch something like this:\n\n --- a/builtin/merge.c\n +++ b/builtin/merge.c\n @@ -1398,7 +1398,7 @@ int cmd_merge(int argc, const char **argv,\nconst char *prefix)\n NULL, 0, UPDATE_REFS_DIE_ON_ERR);\n\n if (remoteheads && !common)\n - ; /* No common ancestors found. We need a real merge. */\n + die(_(\"No common ancestor - not merging\"));\n else if (!remoteheads ||\n (!remoteheads->next && !common->next &&\n common->item == remoteheads->item)) {\n\n(the above is explicitly whitespace-damaged on purpose - it's not\nmeant as a serious patch, because we do want the *ability* to merge\ndifferent projects across different roots, and there are even git\ntests for it, it's just that I think it's too easy to make this\nmistake and not even realize).\n\nSo the real thing having a special option required to merge\nnon-related projects? Or at least a humongous warning?\n\nYou can recreate (for testing only!) this by doing this in a kernel repo:\n\n git checkout a101ad945113\n git merge 3cf42efc3479\n\nand you'll see how it happily ends up creating a merge commit with no\ncommon ancestors and no warning that anything might be wrong. It will\ntake a while - walking all the way up to the root to not find the\ncommon object - but it will happily merge those two totally unrelated\nbranches without complaining at all.\n\nNow I'm starting to wonder just how many github projects have lots of\nseparate root commits..\n\n Linus\n"},{"id":"281144","messageId":"alpine.DEB.2.20.1603181532040.4690@virtualbox","threadId":"41735","inReplyTo":"CA+55aFy=-UAbVo+Xx08tBA7eTPk2B+G3=SbarVxThS57LdakPA@mail.gmail.com","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-18T14:32:54Z","receivedAt":"2016-03-18T14:32:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Linus,\n\nOn Fri, 18 Mar 2016, Linus Torvalds wrote:\n\n> I thought git didn't merge two branches that have no common base by\n> default, but it seems it will happily do so.\n\nWhat happened to \"The coolest merge EVER!\"?\n\n\thttp://thread.gmane.org/gmane.comp.version-control.git/5126/\n\nCiao,\nDscho\n"},{"id":"281150","messageId":"xmqqzitvrdul.fsf@gitster.mtv.corp.google.com","threadId":"41735","inReplyTo":"alpine.DEB.2.20.1603181532040.4690@virtualbox","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-18T15:43:30Z","receivedAt":"2016-03-18T15:43:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi Linus,\n>\n> On Fri, 18 Mar 2016, Linus Torvalds wrote:\n>\n>> I thought git didn't merge two branches that have no common base by\n>> default, but it seems it will happily do so.\n>\n> What happened to \"The coolest merge EVER!\"?\n>\n> \thttp://thread.gmane.org/gmane.comp.version-control.git/5126/\n>\n> Ciao,\n> Dscho\n\nAn obvious response to the above, \"What about it?\", is something you\nwould have already anticipated when you wrote the above, and I wish\nI saw that in the message I am responding to, but I didn't, so here\nis my attempt ;-)\n\nThe old article shows two interesting things. One is that there are\ncases where it makes perfect sense to bind two unrelated histories\nwhen the two roots are totally unrelated.\n\nI am not Linus, but I think the proposal is to make it harder to do\nthis unusual merge by mistake, while keeping it possible to do so\nwhen the user really wants to. And the \"deliberately whitespace\ndamaged patch\" in the message you are responding to was primarily to\npoint out where the \"making it harder\" logic should go by showing\nhow to make it impossible, leaving it to readers to adjust it to\n\"harder but still possible\".\n\nNow, the second thing that the old article you pointed shows is that\nit is possible to create such a merge without using \"git merge\" even\nthough it is more involved and takes conscious effort by the user.\nIn that sense, you could argue that, with the \"make it impossible\"\nchange in Linus's message to \"git merge\", there is no more change\nneeded (I do not know if that is what you meant to imply, though).\n\nI think it makes sense to teach \"git merge\" to error out like Linus\ndid unless the user explicitly says \"I know what I am doing\" with an\nexplicit option (e.g. --force or --merge-unrelated-histories).\n"},{"id":"281151","messageId":"CA+55aFwbRVG-5AW+NnMOFZ_hU5i+i7f3FxgEt9Qm7B6pEd7x0g@mail.gmail.com","threadId":"41735","inReplyTo":"alpine.DEB.2.20.1603181532040.4690@virtualbox","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2016-03-18T15:47:02Z","receivedAt":"2016-03-18T15:47:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin\n wrote:\n>\n> On Fri, 18 Mar 2016, Linus Torvalds wrote:\n>\n>> I thought git didn't merge two branches that have no common base by\n>> default, but it seems it will happily do so.\n>\n> What happened to \"The coolest merge EVER!\"?\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/5126/\n\nI'm not complaining about multi-root capability in general - it's\nstill cool. In the kernel, we have aef8755711a2 (\"Merge Btrfs into\nfs/btrfs\") that does something slightly similar.\n\nIt's literally just the fact that \"git merge\" does it with no extra\nflags or checks. I'd like people to have to be aware of what they are\ndoing when they merge two different projects, not do it by mistake.\n\nSo making it conditional on a flag like \"--no-common-root\" is what I'd look for.\n\nOr just make it about the merge stategy. For example, \"subtree\" makes\nsense exactly for merging one project into a subdirectory of another.\nBut the default merge shouldn't do it.\n\nI don't think the original \"resolve\" did it, for example. You can't do\na three-way merge without a base.\n\nNote how that above \"coolest merge\" definitely wasn't done by just\n\"git merge gitk\". I had to play around with the git internals. Now, it\nshouldn't be _that_ hard, but at the same time it really shouldn't be\nas easy as \"I didn't know, so I merged two independent projects\".\n\n Linus\n"},{"id":"281156","messageId":"xmqqr3f7rbck.fsf@gitster.mtv.corp.google.com","threadId":"41735","inReplyTo":"CA+55aFwbRVG-5AW+NnMOFZ_hU5i+i7f3FxgEt9Qm7B6pEd7x0g@mail.gmail.com","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-18T16:37:31Z","receivedAt":"2016-03-18T16:37:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> It's literally just the fact that \"git merge\" does it with no extra\n> flags or checks. I'd like people to have to be aware of what they are\n> doing when they merge two different projects, not do it by mistake.\n>\n> So making it conditional on a flag like \"--no-common-root\" is what I'd look for.\n\nI think I said essentially the same thing in a separate message; I\nam not sure \"--no-common-root\" is a good name, but I think it is\nbetter to be more explicit than tying this to a strategy.\n\n> I don't think the original \"resolve\" did it, for example. You can't do\n> a three-way merge without a base.\n\nYes, and that continues to this day:\n\n # Give up if we are given two or more remotes -- not handling octopus.\n case \"$remotes\" in\n ?*' '?*)\n exit 2 ;;\n esac\n\n # Give up if this is a baseless merge.\n if test '' = \"$bases\"\n then\n exit 2\n fi\n\nThis is a tangent but I wonder if we should say why we refuse to\nthe standard error before calling these two \"exit\"s.\n"},{"id":"281157","messageId":"CA+55aFzVqPzEg6zq7sRweE7OCVKMJzM1eZRHXddMG+BabEDeCA@mail.gmail.com","threadId":"41735","inReplyTo":"xmqqr3f7rbck.fsf@gitster.mtv.corp.google.com","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2016-03-18T17:01:25Z","receivedAt":"2016-03-18T17:01:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Fri, Mar 18, 2016 at 9:37 AM, Junio C Hamano wrote:\n>\n>> I don't think the original \"resolve\" did it, for example. You can't do\n>> a three-way merge without a base.\n>\n> Yes, and that continues to this day:\n\nYeah, \"octopus\" also refuses it cleanly:\n\n common=$(git merge-base --all $SHA1 $MRC) ||\n die \"Unable to find common commit with $pretty_name\"\n\nThe code in the recursive merge that allows this to happen is this:\n\n if (merged_common_ancestors == NULL) {\n /* if there is no common ancestor, use an empty tree */\n struct tree *tree;\n\n tree = lookup_tree(EMPTY_TREE_SHA1_BIN);\n merged_common_ancestors = make_virtual_commit(tree, \"ancestor\");\n }\n\nso the \"no common ancestors\" is just considered to be an empty merge base.\n\nAnd I do think that's right, and I think it's clever, and it goes back to 2006:\n\n 934d9a24078e merge-recur: if there is no common ancestor, fake empty one\n\nbut I think there should be an option there.\n\n> This is a tangent but I wonder if we should say why we refuse to\n> the standard error before calling these two \"exit\"s.\n\nAs mentioned, Octopus does.\n\nThat said, there's probably no reason to ever use the old three-way\nmerge, so I'm not even sure it's worth fixing the old\ngit-merge-resolve.\n\n Linus\n"},{"id":"281158","messageId":"xmqqk2kzr9iw.fsf@gitster.mtv.corp.google.com","threadId":"41735","inReplyTo":"CA+55aFzVqPzEg6zq7sRweE7OCVKMJzM1eZRHXddMG+BabEDeCA@mail.gmail.com","subject":"Re: [GIT PULL] GPIO bulk changes for kernel v4.6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-18T17:16:55Z","receivedAt":"2016-03-18T17:16:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> The code in the recursive merge that allows this to happen is this:\n> ...\n> And I do think that's right, and I think it's clever, and it goes back to 2006:\n>\n> 934d9a24078e merge-recur: if there is no common ancestor, fake empty one\n>\n> but I think there should be an option there.\n\nOh, I think everybody understands that and agrees by now.\n\n"}]}