[git-users] Re: help with combine repositories
On May 28, 9:15 am, Stefan Szabo wrote: > "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. Actually, it seems to be quite easy to "fake"(?) that locally by writing a .git/info/grafts file [From there, it seems, you could rewrite history with filter-branch to weld together those branches permanently. I don't want this so I did not look into this very deeply.] That would almost be what I need. Except that one of my branches includes files of what is a submodule in the other branch :-( > 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. Of course! That is the way git is supposed to work ;-) But in my case, history includes private objects that must not be shared. So I need two different histories ... > I'm not sure you can do that at all in git, i.e. branch from no commit. Yes you can: http://madduck.net/blog/2007.07.11:creating-a-git-branch-without-ancestry/ Alternatively, you could add an empty remote an clone an empty branch from there ;) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. 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
"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
> > 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. > or maybe this: what if I create an empty commit and rebase (or graft or whatever) master onto this empty commit. And the start my branch "new" from the same empty commit, put in all the files from master. Now they do share a common history. Even if it's only a silly empty folder that existed before time ;-) >From that common point, master made 10 years of incremental stuff, and new did the same in one big step. As far as I know, it should now be possible to merge new into master and git should be smart enough to see that the result is the same, so: no conflict. right? After that, I could continue to merge changes made in new into master. And cherry-pick changes made in master into new, if I want. If that works, and I feel it should, then the remaining question would be: why can't git just pretend that every random two branches share the same common "nothing" that existed before the first commit? ... and of course the problem with my submodule in one branch that is expanded into files in the other branch ... ;) -- 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/-/CAnRFkc0sR0J. 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.
[git-users] Re: help with combine repositories
Am Freitag, 25. Mai 2012 08:45:56 UTC+2 schrieb Thomas Ferris Nicolaisen: > > It could also be a job for the git subtree command, which was briefly > mentioned in another thread here recently: > https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt > > Thank you Thomas for your reply I will look into this subtree stuff and see if can help -- 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/-/W3-fPC48BnMJ. 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
Hi Matt, Anything is possible :) If I get this straight, you want new customer-development to take place in repo B. And then later on, get that development back into the big A? And then be able to continue developing in repo B? Cherry-pick or patches certainly sound like a straightforward way to handle this.. It could also be a job for the git subtree command, which was briefly mentioned in another thread here recently: https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt I haven't used subtree myself, but I imagine you could structure it like this: Repo A (10 years of history) \- subfolder1 \- subfolder2 Repo A` (export of repo A, little history) \- subfolder1 \- subfolder2 Now, start doing the customer's development in a new empty repository X: Repo X \- customer-stuff Now, use git submodule to import Repo X into both A and A`: Repo A (10 years of history) \- subfolder1 \- subfolder2 \- customer-stuff Repo A` (export of repo A, little history) \- subfolder1 \- subfolder2 \- customer-stuff Now, using git subtree, it should be possible to update Repo X with changes you do inside A or A` customer-stuff, and then sync it back to the other repo, in either direction. Note that the above is just a product of my imagination, I haven't tried it myself. If you are not very comfortable with Git in general and don't have time digging into how subtree works, you should probably just stick to using patches. On Thursday, May 24, 2012 5:40:52 PM UTC+2, 7ff wrote: > > 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/-/Drqh5EwHOboJ. 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.
