git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry D'Anna <larry@elder-gods.org>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v6] add --summary option to git-push and git-fetch
Date: Sun, 31 Jan 2010 19:57:51 -0500	[thread overview]
Message-ID: <20100201005751.GA8322@cthulhu> (raw)
In-Reply-To: <7vsk9oysds.fsf@alter.siamese.dyndns.org>

* Junio C Hamano (gitster@pobox.com) [100130 02:16]:
> Larry D'Anna <larry@elder-gods.org> writes:
> > +
> > +	object = parse_object(sha1); 
> > +	if (!object)
> > +	    die("bad object %s", arg);
> > +	
> > +	object_deref = deref_tag(object, NULL, 0); 
> > +	if (object_deref && object_deref->type == OBJ_COMMIT)
> > +	    if (flags_to_clear)
> > +		clear_commit_marks((struct commit *) object_deref, flags_to_clear); 
> > +
> > +	object->flags |= flags ^ local_flags; 
> 
> This smells somewhat fishy---what is the reason this "peel and mark" needs
> to be done only in this codepath, and none of the other callers of
> get_reference() need a similar logic, for example?
> 
> In general, why do you need to sprinkle clear-commit-marks all over the
> place?  

My idea was to call call clear_commit_marks on the "roots" of the revision arg,
and since handle_revision_arg looks up those roots in several different places,
i had to put clear_commit_marks in each of those places.  the reason the patch
is particularly ugly in this spot is that the other places where i put
clear_commit_marks, I already had a struct commit *, but here i just had a
object that might be a tag.

> This is not a rhetorical question (I haven't reviewed all the
> codepath involved for quite some time), but naïvely it appears it would be
> a lot simpler if you can let the existing code to do all the revision
> parsing and preparation to add to the pending object array as usual, and
> clear the flags from them before you let prepare_revision_walk() to start
> traversing the commit, but you probably had some reason why that simpler
> approach would not work and did it this way.  What am I missing?

The "existing code" being the caller of print_summary_for_push_or_fetch?  I
suppose I just wanted to keep the patches interference with update_local_ref to
a minimum, so I had it just grab the existing variable "quickref" out of that
function, because that was all the info I really needed to print the summary.

So i guess you're saying that it would be better for update_local_ref and
print_summary_for_push_or_fetch to clear the flags, and just pass a rev_info for
print_summary_for_push_or_fetch instead of quickref?

   --larry

  parent reply	other threads:[~2010-02-01  1:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-03  4:48 [PATCH] add --summary option to git-push and git-fetch Larry D'Anna
2009-07-03  9:20 ` Junio C Hamano
2009-07-07  1:59   ` [PATCH v3] " Larry D'Anna
2009-07-09 18:03     ` Larry D'Anna
2009-07-10  2:24       ` [PATCH v4] " Larry D'Anna
2009-07-10  7:33         ` Stephen Boyd
2009-07-11 17:41           ` Larry D'Anna
2009-07-11 19:05             ` Junio C Hamano
2010-01-30  0:59               ` Larry D'Anna
2010-01-30  1:17                 ` Junio C Hamano
2010-01-30  1:25                   ` Junio C Hamano
2010-01-30  1:19                 ` Junio C Hamano
2010-01-30  1:10               ` [PATCH v5] " Larry D'Anna
2010-01-30  2:05                 ` [PATCH v6] " Larry D'Anna
     [not found]                   ` <7vsk9oysds.fsf@alter.siamese.dyndns.org>
2010-01-30  7:51                     ` Ilari Liusvaara
2010-01-30  8:04                       ` Junio C Hamano
2010-01-30  8:57                         ` Ilari Liusvaara
2010-02-01  0:34                     ` Daniel Barkalow
2010-02-01  0:57                     ` Larry D'Anna [this message]
2010-02-04 17:16                       ` Larry D'Anna
2010-02-04 17:25                         ` Junio C Hamano
2010-02-04 17:55                           ` Junio C Hamano
2010-01-31 12:04                   ` Tay Ray Chuan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100201005751.GA8322@cthulhu \
    --to=larry@elder-gods.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).