Line wrapping email at under 80 columns would be nice. It makes it easier to read the message, and more importantly, easier to quote a few times during discussion. lmage11@xxxxxxxxxxxx wrote: > Therefore, I propose that git mv's behavior be changed. I think it > would make far more sense for a move to only change the actual name > of the file and to not pull in unstaged changes. In other words, > I'd like the index entry for the original file name to be removed > and an index entry to be added with a different name, but using the > exact same blob hash as the original file. I don't know exactly how > git manages the index internally, but a shortcut for this would be > to simply rename the index entry in place. I'm somewhat hesistant to change existing behavior, as users may be used to it or relying upon it within their scripts. But you make an excellent argument about why the current git-mv behavior is perhaps less than ideal. Elsewhere in git we use the --cached command line option to mean "only make the change in the index". For example the git-apply --cached option. You could start a patch that uses --cached to trigger the new behavior you propose and see if people are interested in changing the default once the feature is working and available for experimentation. > I'm willing to look into what changes would need to be made to the > code for this change to happen; I'm not asking for someone to do > all the work for me. :) > > So... Yeah. I'd like to know what people think about this before > I put a significant amount of effort into it. After all, we know > how lazy programmers are... :) See builtin-mv.c around l.264-283. This is where we are removing the old names from the index (in memory) and inserting the new names. Instead of calling add_file_to_cache() you would want to use something like add_cacheinfo() in builtin-update-index.c, specifying the old sha1, ce_flags and ce_mode. I'm sure Junio could probably give you a better starting point than I can, as he's more familiar with this sort of code, but that should still get you looking in the right direction and maybe get a working implementation together that you can share for discussion. -- Shawn. - 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
