interested in folks' opinion on the following issue ... couple years
back, i had a short contract putting some C code under version control
(it had never been under version control), cleaning it up, dealing
with numerous compilation warnings and a couple compile-time errors,
and here's the issue.
the code had been written by several different people over the
years, and it was just plain aesthetically messy, so *before* placing
it in a git repository, i suggested doing some initial cleanup, such
as:
* run it through lint
* use "indent" to at least standardize everyone's differing coding
styles
* remove all compile warnings
* obviously, fix the small number of compile-time errors
* fix ridiculous spelling mistakes in comments
etc, etc. it was my position that there was no value initializing the
git repository with content that was clearly messy and warning-ridden
and stylistically inconsistent ... you get the idea.
the project manager was adamant that the *proper* way to do this was
to start the git repo with the code *exactly* as it was. i suggested
that, of course, one should keep the original code, perhaps off to the
side, but it was my take that there's no real value in establishing a
version control repo of *any* kind if you know beforehand that the
content is in that much of a mess.
in the end, i did what the manager asked (naturally) and,
unsurprisingly, most of the history of that repository is now nothing
but cleanup which, to me, has no value.
not sure why it didn't occur to me at the time, but if i were to do
this again, i'd just check the original source into a git "orphan"
branch so it's part of the repo but stays out of the way.
thoughts? do people have strong opinions on this either way?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================