# RE: Updating Files 3 messages from 2011-11-10 to 2011-11-10. Participants: Brand, Greg, Andrew Ardill, Ben Walton. Thread: https://gitlist.dev/t/28899 ## Brand, Greg, 2011-11-10 00:54 Subject: RE: Updating Files Message-ID: <338A71EC3E356A47BF5279971E4EF72A04D860D7F6@WESMSG51.nordsoncorp.local> URL: https://gitlist.dev/e/338A71EC3E356A47BF5279971E4EF72A04D860D7F6%40WESMSG51.nordsoncorp.local ``` 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:                ..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. _____________________________________________________________________________ ``` ## Andrew Ardill, 2011-11-10 01:05 Subject: Re: Updating Files Message-ID: URL: https://gitlist.dev/e/CAH5451m%3DzdM_1CKSubLksm%2BYZxjybNFo-%3Dq6HTUkXXTsqzae9g%40mail.gmail.com In-Reply-To: <338A71EC3E356A47BF5279971E4EF72A04D860D7F6@WESMSG51.nordsoncorp.local> ``` 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 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: >                ..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@vger.kernel.org > More majordomo info at  http://vger.kernel.org/majordomo-info.html > ``` ## Ben Walton, 2011-11-10 01:08 Subject: RE: Updating Files Message-ID: <1320887258-sup-7544@pinkfloyd.chass.utoronto.ca> URL: https://gitlist.dev/e/1320887258-sup-7544%40pinkfloyd.chass.utoronto.ca In-Reply-To: <338A71EC3E356A47BF5279971E4EF72A04D860D7F6@WESMSG51.nordsoncorp.local> ``` Excerpts from Brand, Greg's message of Wed Nov 09 19:54:34 -0500 2011: Hi Greg, >                ..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. You've got at least two options to store changes you want to keep but have them kept out of the way. 1. Commit the change on a branch and leave that branch sitting there. 2. Stash the change with a descriptive note. If you're on branch master and want to save this change but not have it 'live' you could do: git checkout -b save_my_change git add modified_file git commit -m 'saving this for later, just in case' git checkout master The master branch will not have the change but the save_my_change branch will. You can see the commit with a command like: git show save_my_change That looks up the sha1 for the ref that save_my_change refers to and then shows the commit object. To re-apply this later, you could merge the branch to master or cherry pick the sha1 to master (or any other branch). The second option, stashing, is likely nicer for this type of thing but ymmv. In your working tree, with the modified file(s), do: git stash save -m 'something potentially useful, but maybe not' Your working tree is now clean and you can see stashes with: git stash list You can later get at a stash with git stash apply. The real gurus may point out something nicer that I didn't think of too... Hope this helps. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 ```