[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-releng-inbox] [Bug 316208] CDT git migration
|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=316208
Product/Component: CDT / cdt-releng
--- Comment #67 from James Blackburn <jamesblackburn+eclipse@xxxxxxxxx> 2011-06-16 13:22:40 EDT ---
(In reply to comment #66)
> Seeing the history is not working properly because of EGit/git limitations for
> now, as you pointed out. If we can find a way to do it, we should post it to
> this bug.
I've done some digging on this:
git-blame works fine, because it's magic.
git log, even with --follow doesn't because it's 'a hack'(1)
See my question to the git mailing list:
http://git.661346.n2.nabble.com/git-log-follow-doesn-t-follow-a-rename-over-a-merge-td6480971.html
For the moment, to view the full log of a DSF / Memory file, use blame-log.sh
shell script from here:
http://git.661346.n2.nabble.com/alternate-log-follow-idea-td1385917.html
Or, alternatively: use git blame <file>, then git log --follow --
<original_file_path>
Given blame knows where the content has come from I'm sure we can persuade the
egit people to get the history view to tell us :) (2)
(1) From Linus: "I really never wanted the pain, and never cared enough for it,
which is why --follow is such a hack. It literally was designed as a "SVN noob"
pleaser, not as a "real git functionality" thing."
http://kerneltrap.org/mailarchive/git/2009/1/30/4861064
(2) There are plans for cgit to fix this:
http://git.661346.n2.nabble.com/gsoc-Better-git-log-follow-support-td6188083.html
--
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
