mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Robert Dailey <>
To: Jeff King <>
Cc: Git <>
Subject: Re: diff.renames not working?
Date: Mon, 16 Sep 2019 09:25:28 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Sep 13, 2019 at 10:30 PM Jeff King <> wrote:
> > Now this looks more like it. I can actually see a useful diff here,
> > instead of everything looking like a new file. But there is a lot of
> > confusion here:
> >
> > 1. `diff --follow` is not a documented[1] option. Why does it work?
> Accident. :) See above.
> > 2. `diff -M` doesn't actually work either. It should, though. In fact,
> > I expected it to work as `--follow` does. But it doesn't.
> It doesn't work because this is a copy, not a rename.
> > 3. The `diff.renames` config doesn't seem to be working here, when it should.
> It does, but the pathspec prevents it from finding a source candidate.

Jeff, thanks so much. All of your examples help to contrast the
different behavior. I thought -M did copies & renames, that was my
misunderstanding. But the fact that you explained that the file spec
would prevent it from working as I'd like anyway means it doesn't
matter too much.

Ultimately my goal is to use the pathspec to filter what is visible, I
don't necessarily intend it to obscure my results due to internal
behavior. I realize there are performance obligations too (as you
described) but I feel like something like this should be
straightforward for end users. I consider myself a step above most
people with my understanding of Git and how it functions, and even I
was confused by this. Especially when it comes to folks I work with at
my day job, I just don't see them making sense of this.

To me, as transparently as possible, moves and copies should be
handled intrinsically. I realize there are technical challenges
(performance, ambiguities, etc), but anything that can be done to help
with that would go a long way with most users. Maybe a 3rd option from
your list to solve this issue might be adding some metadata to commits
or blob object types to record the pathspec of the file it was a copy
or move of. Even if this required you to first do a git cp/mv before
modifying the content, or a strict similarity threshold, I think it
would go a long way. That means that `diff` can utilize the metadata
in the object itself to find the path specs to follow, instead of
requiring some complex deduction logic that has a steep performance

  reply	other threads:[~2019-09-16 14:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13 20:24 diff.renames not working? Robert Dailey
2019-09-13 22:36 ` Bryan Turner
2019-09-14  3:30 ` Jeff King
2019-09-16 14:25   ` Robert Dailey [this message]
2019-09-16 17:35   ` 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:

  List information:

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

  git send-email \
    --in-reply-to='' \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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 read-only IMAP folder(s) and NNTP newsgroup(s).