From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff Hostetler <git@jeffhostetler.com>
Cc: Philip Oakley <philipoakley@iee.org>,
Pavel Kretov <firegurafiku@gmail.com>,
git@vger.kernel.org
Subject: Re: [idea] File history tracking hints
Date: Sat, 30 Sep 2017 17:11:53 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1.1709301706170.40514@virtualbox> (raw)
In-Reply-To: <5fb263a8-d83b-64a7-812f-fd8e3748feb6@jeffhostetler.com>
Hi Jeff,
On Sat, 30 Sep 2017, Jeff Hostetler wrote:
> On 9/29/2017 7:12 PM, Johannes Schindelin wrote:
>
> > Therefore, it would be good to have a way to tell Git about renames
> > explicitly so that it does not even need to use its heuristics.
>
> Agreed.
>
> It would be nice if every file (and tree) had a permanent GUID
> associated with it. Then the filename/pathname becomes a property
> of the GUIDs. Then you can exactly know about moves/renames with
> minimal effort (and no guessing). But I suppose that ship has sailed...
Yes, that ship has sailed.
But we still could teach Git to understand certain "hints" (that would be
really more like "cluebats").
So while we cannot have any GUIDs that are persistent across renames/moves
(and which users would probably get wrong all the time by using
third-party tools that are not Git-rename aware), we have unique
identifiers: the object names.
And we could easily have a lookup table of pairs of object names, telling
Git that they were source and target of a rename. When Git would try to
figure out whether anything was renamed, it would first look at that
lookup table and save itself a lot of work (and opportunity to fail) and
short-cut the rename detection.
Ciao,
Johannes
next prev parent reply other threads:[~2017-09-30 15:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-11 7:11 [idea] File history tracking hints Pavel Kretov
2017-09-11 18:11 ` Stefan Beller
2017-09-11 18:47 ` Jacob Keller
2017-09-11 18:41 ` Jeff King
2017-09-11 20:09 ` Igor Djordjevic
2017-09-11 21:48 ` Philip Oakley
2017-09-13 11:38 ` Johannes Schindelin
2017-09-14 23:22 ` Philip Oakley
2017-09-29 23:12 ` Johannes Schindelin
2017-09-30 8:02 ` Jeff Hostetler
2017-09-30 15:11 ` Johannes Schindelin [this message]
2017-10-01 3:27 ` Junio C Hamano
2017-10-02 17:41 ` Stefan Beller
2017-10-02 18:51 ` Jeff Hostetler
2017-10-02 19:18 ` Stefan Beller
2017-10-02 20:02 ` Jeff Hostetler
2017-10-03 0:52 ` Junio C Hamano
2017-10-03 0:45 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1.1709301706170.40514@virtualbox \
--to=johannes.schindelin@gmx.de \
--cc=firegurafiku@gmail.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).