git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bo Yang <struggleyb.nku@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, trast@student.ethz.ch
Subject: Re: [PATCH] Make git log --follow support --find-copies-harder.
Date: Thu, 22 Apr 2010 10:27:55 +0800	[thread overview]
Message-ID: <m2p41f08ee11004211927w88506198sfd740da672b5c6f7@mail.gmail.com> (raw)
In-Reply-To: <7v8w8gbv75.fsf@alter.siamese.dyndns.org>

On Thu, Apr 22, 2010 at 12:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> What does the command do when given a single -C instead of --f-c-h, with
> or without your patch?  What should it do?

I have found that two days ago, all '-M/-C/-C -C' with some <path>
specified will fail.
byang@byang-laptop:~/git/git$ git diff --name-status -M  maint master
builtin/add.c
A       builtin/add.c

byang@byang-laptop:~/git/git$ git log -M -C -C --name-status
--pretty=oneline t/t4013/diff.show_--first-parent_master
2bf6587349e31b582dae47954b1a334052230e28 show --first-parent/-m: do
not default to --cc
A       t/t4013/diff.show_--first-parent_master

without <path>
byang@byang-laptop:~/git/git$ git diff --name-status -M  maint master
| grep  'builtin/add.c'
R100	builtin-add.c	builtin/add.c

byang@byang-laptop:~/git/git$ git log -M -C -C --name-status
--pretty=oneline | grep -- 't/t4013/diff.show_--first-parent_master'
C050	t/t4013/diff.show_master	t/t4013/diff.show_--first-parent_master

Both of above files are copied/renamed.

This because in diff_tree,

              if (opt->nr_paths) {
                        skip_uninteresting(t1, base, baselen, opt);
                        skip_uninteresting(t2, base, baselen, opt);
                }

And this give no chance for later rename/copy detection. I have been
trying to figure out a patch for this, but the logic is complex and it
will take more time...

> Because try_to_follow_renames() is supposed to be a rare-event (it only
> happens when a path we have been following disappears), I am having this
> feeling that it would make more sense to do this change unconditionally.
>
> Two possible outcomes that this patch allows the users to have by giving
> them a choice to give (or not to give) --f-c-h are:
>
>  (1) the path is judged to be new in a commit and traversal finishes
>     there; or
>
>  (2) the path is found to be a copy from another path from one of the
>     parents and traversal continues.
>
> But I think using --follow is a sure sign of the user wanting the latter
> and never the former, no?

Hmm, that makes sense. So, --follow always means --f-c-h.

Regards!
Bo

  reply	other threads:[~2010-04-22  2:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21 14:37 [PATCH] Make git log --follow support --find-copies-harder Bo Yang
2010-04-21 16:56 ` Junio C Hamano
2010-04-22  2:27   ` Bo Yang [this message]
2010-04-22  5:54     ` 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=m2p41f08ee11004211927w88506198sfd740da672b5c6f7@mail.gmail.com \
    --to=struggleyb.nku@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=trast@student.ethz.ch \
    /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).