On Tue, Feb 18, 2014 at 8:24 AM, Uwe Schindler <[email protected]> wrote: > 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, that's precisely what I'm chasing. I thought, some years ago, that I'd seen git svn do a real svn mv, but this morning's experiments do not lead me to believe that this can be arranged with the tools at hand. > > 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]
