Re: How can I use git to help me merge a patch with the new directory structure

[Carl Sorensen]

On 7/26/09 11:35 AM, "Johannes Schindelin" <address@hidden>
wrote:

> Hi,
> 
> On Sat, 25 Jul 2009, Carl Sorensen wrote:
> 
>> As you're aware, I've been working on a patch for autobeaming.
>> 
>> It affects c++, scheme, and documentation files.
>> 
>> Now I want to apply the patch to master.  But the problem is that all of
>> the documentation files have moved to Documentation/ISOLANG/notation
>> instead of Documentation/ISOLANG/user
>> 
>> So this seems to break any means of making my patch apply.
>> 
>> Any git gurus out there who have an idea of how I can do this without
>> having to manually apply patches made between the files in the different
>> directories?
> 
> You should be ablt to use "git cherry-pick <commit>" on the branch you
> want to port this commit to.  This will perform a rename-aware 3-way
> merge.

I tried that, but I don't know how to make it work properly.

sorensen2:lilypond-working Carl$ git cherry-pick new-beam-settings
warning: too many files (created: 526 deleted: 717), skipping inexact rename
detection
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and
commit the result.
When commiting, use the option '-c bd43152' to retain authorship and
message.


So far, so good, I think.



sorensen2:lilypond-working Carl$ git mergetool
merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge
vimdiff
Merging the files: Documentation/es/user/rhythms.itely
Documentation/fr/user/rhythms.itely
Documentation/topdocs/NEWS.tely
Documentation/user/music-glossary.tely
input/lsr/chordchanges-for-fretboards.ly
input/lsr/making-slurs-with-complex-dash-structure.ly
input/lsr/non-default-tuplet-numbers.ly
input/lsr/non-traditional-key-signatures.ly
scm/define-context-properties.scm
scm/define-music-display-methods.scm

Deleted merge conflict for 'Documentation/es/user/rhythms.itely':
  {local}: deleted
  {remote}: modified
Use (m)odified or (d)eleted file, or (a)bort?

So at this point, I get the choice to use the modified file (which will be
in the wrong directory), or the deleted file (which is in the right
directory).  Neither choice seems to be right.


If I choose d, the file never gets added to the commit (but there should be
modifications to the file).

If I choose m, the file gets added to the commit as a *new* file, in the
*old* path.

The files that didn't have merge conflicts appear to have worked just fine,
with modified commits in the new directory locations.  But the files with
merge conflicts don't seem to be working properly.

Any detailed suggestions you could give me would be much appreciated.

Thanks,

Carl





> 
> Ciao,
> Dscho