Hi,

> ok, so, you need to go by an intermediary branch as git merge or rebase only 
> commits

It there a simpler way of doing this? In svn it just a "svn merge" followed by 
a "svn ci" - assuming you're happy with the merge.

If we want to merge the entire tree would we follow the same process? (eg like 
what we have to do after a release) Do you have to do a git mergeTool on every 
file?

Lets give that a try:

> git checkout -b temp
> git checkout origin/release4.9 RELEASE_NOTES <FILE2> <FILEX>

OK I ran "git checkout origin/release4.9 RELEASE_NOTES README" and a "git 
status" only show README changed, however "git diff README" shows no changes, 
ignoring that I continue.

> git add -u

Why is "-u" needed?

> git commit -m "Merge RELEASE_NOTES, etc.. from release4.9 branch"

A bit scary:
 1 file changed, 36 insertions(+), 63 deletions(-) 

Why did it do this when "git diff" showed no changes?

> git checkout develop

Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 1 commit.
  (use "git push" to publish your local commits)

Think that's OK.

> git rebase temp

At this point if I do a git status I get:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
#   (use "git push" to publish your local commits)
#
nothing to commit, working directory clean

Which is a little strange as I would of expected changed from the "git checkout 
develop".

> git mergeTool RELEASE_NOTES

Gives "No files need merging"

So I assume no need to to do a  "git rebase --continue"?

Try "git mergeTool README" and I also get "No files need merging"

This is not what I expected I know it made changes to the file in the commit 
above.

git status give at this point:
# On branch develop
# Your branch is ahead of 'origin/develop' by 2 commits.
#   (use "git push" to publish your local commits)
#
nothing to commit, working directory clean

What are here 2 commits when I've only done one?

> git branch -d temp
deletes branch

If at this point if I do this "git diff --stat origin/develop" I get:
 README        | 99 
++++++++++++++++++++++++++++++++++++---------------------------------------------------------------
 RELEASE_NOTES | 26 +++++++++++++++++++++++++-

Why is it saying both README and RELEASE_NOTES have changed when only one file 
was changed with the commit? 

Looking at the changes (via "git diff origin/develop") to README I see that it 
has merged the files incorrectly and certainly not what I expected. It's 
removed the more recent changes about FP 11.7 and AIR 3.7, using git rather 
than svn and changes to TLF but it did add the single line that changed the 
version number 4.9 to 4.9.1. RELEASE_NOTES have similar issues. Why did this 
not merge as expected?

Why did "git mergeTool" say in both cases "No files need merging" when it 
obviously has (incorrectly) merged the files?

Obviously Im not an expert git user and just know enough to keep getting myself 
into trouble. :-) I am just trying to understand what is going on here as 
currently it really doesn't make any sense to me at all and worse looks like it 
done the merge mostly in reverse?

Thanks,
Justin

Reply via email to