[githelp] Merging two repositories
I have two separate local repositories cloned from the same other repository and I have made different changes to both. How do I merge those changes together using git ? Or do I have to do it manually ?
I have two separate local repositories cloned from the same other repository and I have made different changes to both. How do I merge those changes together using git ? Or do I have to do it manually ?
The simplest way is to have one reference the other, and then import your changes that way. Something along these lines: cd repo1 git remote add otherrepo ../repo2 git fetch --all git pull otherrepo master Ask if you need more informations. Philippe
cd repo1 git remote add otherrepo ../repo2 git fetch --all git pull otherrepo master
I just realised that simply "git pull ../repo2 master" should work too. Learn about git reflog so you know how to reset bad situations, or at worse do some physical backup of the directories if you are unsure and give it a try. Philippe
On 12/10/2013 3:54 AM, Philippe Vaucher wrote:
cd repo1 git remote add otherrepo ../repo2 git fetch --all git pull otherrepo master
I just realised that simply "git pull ../repo2 master" should work too.
It sounds like you are saying that I can just pull from the second repository to merge the changes from the second repository into the first repository. That sounds like the way it should work. Thanks !
Learn about git reflog so you know how to reset bad situations, or at worse do some physical backup of the directories if you are unsure and give it a try.
OK, thanks for pointing it out. I might just buy a git book and read it, since I am not patient enough to read everything online. Or maybe just print out the free online git at the main git site and then read that away from my computer.
Learn about git reflog so you know how to reset bad situations, or at worse
do some physical backup of the directories if you are unsure and give it a try.
OK, thanks for pointing it out. I might just buy a git book and read it, since I am not patient enough to read everything online.
Here is a super-quick-micro-crash-course: - git commits form a DAG (you can imagine it as a tree if it helps). A branch/tag is just a little sticker put on a part of a tree. Creating a commit in git is just adding a new part on the tree and moving the sticker "master" to it. Rewriting a commit is just going back a commit on the tree and creating a new one, and moving the sticker "master" to it. - when you rewrite history, delete commits, whatever.... they are not really deleted. They are just not visible anymore, because there are no "stickers" attached to them anymore. - "git reflog" shows you the history of what you did to the repo. So you see all commits you did, all rebases, all checkouts, etc, each time with the SHA1. - The only really destructive operation in git is "git gc", which collects commits/whatever that don't have a sticker attached to them. Given this information, you can now guess that "trying out things" in git is super safe... you try your stuffs, you verify the results, and if you are unhappy you "git reflog", find the SHA1 where stuffs were still ok, and "git reset --hard SHA1" and voila, you're back to your previous "good" state. There's also "git fsck" which can show you "lost" commits. HIH, Philippe
On Wed, Dec 11, 2013 at 1:28 AM, Philippe Vaucher < philippe.vaucher@gmail.com> wrote:
Learn about git reflog so you know how to reset bad situations, or at worse
do some physical backup of the directories if you are unsure and give it a try.
OK, thanks for pointing it out. I might just buy a git book and read it, since I am not patient enough to read everything online.
Here is a super-quick-micro-crash-course:
- git commits form a DAG (you can imagine it as a tree if it helps). A branch/tag is just a little sticker put on a part of a tree. Creating a commit in git is just adding a new part on the tree and moving the sticker "master" to it. Rewriting a commit is just going back a commit on the tree and creating a new one, and moving the sticker "master" to it. - when you rewrite history, delete commits, whatever.... they are not really deleted. They are just not visible anymore, because there are no "stickers" attached to them anymore. - "git reflog" shows you the history of what you did to the repo. So you see all commits you did, all rebases, all checkouts, etc, each time with the SHA1. - The only really destructive operation in git is "git gc", which collects commits/whatever that don't have a sticker attached to them.
Given this information, you can now guess that "trying out things" in git is super safe... you try your stuffs, you verify the results, and if you are unhappy you "git reflog", find the SHA1 where stuffs were still ok, and "git reset --hard SHA1" and voila, you're back to your previous "good" state. There's also "git fsck" which can show you "lost" commits.
Other git commands may automatically garbage collect unreachable commits, so don't count on them hanging around indefinitely without a ref anchor to make them reachable. The git-gc man page shows how you can disable gc for your repo, but that doesn't prevent Github from saving space by gc'ing your remote repo. Michael
HIH, Philippe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Cox, Michael -
Edward Diener -
Oliver Kowalke -
Philippe Vaucher