From: Konstantin Khomoutov <kostix+git@007spb.ru>
To: Joao Pinto <Joao.Pinto@synopsys.com>
Cc: <git@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"CARLOS.PALMINHA@synopsys.com" <CARLOS.PALMINHA@synopsys.com>
Subject: Re: Git: new feature suggestion
Date: Thu, 19 Jan 2017 09:33:13 +0300 [thread overview]
Message-ID: <20170119093313.ea57832dfd1bc7e0b0f1e630@domain007.com> (raw)
In-Reply-To: <4817eb00-6efc-e3c0-53d7-46f2509350d3@synopsys.com>
On Wed, 18 Jan 2017 10:40:52 +0000
Joao Pinto <Joao.Pinto@synopsys.com> wrote:
[...]
> I have seen a lot of Linux developers avoid this re-organization
> operations because they would lose the renamed file history, because
> a new log is created for the new file, even if it is a renamed
> version of itself. I am sending you this e-mail to suggest the
> creation of a new feature in Git: when renamed, a file or folder
> should inherit his parent’s log and a “rename: …” would be
> automatically created or have some kind of pointer to its “old” form
> to make history analysis easier.
Git does not record renames because of its stance that what matters is
code _of the whole project_ as opposed to its location in a particular
file.
Hence with regard to renames Git "works backwards" by detecting them
dynamically while traversing the history (such as with `git log`
etc). This detection uses certain heuristics which can be controlled
with knobs pointed to by Stefan Beller.
Still, I welcome you to read the sort-of "reference" post by Linus
Torvalds [1] in which he explains the reasoning behind this approach
implemented in Git. IMO, understanding the reasoning behind the idea
is much better than just mechanically learning how to use it.
The whole thread (esp. Torvalds' replies) is worth reading, but that
particular mail summarizes the whole thing very well.
(The reference link to it used to be [2], but Gmane is not fully
recovered to be able to display it.)
1. http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/
2. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
next prev parent reply other threads:[~2017-01-19 6:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 10:40 Git: new feature suggestion Joao Pinto
2017-01-18 18:50 ` Stefan Beller
2017-01-18 19:04 ` Joao Pinto
2017-01-19 6:33 ` Konstantin Khomoutov [this message]
2017-01-19 17:55 ` Joao Pinto
2017-01-19 18:17 ` Junio C Hamano
2017-01-19 18:39 ` Linus Torvalds
2017-01-19 18:54 ` Joao Pinto
2017-01-19 19:16 ` Linus Torvalds
2017-01-19 21:51 ` Joao Pinto
2017-01-19 22:03 ` Stefan Beller
2017-01-20 10:44 ` Joao Pinto
2017-01-19 21:48 ` Jakub Narębski
2017-01-20 0:26 ` Linus Torvalds
2017-01-20 11:18 ` Jakub Narębski
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=20170119093313.ea57832dfd1bc7e0b0f1e630@domain007.com \
--to=kostix+git@007spb.ru \
--cc=CARLOS.PALMINHA@synopsys.com \
--cc=Joao.Pinto@synopsys.com \
--cc=git@vger.kernel.org \
--cc=torvalds@linux-foundation.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.
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).