[git-users] Re: help with combine repositories
I could actively tell git that two trees are the same. I'll keep my eyes open for an answer to this one on this list, as this interests me as much as it does you. This is key for your problem. But I can tell you this much: over here, where I'm working, we cloned entire reposes -- history and all -- so that we could easily pull from each other when needed, without worrying about differing histories. We're also using the patch-based approach, but the issue of failing to apply older patches to newer branches arises frequently. The way we're working around that, is to apply the older patch to a temporary branch starting from the commit the patch was created from, and then cherry-pick it onto the right branch. If there are no conflicts, git will do the right thing every time, and history is key. Suppose, I have a repository with history on master. Now I create a new branch new from nothing that includes all the same files as master, but no history. Just as if i created all the files now from scratch. I'm not sure you can do that at all in git, i.e. branch from no commit. That, indeed, would be like cloning with no history. I'll also keep my eyes peeled for this one... Thank you for your feedback as well. vineri, 25 mai 2012, 22:43:36 UTC+3, 7ff a scris: Stafen, thank you for your reply, Am Freitag, 25. Mai 2012 13:49:52 UTC+2 schrieb Stefan: [...]There simply is no way to cherry-pick commits (or rebase branches) from B into A, since git has no way to know that they are even the same source tree, let alone have any common history among them. I did know about the different sha when they don't have a common history. I was under the impression, that I could actively tell git that two trees are the same. But it seems I was remembering wrongly, git merge -s ours does the opposite of what I want: merge in all the history without changing files :-( To simplify the problem a bit (forget about the submodule and changes files and two repositories for a moment): Suppose, I have a repository with history on master. Now I create a new branch new from nothing that includes all the same files as master, but no history. Just as if i created all the files now from scratch. master and new have no common history, right. But could I not merge new into master? There should not be any conflicts since all files are the same. (?) Or if it is seen as a conflict that I want to recreate an already existing file (even with the very same content), I could resolve this easily, by just adding either version. What am I missing here? I might try this experiment later and see what's happening. I suspect that it will not work that way even though I don't really understand why ... So, the way I see it, in your case you have but one choice, and that is to move patches from B to A (and backwards, if A is indeed active itself!) and applying them in the same sequence. Git also tries to make this easier for you by providing things like format-patch, send-email, apply, etc. right, applying patch-files, or even copying files over and checking them in again, that was my Plan B already. cheers Matt -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/BZ7sipuaNkUJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: help with combine repositories
Maybe I can also help shed some light here. I'll start with the difference between patch and commit. Patch is -- simply put -- a diff between two versions of the same tree. You can only apply the patch to the same version of the tree from which it was generated. Period. In comes git to add a new dimension to patching: the history. A patch with a history is a commit. Every commit has a SHA1 that makes it unique. Two commits that have different SHA1s are viewed as different commits, even though running git format-patch on both could yield identical results! otherwise put, even though it's the same patch, if applied to different histories, you have different commits. And this is the case with your A and B reposes. Even though B starts fresh from a given commit in A, git has no way of knowing this without replicating the entire history (I'm not an expert here, so someone may cut in and contradict me; but this highlights the true git-related question behind your question: Is there a way to link two separate git histories without actually replicating them?). There simply is no way to cherry-pick commits (or rebase branches) from B into A, since git has no way to know that they are even the same source tree, let alone have any common history among them. So, the way I see it, in your case you have but one choice, and that is to move patches from B to A (and backwards, if A is indeed active itself!) and applying them in the same sequence. Git also tries to make this easier for you by providing things like format-patch, send-email, apply, etc. Anyone else please feel free to disagree. joi, 24 mai 2012, 18:40:52 UTC+3, 7ff a scris: Hello, I would appreciate some help or suggetions on this problem: condensed version: - A) a big repository with long history and a submodule B) a small repo made recently from an export of repo A, except some files/folders and including the files from the submodule of A how can I merge new commits (or cherrypick)? more detailed: --- repo A is a project with about 10 years of history (partially imported form svn) which I want to keep. This repo includes files for different customers/ applications. Recently, I agreed to work on this project with a team of one customer in a shared git repository. Obviously, they must not be able to see private files belonging to other customers. And there was no need for them to see my 10ys of history. So for a quick start, I just created a new repository with the files to be used. And to make things simpler (maybe more complicated now) I included the files from the submodule. Now I want to link the two repos so that I can merge new commits between the two repos. (git remote starts with a no common history warning ... so maybe some merge -s ours magic should be applied ... ? But the difference in submodules makes me doubt that this will be easy) To be sure not to import private object into B, merging one way B into A alone would be a helpful start. Ideally, I would to able to merge both ways. Is this possible at all? Or should I prepare to juggle with patch files? Thanks, Matt -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/QBXtZrkYVRMJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: help with combine repositories
Stafen, thank you for your reply, Am Freitag, 25. Mai 2012 13:49:52 UTC+2 schrieb Stefan: [...]There simply is no way to cherry-pick commits (or rebase branches) from B into A, since git has no way to know that they are even the same source tree, let alone have any common history among them. I did know about the different sha when they don't have a common history. I was under the impression, that I could actively tell git that two trees are the same. But it seems I was remembering wrongly, git merge -s ours does the opposite of what I want: merge in all the history without changing files :-( To simplify the problem a bit (forget about the submodule and changes files and two repositories for a moment): Suppose, I have a repository with history on master. Now I create a new branch new from nothing that includes all the same files as master, but no history. Just as if i created all the files now from scratch. master and new have no common history, right. But could I not merge new into master? There should not be any conflicts since all files are the same. (?) Or if it is seen as a conflict that I want to recreate an already existing file (even with the very same content), I could resolve this easily, by just adding either version. What am I missing here? I might try this experiment later and see what's happening. I suspect that it will not work that way even though I don't really understand why ... So, the way I see it, in your case you have but one choice, and that is to move patches from B to A (and backwards, if A is indeed active itself!) and applying them in the same sequence. Git also tries to make this easier for you by providing things like format-patch, send-email, apply, etc. right, applying patch-files, or even copying files over and checking them in again, that was my Plan B already. cheers Matt -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/DEWCBzSEMm4J. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
