revision: propagate flag bits from tags to pointees

2014-01-15 Thread Junio C Hamano
With the previous fix 895c5ba3 (revision: do not peel tags used in range notation, 2013-09-19), handle_revision_arg() that processes command line arguments for the git log family of commands no longer directly places the object pointed by the tag in the pending object array when it sees a tag

Re: revision: propagate flag bits from tags to pointees

2014-01-15 Thread Jeff King
On Wed, Jan 15, 2014 at 12:26:13PM -0800, Junio C Hamano wrote: With the previous fix 895c5ba3 (revision: do not peel tags used in range notation, 2013-09-19), handle_revision_arg() that processes command line arguments for the git log family of commands no longer directly places the object

Re: revision: propagate flag bits from tags to pointees

2014-01-15 Thread Junio C Hamano
Jeff King p...@peff.net writes: Looks good to me. As per my previous mail, I _think_ you could squash in: diff --git a/revision.c b/revision.c index f786b51..2db906c 100644 --- a/revision.c +++ b/revision.c @@ -316,13 +316,10 @@ static struct commit *handle_commit(struct rev_info *revs,

Re: revision: propagate flag bits from tags to pointees

2014-01-15 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: But I have a suspicion that my patch may break if any codepath looks at the current flag on the object and decides ah, it already is marked and punts. It indeed looks like mark_tree_uninteresting() does have that property. When an uninteresting tag

[PATCH v2 2/2] revision: propagate flag bits from tags to pointees

2014-01-15 Thread Junio C Hamano
With the previous fix 895c5ba3 (revision: do not peel tags used in range notation, 2013-09-19), handle_revision_arg() that processes command line arguments for the git log family of commands no longer directly places the object pointed by the tag in the pending object array when it sees a tag