You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Shai Erera <se...@gmail.com> on 2014/02/18 13:18:56 UTC
Refactoring code through Github pull requests
Hi
I tried to understand how do I merge changes that involve code refactoring,
e.g. class rename, from github to our SVN. I had such a need, but I also
thought about this issue, now that we accept PRs. So the scenario is this:
- In your git clone, you rename class Foo to Bar
- In order to commit that rename to Apache SVN, you need to create a diff
and apply it to the svn checkout
- If you just run 'patch' or 'svn patch', the commit loses the file history
of Foo, as it's just deleted and Bar is added as a new class
I asked around and seems that some people were already aware of that, and
before applying the patch they replay the moves manually by running 'svn
mv'.
I tried w/ regular SVN workflow, and turns out if you rename in the SVN
checkout, 'svn diff' and then 'svn patch', this doesn't work as well.
Only, when you 'svn patch', you get an error that Bar isn't found, so you
know something's wrong. But in the git workflow, it just works since Foo is
marked as deleted and Bar is marked as Added. As if you ran 'svn diff
--show-copies-as-adds".
So first, wanted to alert people, especially when we merge PRs (since it's
not us doing the rename).
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.
Shai
Re: Refactoring code through Github pull requests
Posted by Benson Margulies <bi...@gmail.com>.
Thomas, please help us comparative git ignoramuses, and detail the
sequence of commands you would use with git-svn to apply a PR,
starting from your fork/clone setup.
On Tue, Feb 18, 2014 at 7:31 AM, Thomas Matthijs <li...@selckin.be> 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 <bi...@gmail.com>
> 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 <li...@selckin.be> wrote:
>> >
>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Refactoring code through Github pull requests
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Tuesday, February 18, 2014 2:24 PM
> To: dev@lucene.apache.org
> 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: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Benson Margulies [mailto:bimargulies@gmail.com]
> > Sent: Tuesday, February 18, 2014 2:17 PM
> > To: dev@lucene.apache.org
> > 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 <se...@gmail.com> 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 <li...@selckin.be>
> > 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
> > >> <bi...@gmail.com>
> > >> 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
> > >>> <li...@selckin.be>
> > >>> wrote:
> > >>> >
> > >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com>
> > 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: dev-unsubscribe@lucene.apache.org For
> > >>> additional commands, e-mail: dev-help@lucene.apache.org
> > >>>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Refactoring code through Github pull requests
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Feb 18, 2014 at 8:24 AM, Uwe Schindler <uw...@thetaphi.de> 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: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Benson Margulies [mailto:bimargulies@gmail.com]
>> Sent: Tuesday, February 18, 2014 2:17 PM
>> To: dev@lucene.apache.org
>> 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 <se...@gmail.com> 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 <li...@selckin.be>
>> 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
>> >> <bi...@gmail.com>
>> >> 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 <li...@selckin.be>
>> >>> wrote:
>> >>> >
>> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com>
>> 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: dev-unsubscribe@lucene.apache.org For
>> >>> additional commands, e-mail: dev-help@lucene.apache.org
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Refactoring code through Github pull requests
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: Tuesday, February 18, 2014 2:17 PM
> To: dev@lucene.apache.org
> 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 <se...@gmail.com> 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 <li...@selckin.be>
> 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
> >> <bi...@gmail.com>
> >> 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 <li...@selckin.be>
> >>> wrote:
> >>> >
> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com>
> 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: dev-unsubscribe@lucene.apache.org For
> >>> additional commands, e-mail: dev-help@lucene.apache.org
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Refactoring code through Github pull requests
Posted by Benson Margulies <bi...@gmail.com>.
See https://wiki.apache.org/lucene-java/BensonMargulies/GitSvnWorkflow
for an experiment with git svn.
On Tue, Feb 18, 2014 at 1:47 PM, Benson Margulies <bi...@gmail.com> wrote:
> Once I have transported a change from branch to branch via diff\apply, git
> stops discussing a rename at all.
>
> On February 18, 2014 9:06:30 AM EST, Thomas Matthijs <li...@selckin.be>
> wrote:
>>
>> Unfortunately i can't find a way to make it explicitly show it will do a
>> svn rename, but it does do it, so that makes this solution not very useful
>> either i guess.
>>
>>
>> --- git ---
>> [master svntest] % git status
>> On branch master
>> Changes to be committed:
>> (use "git reset HEAD <file>..." to unstage)
>>
>> renamed: test -> moo
>>
>> [master svntest] % git commit -m "woof"
>> [master 6e2c0b3] woof
>> 1 file changed, 0 insertions(+), 0 deletions(-)
>> rename test => moo (100%)
>> [master svntest] % git svn dcommit
>> Committing to https://.../trunk ...
>> R test => moo
>> Committed r3
>> D test
>> A moo
>> W: -empty_dir: trunk/test
>> r3 = 0ae41e170cf7d07ec3679eb85d55c068617e0a66 (refs/remotes/trunk)
>>
>>
>> ----- svn ---
>>
>> [trunk] % svn log --diff -v
>> ------------------------------------------------------------------------
>> r3 | thomas | 2014-02-18 14:32:07 +0100 (Tue, 18 Feb 2014) | 1 line
>> Changed paths:
>> A /trunk/moo (from /trunk/test:2)
>> D /trunk/test
>>
>> woof
>>
>>
>> On Tue, Feb 18, 2014 at 2:22 PM, Benson Margulies <bi...@gmail.com>
>> wrote:
>>>
>>> Let me be specific. If I am sitting in a git clone that has been set
>>> up with git svn, and I use git apply to apply the output of git
>>> format-patch, if I dcommit, is the autodetection going to result in an
>>> svn mv?
>>>
>>>
>>> On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs <li...@selckin.be>
>>> wrote:
>>> > Git does not track renames, but can show/detect it, the magic options
>>> > are -C
>>> > and -M for diff/show etc
>>> >
>>> >
>>> >
>>> > On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies
>>> > <bi...@gmail.com>
>>> > wrote:
>>> >>
>>> >> 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 <se...@gmail.com> 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 <li...@selckin.be>
>>> >> > 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
>>> >> >> <bi...@gmail.com>
>>> >> >> 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
>>> >> >>> <li...@selckin.be>
>>> >> >>> wrote:
>>> >> >>> >
>>> >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com>
>>> >> >>> > 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: dev-unsubscribe@lucene.apache.org
>>> >> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> >>>
>>> >> >>
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Refactoring code through Github pull requests
Posted by Benson Margulies <bi...@gmail.com>.
Once I have transported a change from branch to branch via diff\apply, git stops discussing a rename at all.
On February 18, 2014 9:06:30 AM EST, Thomas Matthijs <li...@selckin.be> wrote:
>Unfortunately i can't find a way to make it explicitly show it will do
>a
>svn rename, but it does do it, so that makes this solution not very
>useful
>either i guess.
>
>
>--- git ---
>[master svntest] % git status
>On branch master
>Changes to be committed:
> (use "git reset HEAD <file>..." to unstage)
>
>renamed: test -> moo
>
>[master svntest] % git commit -m "woof"
>[master 6e2c0b3] woof
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename test => moo (100%)
>[master svntest] % git svn dcommit
>Committing to https://.../trunk ...
>R test => moo
>Committed r3
>D test
>A moo
>W: -empty_dir: trunk/test
>r3 = 0ae41e170cf7d07ec3679eb85d55c068617e0a66 (refs/remotes/trunk)
>
>
>----- svn ---
>
>[trunk] % svn log --diff -v
>------------------------------------------------------------------------
>r3 | thomas | 2014-02-18 14:32:07 +0100 (Tue, 18 Feb 2014) | 1 line
>Changed paths:
> A /trunk/moo (from /trunk/test:2)
> D /trunk/test
>
>woof
>
>
>On Tue, Feb 18, 2014 at 2:22 PM, Benson Margulies
><bi...@gmail.com>wrote:
>
>> Let me be specific. If I am sitting in a git clone that has been set
>> up with git svn, and I use git apply to apply the output of git
>> format-patch, if I dcommit, is the autodetection going to result in
>an
>> svn mv?
>>
>>
>> On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs <li...@selckin.be>
>wrote:
>> > Git does not track renames, but can show/detect it, the magic
>options
>> are -C
>> > and -M for diff/show etc
>> >
>> >
>> >
>> > On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies
><bimargulies@gmail.com
>> >
>> > wrote:
>> >>
>> >> 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 <se...@gmail.com>
>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
><li...@selckin.be>
>> >> > 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
>> >> >> <bi...@gmail.com>
>> >> >> 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
><li...@selckin.be>
>> >> >>> wrote:
>> >> >>> >
>> >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera
><se...@gmail.com>
>> >> >>> > 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: dev-unsubscribe@lucene.apache.org
>> >> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >>
>---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Refactoring code through Github pull requests
Posted by Thomas Matthijs <li...@selckin.be>.
Unfortunately i can't find a way to make it explicitly show it will do a
svn rename, but it does do it, so that makes this solution not very useful
either i guess.
--- git ---
[master svntest] % git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: test -> moo
[master svntest] % git commit -m "woof"
[master 6e2c0b3] woof
1 file changed, 0 insertions(+), 0 deletions(-)
rename test => moo (100%)
[master svntest] % git svn dcommit
Committing to https://.../trunk ...
R test => moo
Committed r3
D test
A moo
W: -empty_dir: trunk/test
r3 = 0ae41e170cf7d07ec3679eb85d55c068617e0a66 (refs/remotes/trunk)
----- svn ---
[trunk] % svn log --diff -v
------------------------------------------------------------------------
r3 | thomas | 2014-02-18 14:32:07 +0100 (Tue, 18 Feb 2014) | 1 line
Changed paths:
A /trunk/moo (from /trunk/test:2)
D /trunk/test
woof
On Tue, Feb 18, 2014 at 2:22 PM, Benson Margulies <bi...@gmail.com>wrote:
> Let me be specific. If I am sitting in a git clone that has been set
> up with git svn, and I use git apply to apply the output of git
> format-patch, if I dcommit, is the autodetection going to result in an
> svn mv?
>
>
> On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs <li...@selckin.be> wrote:
> > Git does not track renames, but can show/detect it, the magic options
> are -C
> > and -M for diff/show etc
> >
> >
> >
> > On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies <bimargulies@gmail.com
> >
> > wrote:
> >>
> >> 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 <se...@gmail.com> 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 <li...@selckin.be>
> >> > 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
> >> >> <bi...@gmail.com>
> >> >> 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 <li...@selckin.be>
> >> >>> wrote:
> >> >>> >
> >> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com>
> >> >>> > 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: dev-unsubscribe@lucene.apache.org
> >> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Refactoring code through Github pull requests
Posted by Benson Margulies <bi...@gmail.com>.
Let me be specific. If I am sitting in a git clone that has been set
up with git svn, and I use git apply to apply the output of git
format-patch, if I dcommit, is the autodetection going to result in an
svn mv?
On Tue, Feb 18, 2014 at 8:20 AM, Thomas Matthijs <li...@selckin.be> wrote:
> Git does not track renames, but can show/detect it, the magic options are -C
> and -M for diff/show etc
>
>
>
> On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies <bi...@gmail.com>
> wrote:
>>
>> 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 <se...@gmail.com> 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 <li...@selckin.be>
>> > 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
>> >> <bi...@gmail.com>
>> >> 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 <li...@selckin.be>
>> >>> wrote:
>> >>> >
>> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com>
>> >>> > 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: dev-unsubscribe@lucene.apache.org
>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Refactoring code through Github pull requests
Posted by Thomas Matthijs <li...@selckin.be>.
Git does not track renames, but can show/detect it, the magic options are
-C and -M for diff/show etc
On Tue, Feb 18, 2014 at 2:16 PM, Benson Margulies <bi...@gmail.com>wrote:
> 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 <se...@gmail.com> 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 <li...@selckin.be>
> 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 <
> bimargulies@gmail.com>
> >> 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 <li...@selckin.be>
> >>> wrote:
> >>> >
> >>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com>
> 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: dev-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Refactoring code through Github pull requests
Posted by Benson Margulies <bi...@gmail.com>.
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 <se...@gmail.com> 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 <li...@selckin.be> 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 <bi...@gmail.com>
>> 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 <li...@selckin.be>
>>> wrote:
>>> >
>>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Refactoring code through Github pull requests
Posted by Shai Erera <se...@gmail.com>.
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 <li...@selckin.be> 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 <bi...@gmail.com>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 <li...@selckin.be>
>> wrote:
>> >
>> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
Re: Refactoring code through Github pull requests
Posted by Thomas Matthijs <li...@selckin.be>.
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 <bi...@gmail.com>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 <li...@selckin.be> wrote:
> >
> > On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Refactoring code through Github pull requests
Posted by Benson Margulies <bi...@gmail.com>.
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 <li...@selckin.be> wrote:
>
> On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Refactoring code through Github pull requests
Posted by Thomas Matthijs <li...@selckin.be>.
On Tue, Feb 18, 2014 at 1:18 PM, Shai Erera <se...@gmail.com> 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