From: Jay Soffian <jaysoffian@gmail.com>
To: git <git@vger.kernel.org>
Subject: merge recursive and code movement
Date: Thu, 24 Mar 2011 17:18:20 -0400 [thread overview]
Message-ID: <AANLkTi=h6jUsjqXofd0QeWbNBjc9DeodJJ3FN7caW4XC@mail.gmail.com> (raw)
There's a use case that merge recursive doesn't seem to handle, and I
wonder how difficult it would be to add.
Say you have a merge between OURS and THEIRS, with common ancestor BASE.
Between BASE and THEIRS, a file named header.h has the following changes:
# Rename header.h to header_new.h
git mv header.h header_new.h
# Minor edits to account for the rename such as fixing the
# include guard:
perl -pi -e 's/HEADER_H_/HEADER_NEW_H_/' header_new.h
# Drop a compatibility header.h in place till we can fix all the
# files which include header.h
cat > header.h <<-__EOF__
#ifndef HEADER_H_
#define HEADER_H_
#include "header_hew.h"
#endif // HEADER_H_
__EOF__
git add header.h header_new.h
git commit -m 'rename header.h to header_new.h'
Meanwhile, between BASE and OURS, a few minor changes are made to
header.h. This could be as little as a single line change in the
middle of the header.h.
Now you merge THEIRS to OURS. Git will just show header.h in conflict.
99% of the time I can do the following:
git diff MERGE_BASE... header.h | patch header_new.h
git checkout --theirs header.h
git add header.h header_new.h
But it would seem like this is something merge recursive should be
capable of handling on its own.
j.
next reply other threads:[~2011-03-24 21:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 21:18 Jay Soffian [this message]
2011-03-25 9:37 ` merge recursive and code movement Jeff King
2011-03-25 10:12 ` Jeff King
2011-03-25 11:12 ` Jeff King
2011-03-25 16:00 ` Jeff King
2011-03-25 16:03 ` [PATCH 1/3] t3030: fix accidental success in symlink rename Jeff King
2011-03-25 17:42 ` Junio C Hamano
2011-03-25 17:51 ` Jeff King
2011-03-25 18:25 ` Schalk, Ken
2011-03-25 16:06 ` [PATCH 2/3] merge: handle renames with replacement content Jeff King
2011-03-25 16:08 ` [PATCH 3/3] merge: turn on rewrite detection Jeff King
2011-03-25 17:32 ` merge recursive and code movement Jay Soffian
2012-07-16 0:17 ` Techlive Zheng
2012-07-16 12:26 ` Jeff King
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='AANLkTi=h6jUsjqXofd0QeWbNBjc9DeodJJ3FN7caW4XC@mail.gmail.com' \
--to=jaysoffian@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).