Re: update @version in file
- From
Andreas Ericsson <ae@op5.se>
- Date
- May 13, 2009, 17:38 UTC
- Message-ID
- <4A0B059F.1020509@op5.se>
- In-Reply-To
- <vpqeiutrl09.fsf@bauges.imag.fr>
Matthieu Moy wrote:
Show 10 quoted lines
> Jakub Narebski <jnareb@gmail.com> 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@op5.se 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.