Re: [PATCH v3 03/23] refs.c: add a new refs.c file to hold all common refs code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 26, 2014 at 2:31 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ronnie Sahlberg <sahlberg@xxxxxxxxxx> writes:
>
>> Create a new erfs.c file that will be used to hold all the refs
>> code that is backend agnostic and will be shared across all backends.
>>
>> The reason we renamed everything to refs-be-files.c in the previous patch
>> and now start moving the common code back to the new refs.c file
>> instead of the other way around is the etive volumes of code.
>
> Huh?  Why not create refs-be-files.c and move whatever need to be
> there over there, instead of rename the file and move things that
> shouldn't have been moved back like this?
>

The reason is the relative size of the code. I could do it the other
way but then
the changes that is moving the code would be much bigger.

Moving it like this, by first renaming it to refs-be-files.c and then
moving the backend agnostic parts back
is that the backend agnostic parts are mostly helper functions that
are independent of eachother.
This makes it possible to move just a few functions at a time making
the individual changes smaller and easier to manage when there are
merge conflicts.

A lot of the code that implements the actual files implementation for
refs storage implements the ref-cache/ref-dir/packed-refs/loose refs
etc.
This is all code that is intertwined and is difficult to split up.
Thus almost forcing me to move the whole 3000 lines of implementation
in one single monolithic patch.

I think "first rename, then move the agnostic parts a small section at
a time" was the least bad solution.




> Puzzled.
>
> I do not see 02/23 here, but I am assuming that is is just
>
>     git mv refs.c refs-be-files.c
>
> which may have been a seven-line patch with "format-patch -M" ;-)
>
>>
>> With the ref_cache, packed refs and loose ref handling that are all
>> part of the files based implementation the backend specific part
>> of the old refs.c file is several times larger than the backend agnostic
>> part. Therefore it makes more sense to first rename everything to be
>> part of the files based backend and then move the parts that can be used
>> as common code back to refs.c.
>>
>> Signed-off-by: Ronnie Sahlberg <sahlberg@xxxxxxxxxx>
>> ---
>>  Makefile | 1 +
>>  refs.c   | 3 +++
>>  2 files changed, 4 insertions(+)
>>  create mode 100644 refs.c
>>
>> diff --git a/Makefile b/Makefile
>> index e010ad1..937d22a 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -857,6 +857,7 @@ LIB_OBJS += quote.o
>>  LIB_OBJS += reachable.o
>>  LIB_OBJS += read-cache.o
>>  LIB_OBJS += reflog-walk.o
>> +LIB_OBJS += refs.o
>>  LIB_OBJS += refs-be-files.o
>>  LIB_OBJS += remote.o
>>  LIB_OBJS += replace_object.o
>> diff --git a/refs.c b/refs.c
>> new file mode 100644
>> index 0000000..77492ff
>> --- /dev/null
>> +++ b/refs.c
>> @@ -0,0 +1,3 @@
>> +/*
>> + * Common refs code for all backends.
>> + */
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]