On Thu, Jul 06, 2017 at 11:00:13PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I suspect that "--since 3.days" is still quite buggy (even with a single
> > reflog) because it checks commit timestamps and stops traversing when we
> > go too bar back. But in a reflog, the commits may be
Jeff King writes:
> I suspect that "--since 3.days" is still quite buggy (even with a single
> reflog) because it checks commit timestamps and stops traversing when we
> go too bar back. But in a reflog, the commits may be totally out of
> order. I'm not sure what it should do. Either:
>
> 1. D
On Thu, Jul 06, 2017 at 08:42:45AM -0700, Junio C Hamano wrote:
> >> I somehow feel that the "showing all entries from HEAD and then
> >> showing all from side" is simply a buggy behaviour. I do not think
> >> our users would terribly mind if we changed it later. But I may be
> >> missing the re
Jeff King writes:
> On Wed, Jul 05, 2017 at 03:45:03PM -0700, Junio C Hamano wrote:
>
>> > I did make the ordering intentional. We process each reflog sequentially
>> > in turn. I don't think it would be wrong to interleave them by date, but
>> > I actually think it's useful for somebody who swit
On Thu, Jul 06, 2017 at 03:16:06AM -0400, Jeff King wrote:
> If we think it's buggy, we can fix it now. But I'm not convinced that
> sequential iteration is that bad. It's at least _simple_ and easy to
> explain. The only other thing that would make sense to me is sorting the
> entries by date (re
On Wed, Jul 05, 2017 at 03:45:03PM -0700, Junio C Hamano wrote:
> > I did make the ordering intentional. We process each reflog sequentially
> > in turn. I don't think it would be wrong to interleave them by date, but
> > I actually think it's useful for somebody who switches that behavior to
> >
Jeff King writes:
>> > +test_expect_failure 'walking multiple reflogs shows both' '
>> > + {
>> > + do_walk HEAD &&
>> > + do_walk side
>> > + } >expect &&
>> > + do_walk HEAD side >actual &&
>> > + test_cmp expect actual
>> > +'
>>
>> I somehow find this one a bit iffy.
On Wed, Jul 05, 2017 at 09:05:14PM +0100, Ramsay Jones wrote:
> On 05/07/17 09:00, Jeff King wrote:
> > Since its inception, the general strategy of the reflog-walk
> > code has been to start with the tip commit for the ref, and
> > as we traverse replace each commit's parent pointers with
> > fak
On Wed, Jul 05, 2017 at 10:56:42AM -0700, Junio C Hamano wrote:
> > 1. The fake parents are used for commit selection and
> > display. So for example, "--merges" or "--no-merges"
> > are useful, because the history appears as a linear
>
> s/useful/useless/ perhaps?
Oops, yes ("not us
On 05/07/17 09:00, Jeff King wrote:
> Since its inception, the general strategy of the reflog-walk
> code has been to start with the tip commit for the ref, and
> as we traverse replace each commit's parent pointers with
> fake parents pointing to the previous reflog entry.
>
> This lets us trav
Jeff King writes:
> Since its inception, the general strategy of the reflog-walk
> code has been to start with the tip commit for the ref, and
> as we traverse replace each commit's parent pointers with
> fake parents pointing to the previous reflog entry.
>
> This lets us traverse the reflog as
Since its inception, the general strategy of the reflog-walk
code has been to start with the tip commit for the ref, and
as we traverse replace each commit's parent pointers with
fake parents pointing to the previous reflog entry.
This lets us traverse the reflog as if it were a real
history, but
12 matches
Mail list logo
