"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.
