On Tue, 29 Nov 2016 00:38:28 -0800 (PST) Madhumita Bharde <[email protected]> wrote:
> > > A project I started working on involves changes to opensource git > > > repos -* repo1 *and *repo2* > > > So we have a private git repo say, *myrepo* created with older > > > versions of both repo1 and repo2 (without corresponding .git > > > directories, of course) > > > > How are those repo1 and repo2 codebases stored there? > > Plain subdirectories originally obtained by unpacking upstream > > tarballs or something like this? Something else? > > > > > Now, I want to port changes in latest codebases of *repo1* and > > > *repo2* in *myrepo*. > > > > How do you intend to obtain these codebases? > > Are they maintained as Git repositories as well? Tarballs? > > Something else? [...] > repo1 and repo2 source code was downloaded in tarball format and the > directories were copied to create myrepo which is privately being > maintained as a git repo. > I do not mind getting newer versions of repo1 and repo2 using git > clone (so yes, they are maintained as git repos) or downloading the > tarballs for latest source code. What would be a better option? > > Was trying to create patches for relevant commits in repo1 and repo2 > and apply them to myrepo, but to no avail. I am not sure if this is > the right/feasible approach.. Well, if we suppose your myrepo contains at its toplevel two subdirectories named "repo1" and "repo2" you could take at least two approaches. The first, low-tech one is to just grab "recent" tarballs of the repo1 and repo2 projects and do this: 1) Delete using `git rm` the whole contents of the "repo1" subdirectory. 2) Unwrap the repo1 tarball into the "repo1" subdirectory. 3) `git add` all the files in the repo1 subdirectory. 4) Commit the changes. The end result will be as if you "squash-merged" the changes since the original state of "repo1": some files added, some removed, some modified. Another -- more "high-tech" -- approach is to use the so-called "subtree merging". Basically you do something like: git fetch repo1_url master git merge -s ours --no-commit FETCH_HEAD git read-tree --prefix=repo1 -u FETCH_HEAD git commit -m 'Merge repo1' This will bring the (whole) history of repo1's "master" branch into your repository, place its files in the repo1 subdirectory and record a true merge commit which ties together the history of your repository and that of repo1. The added bonus is that the next time you do git fetch repo1_url master git merge FETCH_HEAD Git should be able to figure out where you'd like to actually relocate the new stuff appeared on the repo1's master. Read more in [1]. 1. https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
