In my case, git didn't quite figure out that my refactoring (splitting a file into two) should also link up the new file to the history of the old.
There are magic flags I could pass (-C<n>) to make git more aggressive about matching up files to histories, but it turns out that passing those flags also generates a bunch of false positives (at least in my case): git thought that unrelated files were actually copies of one another. In the end, I'm probably just going to land the patch via svn and manually setup the history linkage via svn copy. -atw On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin <[email protected]> wrote: > Generally it should Just Work. If it doesn't, I'd like to hear about it. > > http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies > > On Tue, Nov 3, 2009 at 9:16 AM, Erik Kay <[email protected]> wrote: > > Are there best practices we can follow that will help the scripts be > > more accurate? For example, if we move the file, make sure that we > > commit it in the new location before making any text changes? If so, > > we could at least document that. > > > > Erik > > > > > > On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin <[email protected]> wrote: > >> > >> I'm not sure which news you're referring to. :) > >> > >> To answer Jeremy's request: briefly, git doesn't track renames at all > >> (which are conceptually differences between versions) which makes > >> sense when you consider what it does track (conceptually, only > >> collections of files and an ordering between collections). Instead, > >> tools like "git diff" know how to infer renames from the content, and > >> then the Rietveld uploader sorta knows how to munge them into a > >> Subversion-compatible format. (And when you dcommit to svn it > >> converts those inferred renames into real renames.) It usually works > >> pretty well except when it doesn't. > >> > >> If you can convince "git diff" through some combination of flags that > >> a rename or copy happened, then that info can be communicated to svn. > >> > >> So two sources of glitches: (1) can't convince git that two files are > >> related, typically because the text between them is too different; (2) > >> the Rietveld uploader isn't synthesizing Subversion renames well > >> enough. (2) is a bug that I (or realistically, you) can fix, while > >> (1) frequently means that tracking that history doesn't really matter > >> too much. > >> > >> On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. > >> <[email protected]> wrote: > >>> That's a good news. Can that info be put somewhere in the UsingGit wiki > >>> page? > >>> > >>> On Mon, Nov 2, 2009 at 23:56, Evan Martin <[email protected]> wrote: > >>>> > >>>> On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson <[email protected]> > wrote: > >>>> > I'm doing some refactoring in the chromium worker code, and I got > the > >>>> > following review feedback: > >>>> > "small request: can the files that were branched from existing files > be > >>>> > "svn > >>>> > copy'd" instead of copying manually and "svn added"? This will > preserve > >>>> > history > >>>> > and will make it easier to see what changed in the review." > >>>> > Is there a way to do this with git? I do want to make my reviewers > happy > >>>> > :) > >>>> > >>>> Git has an ...odd... way of thinking about renames. The pieces you > >>>> need to know are: > >>>> 1) Does git believe you did a rename? Consult "git diff -M -C --stat > >>>> origin..." and see if it prints renames. > >>>> 2) If no, ping me off-list and I'll help you out. > >>>> 3) If yes, Rietveld should be able to display the diff properly. > >>>> However, this code is relatively untested (we have to convert the Git > >>>> renames into SVN-style "renames" -- SVN doesn't actually support true > >>>> renames, oddly enough) so it could be wrong. In that case, also ping > >>>> me off-list. :) > >>>> > >>>> >> > >>> > >>> > >> > >> > >> > >> > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
