[PATCH rev-list.c] max-count in terms of intersection

[PATCH rev-list.c] max-count in terms of intersection

[Luben Tuikov]

diff-tree 768b79de9eadc38a839332df0fcce021f7174d6d (from 2e67a5f449f4026097494569f871d79bf263ab28)
tree 6403fc730f8d5843043788f4c2f466727ba94bc0
parent 2e67a5f449f4026097494569f871d79bf263ab28
author Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
committer Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500

    [PATCH rev-list.c] max-count in terms of intersection
    
    When a path designation is given, max-count counts the number
    of commits therein (intersection), not globally.
    
    This avoids the case where in case path has been inactive
    for the last N commits, --max-count=N and path designation
    at git-rev-list is given, would give no commits.
    
    Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>

diff --git a/rev-list.c b/rev-list.c
index 6e6ffde..e17f928 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -124,8 +124,6 @@ static int filter_commit(struct commit *
                stop_traversal=1;
                return CONTINUE;
        }
-       if (max_count != -1 && !max_count--)
-               return STOP;
        if (no_merges && (commit->parents && commit->parents->next))
                return CONTINUE;
        if (paths && dense) {
@@ -148,6 +146,9 @@ static int process_commit(struct commit 
                return CONTINUE;
        }
 
+       if (max_count != -1 && !max_count--)
+               return STOP;
+
        show_commit(commit);
 
        return CONTINUE;

Re: [PATCH rev-list.c] max-count in terms of intersection

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> diff-tree 768b79de9eadc38a839332df0fcce021f7174d6d (from 2e67a5f449f4026097494569f871d79bf263ab28)
> tree 6403fc730f8d5843043788f4c2f466727ba94bc0
> parent 2e67a5f449f4026097494569f871d79bf263ab28
> author Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> committer Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
>
>     [PATCH rev-list.c] max-count in terms of intersection
>     

Documentation/SubmittingPatches, perhaps?

>     When a path designation is given, max-count counts the number
>     of commits therein (intersection), not globally.

This makes sense, but I wonder if the same logic applies to
max_age as well.  If we have clock-skewed commits that are
skipped by the DENSE processing, we probably do not want them to
be affecting what to do on the commits that matter.

Re: [PATCH rev-list.c] max-count in terms of intersection

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:

> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > diff-tree 768b79de9eadc38a839332df0fcce021f7174d6d (from
> 2e67a5f449f4026097494569f871d79bf263ab28)
> > tree 6403fc730f8d5843043788f4c2f466727ba94bc0
> > parent 2e67a5f449f4026097494569f871d79bf263ab28
> > author Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> > committer Luben Tuikov <ltuikov@yahoo.com> 1132349344 -0500
> >
> >     [PATCH rev-list.c] max-count in terms of intersection
> >     
> 
> Documentation/SubmittingPatches, perhaps?

Sorry, I just saw this document existed for GIT too.
Would you like me to resubmit?

> >     When a path designation is given, max-count counts the number
> >     of commits therein (intersection), not globally.
> 
> This makes sense, but I wonder if the same logic applies to
> max_age as well.  If we have clock-skewed commits that are
> skipped by the DENSE processing, we probably do not want them to
> be affecting what to do on the commits that matter.

As far as I understand it, I think max-age is fine the way
it is.  After all, max-age depends on date/time which is
absolute (i.e. applies to commits in the whole set and in
the intersection just the same).

    Luben

Re: [PATCH rev-list.c] max-count in terms of intersection

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

>> This makes sense, but I wonder if the same logic applies to
>> max_age as well.  If we have clock-skewed commits that are
>> skipped by the DENSE processing, we probably do not want them to
>> be affecting what to do on the commits that matter.
>
> As far as I understand it, I think max-age is fine the way
> it is.  After all, max-age depends on date/time which is
> absolute (i.e. applies to commits in the whole set and in
> the intersection just the same).

It is recorded absolutely but what if committer's clock is
broken on one commit but not others, and if you are not using
the default sort_by_date() (e.g. --topo-order)?