Matthieu Moy <matthieu....@grenoble-inp.fr> writes: > Jose de Leon <jdel...@ensim.com> writes: > >> For some unknown reason to me, our developers started a git project, >> called Ver1, this was the first version. Then sometime later, they >> created a new git repository called Ver2, the initial commit for Ver2 >> was essentially a copy of the code in Ver1 from the master. They >> didn't clone it, they just copied the code at the latest point. > > This is why "graft points" were created, and then superseeded by "git > replace". > > See http://git-scm.com/blog/2010/03/17/replace.html and > http://git-scm.com/docs/git-replace
After setting up either grafts or replaces, I'd strongly recommend running filter-branch or bfg to rewrite the history of the combined result, and have the developers use that rewritten history _after_ removing the grafts (or replaces). And if you are going to go that route, then graft is sufficient and a lot more light-weight. The only advantage replace has over grafts is that they can be transferred using "git push" and "git fetch" (while grafts can be transferred with some file transfer mechanism outside Git) but if you are rewriting the history, that advantage is lost. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
