Matthieu Moy wrote:
Jakub Narebski <jnareb@xxxxxxxxx> writes:
2. If you wanted however to have *file* version (like in CVS), then it
is impossible because Git doesn't store such info
What could make sense is the commit id where the file was last
modified (i.e. the first item that appears when one runs "git log" on
the file). Not exactly as simple as it could be because of merge, but
not completely meaningless either.
That would also incur an impossible performance penalty. A *LOT* of
projects have a LICENSE file that hasn't been changed since the project
was put under version control in the first place. Is git suppose to
dig through history for every revision just to make sure that the
LICENSE file hasn't been changed since 1999?
Now think about such a feature for a project with 20k+ files (not even
very large, as projects go) and see how much time you lose when
switching branches. Then ask yourself: What's more important: Developer
time or version numbers in files that can be hacked in to match the
entire project's version when releasing?
100% of all discussions about this on git@vger has ended up with the
conclusion that it's not worth wasting a couple of seconds of a
developer's time for this feature to exist. That's why this feature
doesn't exist in git yet.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
http://nordicmeetonnagios.op5.org/
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html