From: Nicolas Pitre <nico@fluxnic.net>
To: Ron Garret <ron1@flownet.com>
Cc: git@vger.kernel.org
Subject: Re: git-mv redux: there must be something else going on
Date: Wed, 03 Feb 2010 14:53:23 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.00.1002031436490.1681@xanadu.home> (raw)
In-Reply-To: <ron1-5F71CB.11234903022010@news.gmane.org>
On Wed, 3 Feb 2010, Ron Garret wrote:
> So... how *does* git decide when two blobs are different blobs and when
> they are the same blob with mods? I asked this question before and was
> pointed to the diffcore docs, but that didn't really clear things up.
> That just describes all the different ways git can do diffs, not the
> actual heuristics that git uses to track content.
Yes, those same heuristics are used to make the decision.
|The second transformation in the chain is diffcore-break, and is
|controlled by the -B option to the 'git diff-{asterisk}' commands.
|This is used to detect a filepair that represents "complete rewrite"
|and break such filepair into two filepairs that represent delete and
|create.
|[...]
|This transformation is used to detect renames and copies, and is
|controlled by the -M option (to detect renames) and the -C option
|(to detect copies as well) to the 'git diff-{asterisk}' commands.
|[...]
Note that you may use the -B, -C, -M and --find-copies-harder arguments
with log as well as diff commands even if there is no actual diff
output. So the explanation is really in that document even if simple
rename detection is concerned only by a fraction of what is said there.
And Git can detect copied files too.
Those semantics are not stored in the repository so they can be improved
or even changed after the facts.
Nicolas
next prev parent reply other threads:[~2010-02-03 19:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-03 18:25 git-mv redux: there must be something else going on Ron Garret
2010-02-03 18:48 ` Avery Pennarun
2010-02-03 19:23 ` Ron Garret
2010-02-03 19:47 ` Avery Pennarun
2010-02-03 20:30 ` Ron Garret
2010-02-03 19:53 ` Nicolas Pitre [this message]
2010-02-03 20:27 ` Ron Garret
2010-02-03 20:31 ` Ron Garret
2010-02-03 20:40 ` Avery Pennarun
2010-02-03 22:33 ` Ron Garret
2010-02-03 23:18 ` Avery Pennarun
2010-02-03 23:55 ` Jay Soffian
2010-02-04 0:10 ` Ron Garret
2010-02-04 0:10 ` Ron Garret
2010-02-04 0:48 ` Junio C Hamano
2010-02-03 20:44 ` Nicolas Pitre
2010-02-03 20:12 ` Pete Harlan
2010-02-03 20:34 ` Ron Garret
2010-02-03 21:12 ` [PATCH] Documentation: clarify git-mv behaviour wrt dirty files Thomas Rast
2010-02-03 21:56 ` 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=alpine.LFD.2.00.1002031436490.1681@xanadu.home \
--to=nico@fluxnic.net \
--cc=git@vger.kernel.org \
--cc=ron1@flownet.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).