John, thanks for your response, I will experiment with your suggestions.
Let me clarify details of what I was saying-- I'm not sure if I'm able to
express my concern clearly.

Both of these repositories ("jtrmal", "vimal") were created from the same
svn repository, using git svn clone.
The master branches on both repos are the same (up to a few last commits,
because they were sync'd at different times) content-wise, the git-svn id's
in the logs are the same, only the sha numbers, are different. I don't
understand the reason for that, but I assume there is some randomness while
initiating the git repository. IIRC the shasum of the commit is sha(content
of the commit+sha of the parent).

Now, imagine I want to integrate vimal/diarization (or any other
vimal's branch) in my master (let's keep the discussion if it makes sense
or not aside -- just assume that the svn does not exist anymore and we
declared my repo as the "official" and we want to add a brand new feature).
How will git approach this problem given the fact that jtrmal/master and
vimal/diarization do not have a single common commit in the revision graph?
How can I align/overlay my master and his master so that git would be able
to infer the correct dependecies between these two masters and the depended
A simple merge generated ~1000 conflicts which, I believe are not because
there would be so many conflicting files but simply because git has
problems figuring out the dependency graph.

Thanks a lot

On Mon, Jul 20, 2015 at 1:17 PM, John McKown <>

> On Mon, Jul 20, 2015 at 9:16 AM, Yenda Trmal <> wrote:
>> Guys,
>> this might be a trivial or already answered question, but I'm not able to
>> find anything on the subject (perhaps I'm not sure what to ask about in the
>> git terminology).
>> As a background -- we are planning to migrate Kaldi from the svn
>> repository to github.
>> There are already Kaldi repositories in github (created by git svn clone
>> and pushing to github), created by independent developers.
>> As far as I understand, looking at the sha sums, from git POV these are
>> completely different repositories.
>> Is there some way how to explain to git, that content-wise, these are the
>> same directories?
>> To give you a concrete example:
>> Let's take these two repositories
>> They share the trunk (master),  but  when I clone my repo:
>> ​​
>> git clone
>> ​​
>> git remote add vimal
> ​I have looked at the above two repos in my browser. Looking at the
> commits going backwards in time, it appears to me that the vimal-manohar91
> last shared commit on Jun 18, 2015. The commit, in jtrmal/kaldi looks like:
> commit 1afc4b3c4731258c5ca9889b533152404b0667ce
> Author: Guoguo Chen <>
> Date:   Thu Jun 18 03:56:43 2015 +0000
>     trunk: adding LogSoftmax component to nnet2 setup
>     git-svn-id:
> 5e6a8d80-dfce-4ca6-a32a-6e07a63d50c8
>> and then for example:
>> git checkout dur-model
>> git merge vimal/DCCA
>> will generate a conflict for (possibly) every file in the repository and
>> will auto-resolve most/some of them, but there still be ~1000 conflicted
>> files. That is a nightmare.
>> Is there some way how to "explain" git that these two repositories are
>> (almost) the same, content-wise?
> ​Why are you trying to merge the dur-model with vimal/DCCA? dur-model
> appears, to me, to be UNIX/Linux code whereas DCCA is Windows code. I don't
> really know what you are trying to accomplish, but if you want to get the
> vimal branches into your repo, then the following might be what you should
> do:
> git checkout -b vimal/DCCA​
> git push --set-upstream origin/DCCA
> git checkout -b vimal/Queue
> git push --set-upstream origin/Queue
> git checkout -b vimal/Semisupervised_DCCA
> git push --set-upstream origin/Semisupervised_DCCA
> git checkout -b vimal/diarization
> git push --set-upstream origin/diarization
> git checkout -b vimal/multilingual
> git push --set-upstream origin/multilinugal
> git checkout master
> ​Now there is a problem in that your "master" and "vimal/master" have some
> conflicts.​ I don't know enough about your code to make any recommendations.
>> Thanks a lot,
>> yenda
>> --
> Schrodinger's backup: The condition of any backup is unknown until a
> restore is attempted.
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
> He's about as useful as a wax frying pan.
> 10 to the 12th power microphones = 1 Megaphone
> Maranatha! <><
> John McKown
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to