On Fri, Jul 13, 2012 at 03:12:47PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, this was my analysis, too. Though reading get_revision-1, it seems
> > like we can actually set SHOWN, but I wasn't able to trigger any change
> > of behavior in practice. I think it is because we mus
Jeff King writes:
> Yeah, this was my analysis, too. Though reading get_revision-1, it seems
> like we can actually set SHOWN, but I wasn't able to trigger any change
> of behavior in practice. I think it is because we must set both SHOWN
> and BOUNDARY to have an effect, and we do not do so.
In
On Fri, Jul 13, 2012 at 02:10:54PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > There's no need to make this get_revision_1 call when our
> > counter runs out. If we are not in --boundary mode, we will
> > just throw away the result and immediately return NULL. If
> > we are in --bound
Jeff King writes:
> There's no need to make this get_revision_1 call when our
> counter runs out. If we are not in --boundary mode, we will
> just throw away the result and immediately return NULL. If
> we are in --boundary mode, then we will still throw away the
> result, and then start showing
On Fri, Jul 13, 2012 at 03:50:23AM -0400, Jeff King wrote:
> revision.c | 39 +++
> 1 file changed, 19 insertions(+), 20 deletions(-)
BTW, the patch is slightly hard to read because of the re-indentation.
Here it is with "-w -U5":
diff --git a/revision.c b/re
During a revision traversal in which --max-count has been
specified, we decrement a counter for each revision returned
by get_revision. When it hits 0, we typically return NULL
(the exception being if we still have boundary commits to
show).
However, before we check the counter, we call get_revisi
6 matches
Mail list logo
