On Thu, Mar 17, 2016 at 11:07 PM, Laxman Dewangan <ldewangan@xxxxxxxxxx> wrote: > > For creating the repo and branch, I just followed the instruction from wiki > https://help.github.com/articles/create-a-repo/ So you shouldn't have created a new repo at all, you should just have cloned an existing one (that gets you a repo, of course). You basically ended up starting a new project. But I guess the github connection explains why there was a crazy README.md file there, and I can see why that documentation would make you think it's the right thing to do. Oh well. Just a "git init" wouldn't have done that kind of damage, the github documentation is just misleading in this respect. We may have to make it really really really clear for the kernel that people should not use github in any way except purely for hosting.. > I jut use git (git version 2.1.4) for pushing the changes in github repo. > > There is no other tools used. I thought git didn't merge two branches that have no common base by default, but it seems it will happily do so. So once you made the mistake of starting a new project, git merge ended up "helpfully" allowing you to merge the remote tracking branch into that new project, and we ended up with a silly new root. "git pull-request" will complain about not having a commit in common, but "git merge" apparently does not even warn. Adding Junio and the git list. This seems like much too easy a way to screw up. Junio (and git people), the problem is that github seems to have caused Laxman to think he should start a new project, and then git happily merged the new root just because nobody knew better. And sadly, I didn't notice the history screw-up until too late, so now we in the kernel have a third root commit (the first two are intentional): commit a101ad945113 was merged by commit e5451c8f8330. So how about a patch something like this: --- a/builtin/merge.c +++ b/builtin/merge.c @@ -1398,7 +1398,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix) NULL, 0, UPDATE_REFS_DIE_ON_ERR); if (remoteheads && !common) - ; /* No common ancestors found. We need a real merge. */ + die(_("No common ancestor - not merging")); else if (!remoteheads || (!remoteheads->next && !common->next && common->item == remoteheads->item)) { (the above is explicitly whitespace-damaged on purpose - it's not meant as a serious patch, because we do want the *ability* to merge different projects across different roots, and there are even git tests for it, it's just that I think it's too easy to make this mistake and not even realize). So the real thing having a special option required to merge non-related projects? Or at least a humongous warning? You can recreate (for testing only!) this by doing this in a kernel repo: git checkout a101ad945113 git merge 3cf42efc3479 and you'll see how it happily ends up creating a merge commit with no common ancestors and no warning that anything might be wrong. It will take a while - walking all the way up to the root to not find the common object - but it will happily merge those two totally unrelated branches without complaining at all. Now I'm starting to wonder just how many github projects have lots of separate root commits.. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html