Changes between Version 4 and Version 5 of GitWorkflow

Timestamp:

03/22/09 01:34:52 (4 years ago)

Author:

cdavid

Comment:

--

GitWorkflow

@@ -124 +124 @@
 }}}
 
-The -m option has the same meaning as the svn commit command. By default (without the "-a"), git only commits the changes you explicitly told him about with the add command (TODO: ref to git-specific workflows). Although extremely useful, it can be a bit confusing at first when you come from a svn background, hence the -a option.
+The -m option has the same meaning as the svn commit command. By default (without the "-a"), git only commits the changes you explicitly told him about with the add command. Although extremely useful, it can be a bit confusing at first when you come from a svn background, hence the -a option.
 
 A big difference of git compared to svn which cannot be skipped even at this level: git clone gives you a working tree (a snapshot of the sources at one revision) AND the repository with the full history. It means in particular that committing a change will NOT propagate it to the original repository you cloned from. For this, you need to use push:
@@ -153 +153 @@
 
 You are not really adding the file foo.c to the repository, but you add its content to the git repository. By default, and without the '-a' option, a commit will NOT include content which has not been added with git add - the '-a' option is equivalent to do an add on every changed file, and then commit. The index is thus a staging area between your working tree (the files as they are on your filesystem) and the repository (the set of commits).
+
+== Commits, sha1 and versions ==
+
+One thing which does not seem right at first in git is the notion of sha1 for "versions". Each commit has a unique number, which is a sha1 (a checksum), and not a plain integer as in svn. The lack for simple integer is inherent to DVCS, and branches in general. Indeed, simple integers only make sense when where is only one line of changes (the trunk), but once you have several branches, numbers are intermixed, and the ordering does not make sense. In git, by design, each commit sha1 depends on the commit content as well as its parents (so the sha1 act as a secure mechanism: if one commit is changed, every other commit below in the graph will have its number changed as well, to prevent malicious content change).
+
+Now, this hardly matters from a user POV, because you usually do not use sha1 to refer to a commit. You use either branch names, tags (which are just a "pretty" name to a commit in git), dates, etc...:
+
+{{{
+# Look at the last commit:
+git show HEAD
+# Look at the last commit parent:
+git show HEAD^
+# Look at the log of changes made the last 2 days
+git log --since="2 days"
+}}}
 
 == Scenario 1: creating a new branch ==