* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Scott wrote:
> > Anyway, maybe it's worth thinking a little about an SCM in which this is a
> > feature, instead of (or in addition to) automatically assuming this is a
> > bug we need to add infrastructure to work around.
>
> Agreed.
>
> To me, the main purpose in tracking renames is to obtain a deeper
> history of the line-by-line changes in a file.
>
> ==> But that doesn't seem relevant here.
>
> Last I looked, git has no such history. A given file contents is the
> indivisable atom of the git world, with no fine structure.
>
> This is quite unlike classic SCM's, built on file formats that track
> source lines, not files, as the atomic unit.
i believe the fundamental thing to think about is not file or line or
namespace, but 'tracking developer intent'. While keeping in mind that
GIT is not an SCM, all SCMs boil down to this single thing: being able
to track what the developer did and why he did it - to be a useful tool
later on. (SCMs are for humans with bad limitations, who have this
fundamental design bug and keep forgetting things.)
the basic question is, how much to track. The most extreme form of
tracking (just for the sake of visualizing it) would be to have an
eye-position recognizing software attached to a webcam looking at the
developer, and then exactly mapping what he did, how long did he look at
one particular line of code and exactly what did he type when doing
that. [ Perhaps also a thought-reader module in addition, once one is
available. (combined with another module that removes all the swearing)]
but i think Linus is on the right track to suggest that "the file names
dont matter all that much, it's all about the content". Global diffs
might track most types of plain renames, and if it gets it wrong - do we
care? Misdetection of renames can happen, but realistically only with
small files and trivial code, which wont have alot of history.
The only serious type of misdetection would be if two large modules in
two different places in the namespace happen to have exactly the same
content but have a different history (because e.g. they were merged in
via two separate trees, one came from one tree, the other from the other
tree), and the developer renamed both of them in the same commit: in
such a case the global diff would have no way to figure out what the
proper thread of history is. But is this a realistic scenario? If the
two files are nontrivial and have the same content, why werent they
merged in the namespace in the first place?
the moment we allow 'namespace' into the picture, things get complex and
ugly. Directory recursion is already a complexity that would have been
nice to avoid.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
