Chris Shoemaker <c.shoemaker@xxxxxxx> writes: > On Mon, Dec 10, 2007 at 03:49:39PM +0100, Florian Weimer wrote: > > * Jakub Narebski: > > > > > + <s id="git"> > > > + Yes (or no depending on interpretation). Git > > > > This should be "No." (same for copies below). > > ISTM that people are stuck using less than helpful criteria for > judging whether renames are supported. Namely, in effect, they ask: > "Does the user get to do extra work in order to get rename-detection?" > > Let me humbly suggest an alternate, two-fold, very practical criteria > that I actually care about as a user: > > 1) If I edit file A, while another developer renames file A to B, and > I merge my work with his, do I have to clean things up myself, or does > everything Just Work? The only thing Git doesn't implement _yet_ is when you have renamed a directory, and another developer created a new file in the old directory name. Currently Git creates new files in old directory. Note however that moving files to other directory might need changes in files: for example Java, or header files includes in C/C++. This is not very common, though. BTW. this issue is in TODO for "Better SCM : Comparison" * Add intelligent merging of renamed paths. > 2) If I'm browsing the history of some code in a renamed file, does > the history continue through the rename? And Git does support it in both "git blame" (or "git gui blame"), and in "git log" thanks to --follow option. Note however that --follow cannot be used (yet?) with directories or pathspecs. Not that other SCMs support wildcard pathspec limiting... > By these criteria, git certainly does support renames. That's why I wrote "Yes", adding "or no" (as suggested by Robin Rosenberg) because it does it dofferently than other SCMs. -- Jakub Narebski Poland ShadeHawk on #git - 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
