Hi Beson, The problem is that by this approach the rename gets a delete and add with full file content, versus a native SVN rename (which is a svn cp followed by a delete of the original file). By this the history is lost, because for SVN you patch looks like a complete removal of the original file and a later addition of a totally new file. With a native SVN rename, you would see changes to the old file also in the history of the new file. You would even see the file content changes of the commit renaming the file in svn's diff. Now you cannot see the differences between old and new file, because its just a big blob removed/added.
Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Benson Margulies [mailto:[email protected]] > Sent: Tuesday, February 18, 2014 2:17 PM > To: [email protected] > Subject: Re: Refactoring code through Github pull requests > > I tried using git apply on a patch (from github's .patch URL) that included a > rename. no sign of a rename; just a delete and an add. I feel like I'm missing > something. > > On Tue, Feb 18, 2014 at 7:36 AM, Shai Erera <[email protected]> wrote: > > The problem I see is that if you generate a patch using 'git diff', it > > applies just fine to svn (if you generate it w/ --no-prefix) without > > any warnings about missing files due the rename. Wanted to warn the > > community about it, so that when committers assign themselves to PRs, > > they review the patch closer and detect manually if a rename as happened. > > > > We could decide that renames are done in a separate commit, but it's > > not always possible. > > > > So mainly, FYI. > > > > And if someone has an idea for a script/ant-target we could write to > > detect this case, that would be awesome. > > > > Shai > > > > > > On Tue, Feb 18, 2014 at 2:31 PM, Thomas Matthijs <[email protected]> > wrote: > >> > >> Github pull requests can be treated as individual cherry picked patch > >> sets really, not branch merges ? (ie rebased) from there on out > >> you're in svn land. No need to "merge". > >> > >> But indeed, it tries to detect it based on the file content, and > >> doesn't work 100% as manual svn moves. > >> > >> > >> > >> On Tue, Feb 18, 2014 at 1:27 PM, Benson Margulies > >> <[email protected]> > >> wrote: > >>> > >>> Well, git-svn has a heap of warnings against using it for merges; > >>> it's also a really bad idea when renaming a whole package, as it > >>> does it one-file-at-a-time. > >>> > >>> If you have a workflow that works with the ASF mirror and svn, > >>> please write it up on the Wiki! > >>> > >>> > >>> On Tue, Feb 18, 2014 at 7:23 AM, Thomas Matthijs <[email protected]> > >>> wrote: > >>> > > >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <[email protected]> > wrote: > >>> >> > >>> >> > >>> >> Second, has anyone perhaps found a way to overcome that issue? I > >>> >> thought about maybe writing a script to detect that, looking at > >>> >> the patch file, but it seems hard to detect that the deleted Foo > >>> >> is the new Bar. If it's just rename, maybe, but if part of the > >>> >> rename the code changed a lot ... it becomes harder. > >>> > > >>> > > >>> > Probably not the answer you want but If you use the git-svn bridge > >>> > it should detect the rename and commit it in svn as a move/copy > >>> > > >>> > https://www.kernel.org/pub/software/scm/git/docs/git-svn.html > >>> > >>> -------------------------------------------------------------------- > >>> - To unsubscribe, e-mail: [email protected] For > >>> additional commands, e-mail: [email protected] > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
