I worked around the problem using these steps.

   1. git merge toBisque
   2. git mergetool -t p4merge
   3. wait for git to prompt to run p4merge
   4. In another command prompt use git show 
   ${MERGE_BASE_HASH}:${FILE_PATH} > 
   ${FILE_PATH_LESS_EXTENSION}.BASE.${MERGE_NUM}.${FILE_EXTENSION}
   5. Then hit enter on the git mergetool prompt to run the merge tool.  In 
   this way I stomp on the bad merge BASE file and replace it with the good 
   one from the repo.  
   6. Resolve merge as normal in mergetool
   7. Rinse and repeat steps 3-6 for each file

I had the same problem with meld.  Both p4merge and meld are supported by 
git out of the box.  I had to update the path used for meld but otherwise 
the merge configuration is generally unmodified.  Here is my git config:

> [user]

name = Michael Power

email = you can image what goes here

[core]

autocrlf = input

filemode = false

[difftool "sourcetree"]

cmd = 'C:/Programs/KDiff3/kdiff3.exe' \"$LOCAL\" \"$REMOTE\"

[mergetool "sourcetree"]

cmd = 'C:/Programs/KDiff3/kdiff3.exe' \"$BASE\" \"$LOCAL\" \"$REMOTE\" -o 
> \"$MERGED\"

trustExitCode = true

[color]

ui = true


> [merge]

    tool = meld

defaultToUpstream = true

[mergetool "meld"]

    prompt = false

    keepBackup = true

    keepTemporaries = true

    path = meld.exe

[push]

default = current

  


I tried with current git version of 1.9.0 and I reverted back to 1.8.3 to 
see if that fixed this problem.  Both 1.8.3 and 1.9.0 exhibited the same 
behavior so I reinstalled 1.9.0.  Here is the output of the command with 
some useless information dropped

> $ git config -l | grep -v "^branch" | grep -v "^remote" | grep -v 
>> "^user.email"
>
> core.symlinks=false
>
> core.autocrlf=input
>
> color.diff=auto
>
> color.status=auto
>
> color.branch=auto
>
> color.interactive=true
>
> pack.packsizelimit=2g
>
> help.format=html
>
> http.sslcainfo=/bin/curl-ca-bundle.crt
>
> sendemail.smtpserver=/bin/msmtp.exe
>
> diff.astextplain.textconv=astextplain
>
> rebase.autosquash=true
>
> user.name=Michael Power
>
> core.autocrlf=input
>
> core.filemode=false
>
> difftool.sourcetree.cmd='C:/Programs/KDiff3/kdiff3.exe' "$LOCAL" "$REMOTE"
>
> mergetool.sourcetree.cmd='C:/Programs/KDiff3/kdiff3.exe' "$BASE" "$LOCAL" 
>> "$REMOTE" -o "$MERGED"
>
> mergetool.sourcetree.trustexitcode=true
>
> color.ui=true
>
> merge.tool=meld
>
> merge.defaulttoupstream=true
>
> mergetool.meld.prompt=false
>
> mergetool.meld.keepbackup=true
>
> mergetool.meld.keeptemporaries=true
>
> mergetool.meld.path=meld.exe
>
> push.default=current
>
> core.repositoryformatversion=0
>
> core.filemode=false
>
> core.bare=false
>
> core.logallrefupdates=true
>
> core.ignorecase=true
>
> merge.defaulttoupstream=true
>
>
I think this is caused by the complicated nature of the merge I am doing. 
 Here is the background.  I start with a git project structured like the 
following.  For the sake of description this was release branch R1

> /pom.xml - for webapp
> /src - for webapp 


 I wanted to create sub modules but that is not possible as the root pom is 
actually a webapp.  So I created a sub folder with a root pom inside of it. 

> /pom.xml - for webapp usring webapp-parent for root
> /src - for webapp 
> /webapp-parent/pom.xml - root pom, adding ".." as module


For the next release I decided to get ahead of this bad folder structure by 
moving things around.  I did this on the new release branch R2

> mkdir webapp
> git mv pom.xml webapp/
> git mv src/ webapp/
> git mv webapp-parent/pom.xml .
> git commit -m "Commit move without changing contents of file"
> vim webapp/pom.xml - update parent path
> vim pom.xml - update child path
> git commit -m "Update files to match new path"

This worked good at first.  But did not work so well when I tried to merge 
R1 to R2.  Since /pom.xml exists in both R1 and R2 git did not pickup that 
the original file was moved to /webapp/pom.xml in R2 and /pom.xml in R2 
actually mapped back to R1 /webapp-parent/pom.xml

I decided I could resolve the problem with some incremental moves with 
branches inbetween R1 and R2.  Currently I have a PostR1, PreR2, and ToR2 
branches.  I merge from R1 to PostR1 then PostR1 to PreR2, then PreR2 to 
ToR2, then finally ToR2 to R2.  It ran smoothly until I ran the merge ToR2 
to R2 then the BASE file was corrupted.  

To my best recollection here is the changes I made to create the bridge 
branches PostR1, PreR2, ToR2.  Git was failing because the 
webapp-parent/pom.xml was moved to /pom.xml which was where the 
webapp/pom.xml file used to be.  What I needed to do was merge a couple 
times each time merging through a part of the move.

So with R1 checked out I did the following

> git checkout -b PostR1
> mkdir webapp/
> git mv pom.xml webapp/
> git mv src/ webapp
> git commit -m "Step one move webapp out of the way"


So this was half of the move, now I can merge R1 to PostR1 and git will 
follow the move.  Next I need to move the webapp-parent/pom.xml

> git checkout -b PreR2
> git mv webapp-parent/pom.xml .
> git commit -m "Now with the changes to /pom.xml merged into 
> /webapp/pom.xml it is safe to move the webapp-parent/pom.xml to /pom.xml"


 Now I can merge PostR1 to PreR2 and git will follow the move from 
/webapp-parent/pom.xml to /pom.xml.  At this point I think I wanted to play 
it safe so I created a copy of R2 to merge into

> git checkout R2
> git checkout -b ToR2
> git merge PreR2


This method of merging through multiple merges worked several times until 
my OS was replaced.  Then after reinstalling and switching from cygwin to 
msys I got this BASE file corruption. 

I have my work around.  So this is no longer an issue for me, just extra 
busy work.  Seems to me merge annotations in the BASE file is a bug, and no 
one would know what to do with them.  As evidenced by the fact that I just 
stomped them with the actual merge-base file and moved on.  
 

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

Reply via email to