Re: sg/commit-graph-cleanups (was Re: What's cooking in git.git (Jul 2020, #01; Mon, 6))

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

 



SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:

> On Tue, Jul 07, 2020 at 11:12:51AM -0700, Junio C Hamano wrote:
>> SZEDER Gábor <szeder.dev@xxxxxxxxx> writes:
>> 
>> > On Tue, Jul 07, 2020 at 09:45:21AM -0700, Junio C Hamano wrote:
>> >> Derrick Stolee <stolee@xxxxxxxxx> writes:
>> >> 
>> >> >> Oops, I am not sure what happened here.  There I thought were issues
>> >> >> pointed out at least on the latter series but was I hallucinating?
>> >> >
>> >> > I believe I have resolved all the open comments in both series.
>> >> 
>> >> OK, then I do not have to be worried.
>> >> 
>> >> Let's merge it down before -rc0.
>> >
>> > I think it was merged to next too soon.  I haven't even done with
>> > reporting all the issues that were already in v2.27.0, let alone
>> > looking through these followup series...
>> 
>> Oh, so what's your preference?  Reverting all the commit-graph stuff
>> that is not in 2.26 may be tempting but is not practically feasible
>> this late in the cycle.  It sounded like Derrick was OK to leave
>> them in 'next', and I am fine with keeping them out of the upcoming
>> release.
>
> Yeah, I think it's sensible to leave them out from the upcoming
> release, because that would give us the possibility (and me the time)
> to go over them once more.  Glancing through it, I see that Derrick
> kept most of my commit messages as-is, but some of them contain
> forward references to later patches in my modified path Bloom filters
> series that don't make sense on their own.  There are also some
> missing tests, a missing "Reported-by: me", missing updates to the
> format specs, and even a missing(?) patch.

OK, thanks.




[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]

  Powered by Linux