Re: [PATCH/WIP v3 4/4] ref-filter: move code from 'for-each-ref'

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH/WIP v3 4/4] ref-filter: move code from 'for-each-ref'

From: Matthieu Moy <hidden>
Date: 2016-06-15 23:05:02

Karthik Nayak [off-list ref] writes:
Move most of the code from 'for-each-ref' to 'ref-filter' to make
it publically available to other commands, this is to unify the code
s/publically/publicly/
quoted hunk
--- /dev/null
+++ b/ref-filter.h
Moving file to the .h file should be done in a separate patch. I don't
want to review the 1050 lines of cut-and-paste other than by doing the
cut-and-paste myself and see if I get the same result, but this part is
not as straightforward and needs proper thinking and review.

In short: the big code movement should be *only* a cut-and-paste, alone
in its own patch.

On overall, we're getting close to an acceptable version for these 4
patches. My advice: prioritize polishing these few patches, so that we
can do a detailed review and then consider this part "done" (either
merged in git.git or not, but I'd like to avoid having to review the
code movement & refactoring again when we move to the next patches).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH/WIP v3 4/4] ref-filter: move code from 'for-each-ref'

From: Karthik Nayak <hidden>
Date: 2016-06-15 23:05:02

On 05/29/2015 02:05 AM, Matthieu Moy wrote:
Karthik Nayak [off-list ref] writes:
quoted
Move most of the code from 'for-each-ref' to 'ref-filter' to make
it publically available to other commands, this is to unify the code
s/publically/publicly/
quoted
--- /dev/null
+++ b/ref-filter.h
Moving file to the .h file should be done in a separate patch. I don't
want to review the 1050 lines of cut-and-paste other than by doing the
cut-and-paste myself and see if I get the same result, but this part is
not as straightforward and needs proper thinking and review.

In short: the big code movement should be *only* a cut-and-paste, alone
in its own patch.
Ok, will separate it into two patches.

 >
On overall, we're getting close to an acceptable version for these 4
patches. My advice: prioritize polishing these few patches, so that we
can do a detailed review and then consider this part "done" (either
merged in git.git or not, but I'd like to avoid having to review the
code movement & refactoring again when we move to the next patches).
Sure I'll fix changes suggested by you and push to Github probably by 
tonight (IST), will wait for a day or two to see if there are more 
suggestions by others on the mailing list before sending a new patch 
series here.

-- 
Regards,
Karthik
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help