From: "Neal Kreitzinger" <neal@rsss.com>
To: git@vger.kernel.org
Subject: Re: merge removed content back into current content
Date: Tue, 28 Sep 2010 11:26:21 -0500 [thread overview]
Message-ID: <i7t52j$hl3$1@dough.gmane.org> (raw)
In-Reply-To: AANLkTimxHbCktv=kaq0UfV+u1kH1Pb2LYA2Xi=qkgduW@mail.gmail.com
>"Elijah Newren" <newren@gmail.com> wrote in message
> >news:AANLkTimxHbCktv=kaq0UfV+u1kH1Pb2LYA2Xi=qkgduW@mail.gmail.com...
>On Fri, Sep 24, 2010 at 9:06 PM, Neal Kreitzinger <neal@rsss.com> 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?
next prev parent reply other threads:[~2010-09-28 16:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-25 3:06 merge removed content back into current content Neal Kreitzinger
2010-09-25 23:43 ` Elijah Newren
2010-09-27 18:31 ` Eric Raible
2010-09-28 16:26 ` Neal Kreitzinger [this message]
2010-09-28 16:49 ` Neal Kreitzinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='i7t52j$hl3$1@dough.gmane.org' \
--to=neal@rsss.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.