Re: [PATCH v2] Fix revision walk for commits with the same dates

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

 



On Fri, Mar 22, 2013 at 01:45:47PM -0700, Junio C Hamano wrote:
> Kacper Kornet <draenog@xxxxxxxxxxxxx> writes:

> > Logic in still_interesting function allows to stop the commits
> > traversing if the oldest processed commit is not older then the
> > youngest commit on the list to process and the list contains only
> > commits marked as not interesting ones. It can be premature when dealing
> > with a set of coequal commits. For example git rev-list A^! --not B
> > provides wrong answer if all commits in the range A..B had the same
> > commit time and there are more then 7 of them.

> > To fix this problem the relevant part of the logic in still_interesting
> > is changed to: the walk can be stopped if the oldest processed commit is
> > younger then the youngest commit on the list to processed.

> Is the made-up test case to freeze the clock even interesting?  The
> slop logic is merely a heuristic to compensate for effects caused by
> skewed or non-monototic clocks, so in a different repository you may
> even need to fuzz the timestamp comparison further

> 	if (date - 10 < src->item->date)

> or something silly like that.

I don't think it is a made-up test case. For example it is easy to get a
number of coequal commits by using git rebase -i. So I argue that git
should treat correctly ranges of such commits.

-- 
  Kacper Kornet
--
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]