2009/7/11 Jesus Reyes :
I think this is a feature and not a bug,
Yes, it is how SVN works to show you the original file, but it waists a lot of space (double everything) and it pollutes the directories, so you can't quickly archive the "checked out" directories without pulling in all the .svn one. Alternative is to first export to another location and then archive that. Git you don't have to worry about that, plus Git has the 'git archive' command which does exactly want I intended in the first place - very nice for creating releases.
It would be nice if the same thing could be made with git,
There are many ways to get hold of the original file in the repository. 'git cat' is just one of them, 'git show' is another. But 'git diff' does an excellent job by itself. It has built in pager support, so you can scroll up and down through the diff output, git does color highlighting for your, git also has a pascal language diff improvemnt, so the hunks in the pach (text starting with @@) contains the class name, method name etc.. to which the hunk relates - I find the latter *very* handy.
Then you can also tell git against what you want the diff. If you made many local commits you can compare against them, or if you want to compare against the original version still in "upstream" or "master". You can obviously also do diffs against any revision back in time by specifing the revision, x days ago, etc...
and even as git can hold whole history, it would be interesting to choose any
specific revision to do the diff, how?
Git does not use incremental revision numbers because it is a distributed SCM, so which revision number will be the true revision number? That is why git instead uses a SHA1 which was generated from each commit. This has many advantages. If you want to know if you have the same version as somebody else, you only need to look at the SHA1 instead of the commit details - this is obviously very fast. This also helps merges, etc... so git can easily detect if a local commit which was submitted as a patch and then came back through "master" or "upstream" (patch was accepted at applied), git can savely remove the local commit and apply the new one instead.
If to different repositories had different development paths, but a specific commit ended up havening the same SHA1, it means they file is now exactly the same, no matter the history it took to get there.
In Git you don't have to specify the whole 40 character SHA1, normally the first 7 characters is enough to uniquely identify a SHA1. I must admit, SHA1's were something to get used to, because all previous SCM systems I used, had incremental revision numbers. But SHA1 is more than just a "number" in Git, it tells you that it is cryptographically correct, and contains the history (including moved files, renamed files, directory tree etc) of how you got to that file.
Now if you cloned a SubVersion repository and keep the Git repository as a mirror (like I am doing with FPC and Lazarus), you mights still want to reference the SubVersion revision number. Well, git has support for that. First off, when git cloned the SubVersion repository it added some meta data by default into the commit message (and a few other places) telling you the repository and revision number it came from. To reference a specific revision number like SVN does you can do something like this:
git log -r1354
git log -r2000:2050 -v
etc..
btw how do git deals with revisions? with svn having a short number
tagging a revision is handy even when it could make you crazy like
Well I think I explained that above. You can use any abbreviated version of a full SHA1, though the first 6-8 characters are probably a recommended minimum. Many git commands can be told to only show an abbreviated SHA1 as well. Git also has some other formats you can use which don't require a SHA1 value. HEAD for example points to the last commit in a branch. ORIG_HEAD is the HEAD before you did some big command like 'git fetch' (something like svn checkout). So if you made a mistake, you can even undo the 'git fetch' command. You can also do things like HEAD~4 which means 4 commits before HEAD. The number can be as high or low as you want. You can use tags as well... v1.6~20 meaning 20 commits before the v1.6 tag etc...
It's hardly possible to loose something in git as well. You might have deleted commits from history or undone your last days work etc... Those commits might not appear in any branch or log anymore, but as long as you did not run 'git plune', they are still available as "dangling commits". You can obviously ask git to show you all dangling commits, you can then use 'git show <sha1>' to view those and retrieve them. It is recommended to create a sandbox repository and play around with such commands to get used to the idea that things don't just get lost. This allows you to experiment with more commands a lot quicker.
The git mailing list is also a very friendly environment and they do not mind answering questions from any experience level.
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
