Can someone comment whether supporting merges after renames will be on
the Git roadmap?
As a Java developer, I can say that refactoring of class names and
packages happens quite often. Having to remember I've made this change
throughout the lifetime of a branch (or master, until pushed to a
central repository), and needing to manually merge changes to files /
packages (directories) I've refactored is something that I want my VCS
to do.
Thank you,
Ittay
Jeff King wrote:
On Thu, May 01, 2008 at 12:12:33PM -0700, Steven Grimm wrote:
However, that leaves the question of which default will be wrong the
least often.
In my personal experience, I think a directory rename has almost always
meant that I would want new files to appear in the new directory rather
I do agree that the rename is probably more often desired.
Of course, the discussion is moot anyway until someone writes code to
detect the situation; my impression is the current behavior is the way it
is simply because it's what naturally happens in the absence of
merge-time detection of a directory getting renamed.
Yes, I think that is largely a correct impression (although I think
Linus has spoken out against directory renaming in the past, so there is
at least a little bit of conscious effort). I suspect the right sequence
of steps to implement this would be:
1. write a proof-of-concept that shows directory renaming after the
fact (e.g., take a conflicted merge, scan the diff for directory
renames, and then fix up the files). That way it is available, but
doesn't impact git at all.
2. If people think it is useful, build it into the diff and merge
machinery so that it can happen automagically, but make it
optional. Thus git fully supports it, but the policy decision is
left up to the user.
3. Make it the default if it is the common choice.
So we just need somebody to volunteer to work on 1. ;)
-Peff
--
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
--
Ittay Dror <ittayd@xxxxxxxxxx>
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
--
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
