On Mon, Jul 20, 2015 at 1:45 PM, Jan Trmal <jtr...@gmail.com> wrote:
> 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
> branches?
> 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
> y.
>
>
I am not a git internals person. But I think you may have a
misunderstanding. git doesn't use a "dependency graph" to do merges. git
has two types of merges. The first is the "fast forward" merge. This is
where the desktop repository is at a previous level (commit SHA-1) of the
remote repository, with no changes. So git just copies the files from the
remote repository into the working directory and commits them. The second
is a "non fast forward" merge (SHA-1 commit value is not in the list of
commits in the remote). This is what you are experiencing. In this case the
desktop repository has changes which are not in the remote repository. What
git does, in effect, is compares each file (contents) in your working
directory with the equivalently named file (contents) in the remote
repository. If there are incompatible changes, this is a "conflict". An
incompatible change would be like a file in which you deleted some lines,
and added others, where the remote repository added or deleted other lines.
In this case, git doesn't know what do to, and so it changes the file in
the working directory so that you can edit it and "harmonize"(?) the
changes. This is basically what you must do.
I basically did the following:
git clone https://github.com/jtrmal/kaldi
git remote add virmal https://github.com/vimal-manohar91/kaldi-git
git fetch --all #load up everything
This resulted in the following branches (git branch -a)
* master
remotes/origin/HEAD -> origin/master
remotes/origin/dur-model
remotes/origin/master
remotes/origin/mixer6
remotes/origin/scale-pashto
remotes/vimal/DCCA
remotes/vimal/Queue
remotes/vimal/Semisupervised_DCCA
remotes/vimal/diarization
remotes/vimal/master
remotes/vimal/multilingual
I then did the command: git diff --name-status master vimal/master . This
command tells the a summary of what files are added, deleted, and modified.
There were 7 files added, 99 files deleted, and 141 files modified. If you
want to see what the modifications are, do the command: git diff master
vimal/master . This basically will show you a "patch" deck which details
the changes. I went ahead and did a "git merge virmal/master". It did show
1,437 files with conflicts. I have no idea why that is so much higher that
what the --name-status report said. And I really don't know what you should
do about the differences.
What you could do is keep the vimal/master (which seems to say a lot about
Windows) separate is to just give it a different name.
git checkout dur-model #switch away from master
git branch -m master linux-master
git checkout -b vimal/master #get the Windows version of master
git checkout dur-mode #switch away from it
git branch -m master Windows-master
git push --set-upstream origin Windows-master
git branch -m linux-master master #put the Linux code back as master
git push --mirror # upload everything.
Hopefully a real git expert will chime in to correct any mistakes I've made.
git pu
--
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 the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
