Re: [PATCH v2 0/7] Provide API to invalidate refs cache

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

 



On 10/11/2011 02:02 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
>> These patches apply on top of mh/iterate-refs, which is in next but
>> not in master.
> 
> Building your series on mh/iterate-refs would unfortunately make the
> conflict resolution worse. It would have been better if this were based on
> a merge between mh/iterate-refs and jp/get-ref-dir-unsorted (which already
> has happened on 'master' as of fifteen minutes ago).

AAAAaaaarrrgghh did that really have to happen?!?

> I could rebase your series, but it always is more error prone to have
> somebody who is not the original author rebase a series than the original
> author build for the intended base tree from the beginning.

I don't mind rebasing this little series on jp/get-ref-dir-unsorted.
But it's going to be an utter nightmare (as in, "can I even muster the
energy to do so much pointless work") to rebase my much bigger
hierarchical-refs series [1] onto jp/get-ref-dir-unsorted.  The latter
makes changes all over refs.c and changes several things at once
(separate ref_entry out of ref_list, change current_ref to a ref_entry*,
rename ref_list to ref_array, change data structure to array plus
rewrite all loops, change to binary search).  And
jp/get-ref-dir-unsorted includes a change that was inspired by my patch
series [2], so it is not like jp/get-ref-dir-unsorted was developed in
complete isolation from hierarchical-refs.

And this rebase will be work with no benefit, because my series includes
all of the improvements of jp/get-ref-dir-unsorted plus much more.  But
my change to the data structure is implemented in a different order and
following other improvements.  For example, I add a lot of comments,
change a lot of code to use the cached_refs data structure more
consistently, and accommodate partly-sorted lists by the time my patch
series includes everything that is in jp/get-ref-dir-unsorted.

Rebasing 78 patches is going to be a morass of clerical work.  Is there
any alternative?

Michael

PS: I see that some confusion might have been caused by one of my emails
[3], where I mistakenly approved of the merge of jp/get-ref-dir-unsorted
(meaning the "Don't sort ref_list too early" part) just before asking
that jp/get-ref-dir-unsorted not be merged (meaning the rest).  So maybe
I brought this whole mess down on my own head :-(

[1] branch hierarchical-refs on git://github.com/mhagger/git.git
[2] http://marc.info/?l=git&m=131740585620461&w=2
[3] http://marc.info/?l=git&m=131753257824405&w=2

-- 
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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]