Re: merge removed content back into current content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>"Elijah Newren" <newren@xxxxxxxxx> wrote in message 
> >news:AANLkTimxHbCktv=kaq0UfV+u1kH1Pb2LYA2Xi=qkgduW@xxxxxxxxxxxxxxxxx
>On Fri, Sep 24, 2010 at 9:06 PM, Neal Kreitzinger <neal@xxxxxxxx> wrote:
>> How do I tell git to merge a single program from an old commit into the
>> current version of that program in the HEAD commit? In this scenario, I
>> want to get back some removed code but still keep the new code.
>>
>> e.g.
>>
>> Commit-1 = initial commit containing Program-A, and other programs
>>
>> Commit-2 = add Changeset-1 to Program-A , and make changes to other 
>> programs
>>
>> Commit-3 = remove Changeset-1 from Program-A, then add Changeset-2 to
>> Program-A, and make changes to other programs
>>
>> *desired* Commit-4 = only merge Program-A from Commit-2 into Program-A of
>> Commit-3, and don't change any other programs
>> (in other words, get my old changes from Commit-2 back, but don't loose 
>> the
>> new changes from Commit-3)
>
>Does something like:
>  git diff commit1 commit2 -- ProgramA | git apply
>do what you need?
>
All of our source conflicts because we add a user/datestamp to the first 
line.  We do this to insure the programmer reviews the merge.
However, I never used git apply before so that was interesting to learn.

>If diff+apply doesn't work[1], you can try
>  git cat-file -p commit1:ProgramA > base
>  git cat-file -p commit2:ProgramA > other
>  git cat-file -p commit3:ProgramA > current
>  git merge-file current base other
>
This method is also something new to me, but it seems too manual.  It also 
does not do the normal git merge where the results are in the index.  An 
easier method is to do this:
git difftool commit1 commit2 -- ProgramA
and then use kdiff3's merge option.  this does not include the common 
ancestor as a reference like a normal git merge conflict followed by git 
mergetool (kdiff3), but is user friendly.  However, I'm not crazy about it 
because I'd rather have the merge results in the index and use git mergetool 
like I do for commit merges.

>[1] e.g. would cause conflicts -- btw, does anyone know how to force
>git apply to proceed and add conflict markers if necessary rather than
>just bailing out? 



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]