"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
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.
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
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at