Thanks Konstantin,

I started with this approach yesterday.  I tried this:
git clone

... i edited a file just to see what would happen

git checkout <hashcodeOfPriorCommit>

But git did NOT overwrite the file that I manually changed.  Why was that?
 FYI, this won't happen in 'real life" but I was trying to convince myself
that the checkout would work.

On Fri, Jun 14, 2013 at 9:34 AM, Konstantin Khomoutov <> wrote:

> On Fri, 14 Jun 2013 08:23:46 -0500
> Deanna Delapasse <> wrote:
> > Maybe - I wasn't sure if the commit hash would give me JUST the
> > recently committed files or the entire codebase.  I'll try it.
> Neither.  Each commit references one complete snapshot of the
> repository, and also it references one or more parent commits.
> So, knowing the SHA-1 name of a commit gives you:
> 1) A way to recreate the precise state of the repository
>    as it was when that commit was recorded [*].
> 2) An ability to go back through the commit's ancestry line.
> 3) Certain other bits of meta information about the commit
>    author, the committer, the date the commit was recorded etc.
> Each commit in the repository has its own distinct SHA-1 name and
> captures its own distinct state of the repository.
> [*] That's not exactly true: commits are cut from the so-called
>     "staging area", not from the work tree.  And certain information
>     attached to files by the file system underlying the work tree
>     (such as NTFS file streams and Unix permission bits and owner/group
>     information) will be lost.

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 
For more options, visit

Reply via email to