Oh sorry, you were in GIT world. My response does not apply for you :-) Regards, Uwe (GIT ignorant)
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Uwe Schindler [mailto:[email protected]] > Sent: Tuesday, February 18, 2014 2:24 PM > To: [email protected] > Subject: RE: Refactoring code through Github pull requests > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
