Re: Hey - A Conceptual Simplication....

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Nov 20, 2009, 01:48 UTC
Message-ID: <20091120014843.GB22556@dpotapov.dyndns.org>
In-Reply-To: <009401ca68bc$7e4b12b0$7ae13810$@com>

On Wed, Nov 18, 2009 at 09:03:31PM -0500, George Dennie wrote:

Show 5 quoted lines

> 
> For example, the functional notion of the repository seems well
> defined: a growing web of immutable commits each created as either an
> isolated commit or more typically an update and/or merger of one or
> more pre-existing commits.

In Git, commits are not immutable. One thing that many Git users do is git-rebase, which in essense is re-writing or re-ordering exising commits. So, you can change history in Git, but you should never change the published history. (Of course, that leads to the question what is considered as published history. For instance, commits merged on the proposed-updates branch are usually not considered to be "published", so they can be re-written or discarded later).

So, the correct way to use Git is to find the right balance between the need to clean up after mistakes (using git-rebase) and not doing too much, so you will not lose important history or create problems for other peoples.

> 
> The notion of a shapeless commit is curious. Intuitively, I consider a
> commit as capturing the state of my work at a transactional boundary
> (i.e. a successful unit test...or even lunch break).

No, it is not what Git commits were intended for. In Git, a commit is a change intended to achieve some goal. Basically, you send a patch to maintainer, and you should explain what this patch does and why it is useful... If your explanation is "I have a lunch break now", it is very bad explanation, thus a bad patch.

Dmitry