emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: base


From: Óscar Fuentes
Subject: Re: base
Date: Thu, 26 Aug 2010 16:42:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

> So you are saying that there's no way a user can understand how to use
> git efficiently without knowing about SHA1, hashes, blobs, index
> files, and how they all live happily in disk files and point to one
> another?

It is perfectly possible to use git without knowing its model, in the
sense that you can store your changes on the repo, see logs, etc. More
or less like CVS or Subversion (or Bazaar!) where the user knows recipes
for dealing with a restricted, mostly simplistic, set of
requirements. On the long term (or not so long) it is not the most
cost-effective approach.

For any dVCS, revision IDs are a core concept. A user that doesn't
understand revision IDs eventually will suffer the consequences of his
ignorance. That applies to git's SHA1 hashes and to whatever bzr uses as
IDs. Blobs and trees are on the foundations of git and defines how it
stores information. Having some knowledge about them makes easy to
understand why git does not track empty directories, how file renaming
is (un)supported, why some operations are blazingly fast but others
(`annotate') are not, etc. The index is one of the most useful
innovations of git. If you insist on ignoring its existence you are
missing a really good feature. Almost every operation in git is about
creating trees, blobs and updating pointers (refs). Do you want to see a
file on another branch without switching to it? If you know about refs,
trees and blobs, it is straightforward. Want to temporaly reset your
working copy to some point on the past? If you know what a git ref is
then you already know that it is possible. Refs are arranged on the file
system on the same way you can name them (i.e. "git log
refs/remotes/origin/master" will work fine)

You will agree that having an insight on how a tool is designed
increases your effectiveness while using it. Some tools makes easy to
gain that insight, because its design is simple enough, or because its
documentation is very good. Such a tool has an advantage over its
competitors.

[snip]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]