git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Turner <dturner@twopensource.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, David Turner <dturner@twitter.com>
Subject: Re: [PATCH v2] log: add log.follow config option
Date: Tue, 07 Jul 2015 21:28:59 -0400	[thread overview]
Message-ID: <1436318939.5521.32.camel@twopensource.com> (raw)
In-Reply-To: <xmqqsi8z1urz.fsf@gitster.dls.corp.google.com>

On Tue, 2015-07-07 at 15:13 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > diff --git a/revision.c b/revision.c
> > index 3ff8723..ae6d4c3 100644
> > --- a/revision.c
> > +++ b/revision.c
> > @@ -2322,12 +2322,21 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
> >  
> >  	if (revs->prune_data.nr) {
> >  		copy_pathspec(&revs->pruning.pathspec, &revs->prune_data);
> > -		/* Can't prune commits with rename following: the paths change.. */
> > -		if (!DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
> > -			revs->prune = 1;
> > +
> >  		if (!revs->full_diff)
> >  			copy_pathspec(&revs->diffopt.pathspec,
> >  				      &revs->prune_data);
> > +
> > +		if (DIFF_OPT_TST(&revs->diffopt, DEFAULT_FOLLOW_RENAMES) &&
> > +		    revs->diffopt.pathspec.nr == 1)
> > +			DIFF_OPT_SET(&revs->diffopt, FOLLOW_RENAMES);
> > +
> > +		/* Can't prune commits with rename following: the paths change.. */
> > +		if (!DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES)) {
> > +			revs->prune = 1;
> > +		} else {
> > +			revs->diff = 1;
> > +		}
> >  	}
> >  	if (revs->combine_merges)
> >  		revs->ignore_merges = 0;
> 
> It is unfortunate that we have to waste one DIFF_OPT bit and touch
> revision.c for something that is "just a convenience".  Because
> setup_revisions() does not have a way to let you flip the settings
> depending on the number of pathspecs specified, I do not think of a
> solution that does not have to touch a low level foundation part of
> the codebase, which I'd really want to avoid.
> 
> But I wonder why your patch needs to touch so much.
> 
> Your changes to other files make sure that diffopt has the
> DEFAULT_FOLLOW_RENAMES when (1) the configuration is set and (2) the
> command line did not override it with --no-follow.  And these look
> very sensible.
> 
> Isn't the only thing left to do in this codepath, after the DEFAULT_
> is set up correctly, to set FOLLOW_RENAMES when (1) DEFAULT_ is set
> and (2) you have only one path?
>
> And once FOLLOW_RENAMES is set or unset according to the end-user
> visible semantics, i.e. "just for a convenience, setting log.follow
> adds --follow to the command line if and only if there is only one
> pathspec", I do not see why existing code needs to be modified in
> any other way.
> 
> IOW, I'd like to know why we need more than something like this
> change to this file, instead of the above?  We didn't muck with
> revs->diff in the original when FOLLOW_RENAMES was set, but now it
> does, for example.

We did, but we did it earlier.  But I can just rearrange the code.

> diff --git a/revision.c b/revision.c
> index 3ff8723..f7bd229 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2270,6 +2270,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
>  			got_rev_arg = 1;
>  	}
>  
> +	if (DIFF_OPT_TST(&revs->diffopt, DEFAULT_FOLLOW_RENAMES) &&
> +	    revs->diffopt.pathspec.nr == 1)
> +		DIFF_OPT_SET(&revs->diffopt, FOLLOW_RENAMES);
> +
>  	if (prune_data.nr) {
>  		/*
>  		 * If we need to introduce the magic "a lone ':' means no

revs->diffopt.pathspec isn't set up yet then. But prune_data is, so I
can use that. 

Will send a v3.

  reply	other threads:[~2015-07-08  1:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07 18:40 [PATCH v2] log: add log.follow config option David Turner
2015-07-07 21:42 ` Matthieu Moy
2015-07-07 22:11   ` David Turner
2015-07-07 22:13 ` Junio C Hamano
2015-07-08  1:28   ` David Turner [this message]
2015-07-08  4:12     ` Junio C Hamano
2015-07-08 16:49   ` Junio C Hamano

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=1436318939.5521.32.camel@twopensource.com \
    --to=dturner@twopensource.com \
    --cc=dturner@twitter.com \
    --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).