{"thread":{"id":"23379","subject":"git pull with \"no common commits\" : danger?","startedAt":"2010-04-08T01:56:56Z","lastAt":"2010-04-08T19:55:23Z","messageCount":7,"participants":["Aghiles","Michael J Gruber","Jonathan Nieder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"138909","messageId":"v2t3abd05a91004071856s5811e086q17241996a359e172@mail.gmail.com","threadId":"23379","inReplyTo":null,"subject":"git pull with \"no common commits\" : danger?","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2010-04-08T01:56:56Z","receivedAt":"2010-04-08T01:56:56Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Hello,\n\nI mistakenly pulled a project into another project. I had the\n\"warning: no common commits\" but the pull did proceed.\nI am wondering if, from a usability point of view, it would be\nbest to avoid doing so by default.\n\nThanks,\n\n  -- aghiles\n"},{"id":"138911","messageId":"4BBD3A98.2020207@drmicha.warpmail.net","threadId":"23379","inReplyTo":"v2t3abd05a91004071856s5811e086q17241996a359e172@mail.gmail.com","subject":"Re: git pull with \"no common commits\" : danger?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-04-08T02:08:24Z","receivedAt":"2010-04-08T02:08:24Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Aghiles venit, vidit, dixit 08.04.2010 09:56:\n> Hello,\n> \n> I mistakenly pulled a project into another project. I had the\n> \"warning: no common commits\" but the pull did proceed.\n> I am wondering if, from a usability point of view, it would be\n> best to avoid doing so by default.\n\nPuleeezze: No animals were harmed during the process, right? I mean, no\ndata loss, all you have to do is a git reset. Let's try and not make Git\ninto \"Are you sure\"dom.\n\nMichael\n"},{"id":"138915","messageId":"h2g3abd05a91004071943g6352370fnc68b81c73a204bb0@mail.gmail.com","threadId":"23379","inReplyTo":"4BBD3A98.2020207@drmicha.warpmail.net","subject":"Re: git pull with \"no common commits\" : danger?","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2010-04-08T02:43:47Z","receivedAt":"2010-04-08T02:43:47Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"> Aghiles venit, vidit, dixit 08.04.2010 09:56:\n>> Hello,\n>>\n>> I mistakenly pulled a project into another project. I had the\n>> \"warning: no common commits\" but the pull did proceed.\n>> I am wondering if, from a usability point of view, it would be\n>> best to avoid doing so by default.\n>\n> Puleeezze: No animals were harmed during the process, right? I mean, no\n> data loss, all you have to do is a git reset. Let's try and not make Git\n> into \"Are you sure\"dom.\n\nHow many times did you see that message? If you saw it, it was probably a\nmistake. I think that it is a safe bet to assume that whoever does that won't\ncomplain to type something like: git pull --no-common-commits-ok\n\nI manage many git projects and this happens from time to time, mainly\nbecause of tiredness. I simply consider the proposed behaviour more\nnatural.\n\nGit is not the bare bone tool set anymore, it aspires into becoming a user\nfriendly tool, usable by \"the masses\". And don't worry, following some simple\nusability rules won't make git less \"cool\".\n\nNow, that was just a suggestion,\n\n -- aghiles\n"},{"id":"138926","messageId":"20100408054349.GA6067@progeny.tock","threadId":"23379","inReplyTo":"v2t3abd05a91004071856s5811e086q17241996a359e172@mail.gmail.com","subject":"Re: git pull with \"no common commits\" : danger?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-08T05:44:05Z","receivedAt":"2010-04-08T05:44:05Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nAghiles wrote:\n\n> I mistakenly pulled a project into another project. I had the\n> \"warning: no common commits\" but the pull did proceed.\n\nFirst: you are aware that interrupting the pull will have no bad\nside-effects, right? So if the worry is lost time, then git is not\nadvertising its features well enough.\n\nBecause of this, if ‘git fetch’ starts refusing to fetch when there\nare no common commits, I will be unhappy, because it imposes hassle on\nthe user for basically no benefit.\n\nOn the other hand, ‘git pull’ is a little different. The fetch has\nvery little cost because it’s interruptible, but the merge could\nresult in two unrelated pieces of history being merged, requiring\nthe user to use ‘git reset --keep HEAD^’ to get back to the\nprevious state. A more likely outcome is a merge conflict, requiring\n‘git reset --merge’ to recover.\n\nCan we make this less painful? Is it worth adding yet another option\nto ‘git pull’ to avoid this pain? I don’t know.\n\nRegards,\nJonathan\n"},{"id":"138930","messageId":"7v1veq8nyf.fsf@alter.siamese.dyndns.org","threadId":"23379","inReplyTo":"v2t3abd05a91004071856s5811e086q17241996a359e172@mail.gmail.com","subject":"Re: git pull with \"no common commits\" : danger?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-08T06:20:40Z","receivedAt":"2010-04-08T06:20:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aghiles writes:\n\n> I mistakenly pulled a project into another project. I had the\n> \"warning: no common commits\" but the pull did proceed.\n> I am wondering if, from a usability point of view, it would be\n> best to avoid doing so by default.\n\nRefusing this without an escape hatch would regress two minor but valid\nworkflows.\n\n 1. \"a cross-project merge\" like 5569bf9 (Do a cross-project merge of Paul\n Mackerras' gitk visualizer, 2005-06-22) aka \"The coolest merge ever\".\n Being able to do this kind of merge after the fact is the whole point\n of allowing merges between two histories with no common commits.\n\n 2. A not so uncommon newbie mistake sequence:\n\n $ git init\n $ git pull $there\n\n instead of the usual\n\n $ git clone $there\n \n which was an actual complaint that led to the \"merge into emptiness\"\n behaviour of \"git pull\" in such a case added as a new feature.\n\nIf we were to forbid a \"nothing in common\" merge by default and add an\noption to explicitly allow it on demand, I would not be worried too much\nabout the first use case. Anybody who runs a cross-project merge has\nalready learned git well enough that having to add an extra option is not\na problem.\n\nBut I would be unhappy if I have to be the one to hear complaints from\nnewbies who are now forced to add an obscure option to his \"git pull\" in\nthe second case.\n\nSo this is not so cut-and-dried from the usability point of view as you\nseem to think.\n"},{"id":"138981","messageId":"r2m3abd05a91004081246x35f9c674m6f4e379255513c80@mail.gmail.com","threadId":"23379","inReplyTo":"7v1veq8nyf.fsf@alter.siamese.dyndns.org","subject":"Re: git pull with \"no common commits\" : danger?","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2010-04-08T19:46:30Z","receivedAt":"2010-04-08T19:46:30Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Junio C Hamano writes:\n\n>\n> ...\n>\n> But I would be unhappy if I have to be the one to hear complaints from\n> newbies who are now forced to add an obscure option to his \"git pull\" in\n> the second case.\n>\n> So this is not so cut-and-dried from the usability point of view as you\n> seem to think.\n\nI understand your reasoning for the second case, and the init/pull sequence\nis something I used to do too. Thanks for the explanations.\n\nRegarding this init/pull sequence: it might be nice to print something like:\n\n Merging with an empty tree, 'git clone' intended ?\n\nI see more and more such messages when using various git commands, it\nhelps a lot.\n\n -- aghiles\n"},{"id":"138983","messageId":"t2j3abd05a91004081255h58d2aca3leeb41adf53dc6a4f@mail.gmail.com","threadId":"23379","inReplyTo":"20100408054349.GA6067@progeny.tock","subject":"Re: git pull with \"no common commits\" : danger?","fromName":"Aghiles","fromEmail":"aghilesk@gmail.com","sentAt":"2010-04-08T19:55:23Z","receivedAt":"2010-04-08T19:55:23Z","isPatch":false,"sender":{"key":"aghilesk@gmail.com","avatar":null},"body":"Jonathan Nieder writes:\n>\n> ...\n>\n> On the other hand, ‘git pull’ is a little different.  The fetch has\n> very little cost because it’s interruptible, but the merge could\n> result in two unrelated pieces of history being merged, requiring\n> the user to use ‘git reset --keep HEAD^’ to get back to the\n> previous state.  A more likely outcome is a merge conflict, requiring\n> ‘git reset --merge’ to recover.\n>\n> Can we make this less painful?  Is it worth adding yet another option\n> to ‘git pull’ to avoid this pain?  I don’t know.\n\nThat is exactly the case I was talking about. I never lost any data\nbecause of this and considering what Junio Hamano is saying I\nprobably should just continue to do the 'git reset'.\n\n -- aghiles\n"}]}