On Fri, 20 Nov 2009, Dmitry Potapov wrote:
On Wed, Nov 18, 2009 at 09:03:31PM -0500, George Dennie wrote:
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 typical advice is to clean up before you make changes public, but not
afterwords.
David Lang
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html