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.
next prev parent 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).