![]() ![]() Unfortunately, merging changes the other way is somewhat trickier, and anyways, you should probably do this as a one time thing, then close the wiki, or redirect to the repo source.įurthermore, a major caveat of this approach is that git log wiki/Home.md (for example) doesn't actually show the history from the wiki page. To merge the new changes in after review, you would do: git pull -s subtree wiki master You can even keep the wiki working on the side to welcome public contributions there, but then vet them into your main documentation as you see fit. Git commit -m "Github wiki subtree merged in wiki/" ![]() Git read-tree -prefix=wiki/ -u wiki/master Git merge -s ours -no-commit -allow-unrelated wiki/master Git remote add -f wiki git:///you/proj.wiki Then to merge it in your main repository, you would do: git clone git:///you/proj For example, assuming your repository is you/proj, your wiki would be at: git:///you/proj.wiki. ![]() Nevertheless, I believe the best solution is to simply move the wiki into the main repository, say in docs/ or wiki, using a subtree merge. In my opinion, GitHub wikis should be branches of the main repository, or at least it should be possible to make that an option. Push merged changes to our clone of FOO_LIBRARY.Pull upstream changes from upstream master branch.Let’s assume our current directory is vc in the hierarchy above. For brevity let’s assume you make no further changes to the upstream code. That will make merging easier when you pull changes from the submodule’s upstream.įOO_LIBRARY upstream has made changes to their repository and you need those changes integrated in Mono. One thing to keep in mind is that if the submodule is a fork it is a good idea to keep your commits as finely grained as possible. The only difference is the first step - in the former case you pull changes from upstream, in the latter you make your own changes. What follows is a workflow which covers both cases above. it is a fork of some upstream repository.We have two scenarios to consider when working with FOO_LIBRARY: Let’s assume the following directory hierarchy: |vc If you work both on the submodule itself and Mono, here’s a workflow you need to follow in order to maintain a healthy relationship between Mono and the submodule. It is also required that you always push the submodule changes before any and all work requiring the changes is done in the Mono repository. It is extremely important not to end the external/MODULE_NAME reference above with a / since that will make git remove the submodule reference and commit all its contents as normal files to Mono directory. Git commit -m "Module MODULE_NAME updated" When the changes are checked out, commit the changes to the Mono repository: cd. You can, of course, use a a specific commit in the ‘git pull’ above instead of the default HEAD. Then in order to integrate changes from the submodule repository of origin: cd external/MODULE_NAME When the submodule repository of origin is ready to be used by Mono, you need to go to the top level directory of Mono repository clone and make sure the submodules are checked out and up to date: git submodule init When there exist upstream changes you need to merge, the following command needs to be used: git fetch upstream/masterįollowed by git merge upstream/BRANCH_NAMEĪnd as soon as all the possible confilits are resolved, push the freshly integrated changes back to our repository git push origin/BRANCH_NAME If this is the case, you must configure your clone of it by adding a remote reference to the upstream repository: git remote add upstream UPSTREAM_URL The repository may be a fork or clone of yet another GIT repository, either on github or elsewhere. The submodule repository of origin (at the REPOSITORY_URL above) must always be modified outside the Mono directory. Submodule repository of origin maintenance If you want to add a new submodule, issue the following command from the Mono topmost directory: git submodule add REPOSITORY_URL external/MODULE_NAMEĪfter that commit and push the changes to. ![]() If you have write access to the submodule repository do your work on it in a separate location, do not ever do any work in the mono copy of the submodule.Īll submodules should reside under the external/ directory off the top level Mono directory. To list the submodules in use run: git submodule The description applies to each of the submodules used by mono. End users do not need to be concerned with the procedures described below. These instructions are for developers working on code in this repository.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |