> Another option is to do one TBR commit where you just fork the file > with no changes, then work again as normal.
May I suggest using gcl instead for this changelist... Would that be possible? I don't like the idea of losing all the commit history of the file he's working on, just because git doesn't correctly implement this... On Tue, Nov 3, 2009 at 09:50, Evan Martin <e...@chromium.org> wrote: > > Another option is to do one TBR commit where you just fork the file > with no changes, then work again as normal. > Pretty ugly though. :) > > On Tue, Nov 3, 2009 at 9:29 AM, Drew Wilson <atwil...@chromium.org> wrote: > > 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 <e...@chromium.org> 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 <erik...@chromium.org> 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 <e...@chromium.org> > 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. > >> >> <phajdan...@chromium.org> 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 <e...@chromium.org> > wrote: > >> >>>> > >> >>>> On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson <atwil...@chromium.org > > > >> >>>> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
