On 09/23/2014 03:38 AM, Robert P. J. Day wrote: > > ...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. The manager was right. There is no point in having any source control at all if you're not using it. Making one single change on your source base outside of source control is a Bad Thing. I would suggest the thing to do is immediately, before any changes, create a git repo of the original, unmodified sources, and push it offline as a backup. Branch, make all your changes on a branch, and keep that (or those, one branch per change) backed up offline as well. Finally, when you're happy, merge all the changes back to the trunk (maybe using merge-compress). The trunk sees only one set of changes to move from old to new source, but history is preserved and, as a paramount concern, you can back out your changes and recover to a know state at any time. You can, of course, push only your trunk to a public repo but you should back up all your branches, disasters happen. Don't forget the primary purpose of using source control is not to publish a project on a commercial advertising site like github, it's to be able to recover from unwanted changes to the source (backups) and to be able to review change history. -- Stephen M. Webb <stephen [ dot ] webb [ at ] bregmasoft [ dot ] ca>