Hi,
Tom Lane <tgl@sss.pgh.pa.us> writes:
> The rearrangement might be marginally nicer from a code beautification
> point of view --- right now we're a bit inconsistent about whether
> datatype-specific hash functions live in hashfunc.c or in the datatype's
> utils/adt/ file. But I'm not sure that removing hashfunc.c altogether is
> an appropriate solution to that, not least because of the loss of CVS
> history for the functions. I'd be inclined to leave the core hash_any()
> code where it is, if not all of these functions altogether.
I guess someone has to talk about it: git will follow the code even when
the file hosting it changes. It's not all magic though:
http://kerneltrap.org/node/11765
"And when using git, the whole 'keep code movement separate from changes' has an even more fundamental reason: git can
trackcode movement (again, whether moving a whole file or just a function between files), and doing a 'git blame -C'
willactually follow code movement between files. It does that by similarity analysis, but it does mean that if you both
movethe code *and* change it at the same time, git cannot see that 'oh, that function came originally from that other
file',and now you get worse annotations about where code actually originated."
Having better tools maybe could help maintain the high quality standards
that are established code wise, too.
Regards,
--
dim