All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Sverre Rabbelier <srabbelier@gmail.com>,
	Jonathan Nieder <jrnieder@gmail.com>, Jeff King <peff@peff.net>,
	Git List <git@vger.kernel.org>,
	Daniel Barkalow <barkalow@iabervon.org>
Subject: Re: [PATCH 3/5] setup_revisions: remember whether a ref was positive or not
Date: Tue, 26 Jul 2011 17:16:06 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.1.00.1107261713040.1534@s15462909.onlinehome-server.info> (raw)
In-Reply-To: <7vy5znscst.fsf@alter.siamese.dyndns.org>

Hi,

On Sun, 24 Jul 2011, Junio C Hamano wrote:

> Sverre Rabbelier <srabbelier@gmail.com> writes:
> 
> >  void add_pending_object(struct rev_info *revs, struct object *obj, const char *name)
> >  {
> > -	add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
> > +	add_pending_object_with_mode(revs, obj, name, S_IFINVALID, 0);
> >  }
> 
> This seems utterly broken.  For example, fmt-merge-msg.c adds "^HEAD" 
> and of course the flags on the object is UNINTERESTING. Has all the 
> callers of add_pending_object() been verified? Why is it passing an 
> unconditional 0 and not !!(obj->flags & UNINTERESTING) or something?
> 
> If the excuse is "this is only to help fast-export and other callers of 
> add_pending_object() does not care", that is a sloppy attitude that 
> breaks maintainability of the code (because it forgets to add "in the 
> current code nobody looks at the new 'flags' field" to that excuse, and 
> also does not have any comments around this code that says so); it is 
> questionable if such a hack belongs to a patch that touches object.h.

I hope you appreciate our effort not to hack this into the 'mode' 
variable. That variable is exactly in the spirit you mentioned, so I 
figured we'd be fine with a similar approach.

Now that you have made clear that it is not fine, would you please care to 
enlighten me how you would prefer the change to look like that makes the 
argument parsing in revision.c remember which _refs_ (as opposed to 
_commits_) were marked uninteresting?

Thank you very much,
Johannes

  parent reply	other threads:[~2011-07-26 15:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-24 14:21 [PATCH 0/5] fast-export: prepare for remote helpers awesomeness Sverre Rabbelier
2011-07-24 14:21 ` [PATCH 1/5] t9350: point out that refs are not updated correctly Sverre Rabbelier
2011-07-24 14:21 ` [PATCH 2/5] fast-export: do not refer to non-existing marks Sverre Rabbelier
2011-07-24 14:21 ` [PATCH 3/5] setup_revisions: remember whether a ref was positive or not Sverre Rabbelier
2011-07-24 19:23   ` Junio C Hamano
2011-07-24 23:17     ` Junio C Hamano
2011-08-03 13:52       ` Sverre Rabbelier
2011-08-03 18:12         ` Junio C Hamano
2011-08-08 16:22           ` Johannes Schindelin
2011-08-08 17:47             ` Junio C Hamano
2011-08-08 21:27               ` Sverre Rabbelier
2011-08-08 22:07                 ` Junio C Hamano
2011-08-08 22:30                   ` Sverre Rabbelier
2011-08-08 22:36                     ` Junio C Hamano
2011-08-08 22:38                       ` Sverre Rabbelier
2011-08-08 22:46                         ` Junio C Hamano
2011-08-08 22:48                           ` Sverre Rabbelier
2011-08-08 23:17                             ` Junio C Hamano
2011-08-08 23:25                               ` Sverre Rabbelier
2011-08-08 23:39                                 ` Junio C Hamano
2011-08-08 22:24                 ` Junio C Hamano
2011-08-08 22:28                   ` Sverre Rabbelier
2011-08-08 22:56                     ` Junio C Hamano
2011-08-08 23:04                       ` Sverre Rabbelier
2011-07-26 15:16     ` Johannes Schindelin [this message]
2011-07-24 14:21 ` [PATCH 4/5] fast-export: do not export negative refs Sverre Rabbelier
2011-07-24 19:07   ` Junio C Hamano
2011-07-26 15:11     ` Johannes Schindelin
2011-07-24 14:21 ` [PATCH 5/5] setup_revisions: remember whether a ref was positive or not Sverre Rabbelier

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=alpine.DEB.1.00.1107261713040.1534@s15462909.onlinehome-server.info \
    --to=johannes.schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    --cc=srabbelier@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.