Re: [git-users] Some clarification on what Git is actually doing, please
On 1 June 2015 at 20:12, Tim Dawson trhdaw...@gmail.com wrote: Thank you, Konstantin. That's quite a lot to take in with one read-through, so I'll study it more carefully as I go forward. I'm finding Git a whole lot better than giving files slightly different names and trying to remember which one went with another! Yes, read about it and use it. That's a good way to learn :) Also, if you are curious about stuff surrounding git I can recommend [git minutes](http://www.gitminutes.com/). /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Some clarification on what Git is actually doing, please
On Tue, 2 Jun 2015 09:32:35 +0200 Magnus Therning mag...@therning.org wrote: That's quite a lot to take in with one read-through, so I'll study it more carefully as I go forward. I'm finding Git a whole lot better than giving files slightly different names and trying to remember which one went with another! Yes, read about it and use it. That's a good way to learn :) Also, if you are curious about stuff surrounding git I can recommend [git minutes](http://www.gitminutes.com/). I would also recommend The Git Parable [1] -- it's fun to read but provides a good insight on how data is actually managed by a DVCS. 1. http://tom.preston-werner.com/2009/05/19/the-git-parable.html -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Some clarification on what Git is actually doing, please
On Sat, 30 May 2015 10:53:47 -0700 (PDT) Tim Dawson trhdaw...@gmail.com wrote: I'm fairly new to Git. I've learned how to commit, branch etc. I'm working on a web site which has problems with cross-browser compatibility. I have created a branch called 'no-flex' in which I've created new files to try out a completely different set of CSS styling to a stand-alone web page. This has been successful. I have committed the new files in the 'no-flex' branch. I now want to introduce this new approach to styling to the 'master' branch, which contains files for the entire web site. I need the new files so that I can refer to them and probably do a bit of copy paste. If I simply go back to the master branch I think I will lose my 'no-flex' files, No, you won't lose these files. Since you've committed them, they will be available via that 'no-flex' branch no matter what you check out or commit. Note that, as most (all?) SCMs, Git is generally an append-only solution -- at least history-wise. Sure, you're able to delete branches, and rewrite them, but most of the time you just add stuff to the repository. so I think I need to checkout (i.e. go back to) master and merge 'no-flex'. Is that correct ? No, not quite. See below. This will result in my new files becoming part of the master branch. But they aren't really part of the main web site, they are just a side excursion to try something out. Eventually when I've milked them for their content they will become redundant (though I probably won't want to delete them from my computer). That's a very keen observation indeed, congrats with this! Merging means -- both logically and physically -- bring the changes made on the branch I'm merging into the branch which is currently checked out, so yes, in this case merging is not what you need. Many of the files in the master branch will get changed radically in the process, some may no longer be needed, and there will be some new ones. The final result will be a web site that looks much the same as now, but whose CSS (and other) files will be incompatible with the current version. Yes, this is understandable. As to what finally do with your 'no-flex' branch and its relation to 'master' branch, see below. Perhaps this is exactly what Git does best, but I have a few concerns: 1. What does Git actually do with a file that exists in an un-merged branch if I go back to the master branch ? Nothing at all. The only ways to lose these files are: * Delete all the references (tags and branches) which, directly or indirectly has the commits containing these files in their history. * Rewrite histories of such references (via `git rebase`, `git filter-branch` etc). And even after you've tried hard to send your committed files into oblivion, they will still be recoverable via the reflog mechanism: Git by default logs all drastic movements of tip commits of their branches, and this log is kept for a hefty amount of days before entries in it get expired and deleted. (Drastic movements are those which are not due to normal committing.) 2. Will that file still be visible in the directory tree of my text editor ? (I think not) That is correct. The whole point of a branch is to provide you with a line of development separate from all the other lines of development. So when you check out another branch, Git makes sure your work tree looks like the state of your project recorded in the tip commit of this branch. (Well, untracked files which do not conflict with the files about to be checked out will be left intact.) 3. What does Git do if I delete a previously committed file from my directory tree ? Nothing beyond noticing the file appears to be missing compared to the tip commit of the currently checked out branch (the HEAD). You will have an option to confirm your deletion -- by staging it for the inclusion in the next commit or to undo it. Git suggests you both of these actions when you run `git status` -- as Magnus already explained. 4. When I've finished with the files from the 'no-flex' branch, do I retain them in the current version, or unstage them so they become untracked (but don't get deleted) ? This may be a matter of choice, but what is best practice ? Well, first, there's no point to mess with the 'no-flex' branch at all. What would unstaging its files get to you? Return the state of the files recorded at its tip to that it had right before you forked it off 'master'. But what's the point, really? You don't supposedly intend to work on it, as it was a one-off gig, right? Hence you basically have several sensible choices: * Just delete this branch (possibly after implementing the similar changes on 'master' -- see below for more). The command to do this is `git branch -d` (or -D). * Rename it to something meaning it's obsolete, like 'attic/no-flex' or 'closed/no-flex'. The command to do this is `git branch -m`. * Replace it with a tag. Tags
Re: [git-users] Some clarification on what Git is actually doing, please
On 1 June 2015 at 09:42, Tim Dawson trhdaw...@gmail.com wrote: Thank you, Magnus. That confirms what I thought. I think my problem is that Git's power seems almost magical, and I hesitate to believe in it. Tim I don't know about that ;) The best advice I have for anyone learning git is to play with it. It is *extremely* easy to clone and set up new repos, so the barrier to run experiments is negligible. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Some clarification on what Git is actually doing, please
Thank you, Magnus. That confirms what I thought. I think my problem is that Git's power seems almost magical, and I hesitate to believe in it. Tim -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Some clarification on what Git is actually doing, please
Thank you, Magnus. That confirms what I thought. I think my problem is that Git's power seems almost magical, and I hesitate to believe in it. Tim On Sunday, 31 May 2015 10:03:33 UTC+1, Magnus Therning wrote: On Sat, May 30, 2015 at 10:53:47AM -0700, Tim Dawson wrote: I'm fairly new to Git. I've learned how to commit, branch etc. I'm working on a web site which has problems with cross-browser compatibility. I have created a branch called 'no-flex' in which I've created new files to try out a completely different set of CSS styling to a stand-alone web page. This has been successful. I have committed the new files in the 'no-flex' branch. I now want to introduce this new approach to styling to the 'master' branch, which contains files for the entire web site. I need the new files so that I can refer to them and probably do a bit of copy paste. If I simply go back to the master branch I think I will lose my 'no-flex' files, so I think I need to checkout (i.e. go back to) master and merge 'no-flex'. Is that correct ? This will result in my new files becoming part of the master branch. But they aren't really part of the main web site, they are just a side excursion to try something out. Eventually when I've milked them for their content they will become redundant (though I probably won't want to delete them from my computer). Many of the files in the master branch will get changed radically in the process, some may no longer be needed, and there will be some new ones. The final result will be a web site that looks much the same as now, but whose CSS (and other) files will be incompatible with the current version. Perhaps this is exactly what Git does best, but I have a few concerns: 1. What does Git actually do with a file that exists in an un-merged branch if I go back to the master branch ? All files that are committed on a branch will remain, and you can at any time check out that branch and you'll find the files in your work area. In fact, this is one of the core pieces of functionality in any VCS 2. Will that file still be visible in the directory tree of my text editor ? (I think not) Your work area will reflect the branch (or more generally, the point in history) you have checked out. So, if the file in question doesn't exist in the branch you have checked out you won't have it in your work area. 3. What does Git do if I delete a previously committed file from my directory tree ? Just try it! Remove a file that you have committed and then run `git status`. You'll see that git notices that the file now is missing. At that point you can either restore it (`git checkout file name`) or stage a removal (`git rm file name`). 4. When I've finished with the files from the 'no-flex' branch, do I retain them in the current version, or unstage them so they become untracked (but don't get deleted) ? This may be a matter of choice, but what is best practice ? Check them in on the 'no-flex' branch. Keeping versions of files is exactly what git is for :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org javascript: jabber: mag...@therning.org javascript: twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Some clarification on what Git is actually doing, please
Thank you, Konstantin. That's quite a lot to take in with one read-through, so I'll study it more carefully as I go forward. I'm finding Git a whole lot better than giving files slightly different names and trying to remember which one went with another! Regards, Tim Dawson -- Tim Dawson Maolbhuidhe Fionnphort Isle of Mull PA66 6BP 01681 700718 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Some clarification on what Git is actually doing, please
On Sat, May 30, 2015 at 10:53:47AM -0700, Tim Dawson wrote: I'm fairly new to Git. I've learned how to commit, branch etc. I'm working on a web site which has problems with cross-browser compatibility. I have created a branch called 'no-flex' in which I've created new files to try out a completely different set of CSS styling to a stand-alone web page. This has been successful. I have committed the new files in the 'no-flex' branch. I now want to introduce this new approach to styling to the 'master' branch, which contains files for the entire web site. I need the new files so that I can refer to them and probably do a bit of copy paste. If I simply go back to the master branch I think I will lose my 'no-flex' files, so I think I need to checkout (i.e. go back to) master and merge 'no-flex'. Is that correct ? This will result in my new files becoming part of the master branch. But they aren't really part of the main web site, they are just a side excursion to try something out. Eventually when I've milked them for their content they will become redundant (though I probably won't want to delete them from my computer). Many of the files in the master branch will get changed radically in the process, some may no longer be needed, and there will be some new ones. The final result will be a web site that looks much the same as now, but whose CSS (and other) files will be incompatible with the current version. Perhaps this is exactly what Git does best, but I have a few concerns: 1. What does Git actually do with a file that exists in an un-merged branch if I go back to the master branch ? All files that are committed on a branch will remain, and you can at any time check out that branch and you'll find the files in your work area. In fact, this is one of the core pieces of functionality in any VCS 2. Will that file still be visible in the directory tree of my text editor ? (I think not) Your work area will reflect the branch (or more generally, the point in history) you have checked out. So, if the file in question doesn't exist in the branch you have checked out you won't have it in your work area. 3. What does Git do if I delete a previously committed file from my directory tree ? Just try it! Remove a file that you have committed and then run `git status`. You'll see that git notices that the file now is missing. At that point you can either restore it (`git checkout file name`) or stage a removal (`git rm file name`). 4. When I've finished with the files from the 'no-flex' branch, do I retain them in the current version, or unstage them so they become untracked (but don't get deleted) ? This may be a matter of choice, but what is best practice ? Check them in on the 'no-flex' branch. Keeping versions of files is exactly what git is for :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. pgp9cLTXhZZwx.pgp Description: PGP signature
