An oft heard recommendation when taking up git is to disregard any SCM you might already know, to clear your mind from an pre-existing expectations and to learn the tool with a blank slate, so to speak. This is probably a good idea in your case. A solid understanding of the core concepts git uses will really help you - for example, it is very quick and easy to create branches in git. A branch is just a reference to a snapshot of your files. So, you can of course have a 'clean' copy and 'dirty' copy, but they would be contained in different branches, not different files. Once you have two branches you can easily compare them, merge them, steal from them - whatever you want. Other key ideas you may want to understand (in the blank slate sense) include the index, the working directory and staging commits. I'm sure others have their own ideas about what they key ideas are too. If you haven't already, check out the pro-git book[1], it is very good at explaining these things. Regards, Andrew Ardill [1] http://progit.org/book/ On 10 November 2011 11:54, Brand, Greg <greg.brand@xxxxxxxxxxxxxxxxxx> wrote: > Good Day, > > Let me begin by describing my SCM experience. > I am an old school UNIX guy, and grew up with RCS. > I have written many BASH and CSH scripts for RCS. > > Moving on, the next logical step was CVS. > I've worked with (and administered) CVS for the last 12 years. > I have also worked with SourceSafe (ugh), Perforce and ClearCase. > > I am an avid CVS proponent. > > I have Recently changed jobs, to a SourceSafe shop. > We HAVE to move to something different. > > I've played with both Subversion and GIT. > I REALLY like GIT, but have some questions. > > > For my questions, I will use a CVS comparison sense this is what I'm most familiar with. > > - Updating a File: > ~ CVS's default behavior, is to try to merge changes from the repository into my local copy. Sometimes, this isn't desirable. > ~ With CVS I can also choose to get a "clean" copy. If the file I'm updating has been modified, CVS will create a backup of the original file before updating to the clean version. The backup file is saved as a "hidden" file, with the format: > .<filename>.revision > ~ Does GIT have the same, or similar options??? I understand with the distributed nature of GIT, there may be several ways to accomplish this. It is nice, though, to be able to get a clean version without losing changes you may (or may not) want to keep. > > > Thank you for your help. > I am sure I will have more questions. > > Best Regards, > Greg Brand > > > _____________________________________________________________________________ > Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com > > This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. > > WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. > _____________________________________________________________________________ > -- > 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 > -- 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