On Fri, Jun 27, 2008 at 7:14 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
quoted text
> On Fri, Jun 27, 2008 at 10:14:05AM -0700, Robert Anderson wrote:
>>
>> It is too subtle.  That the index state - which becomes the next
>> committed state - is not available for building or testing before
>> committing is a deep flaw.
>
> And why is that? It is like saying that any editor that does not allow
> you to compile the file without saving it first has a deep flaw.

I don't believe it is like that.  It would be like that if you
intended for your on-tree disk to have a policy to always compile (for
example).  That is not a common use-case.

quoted text
> In Git, commits are not the same as in CVS.

I have not suggested they were.

quoted text
> You can commit any changes
> and amend them any time later before you publish your changes.

This is enforcing a two-step process where there only need be one the
vast majority of the time, to require that commit and publish be
separate operations.

quoted text
> Those who care about quality should have a review process, and the
> review process works best when all changes are slit in a small logical
> steps. How do you propose to that without committing changes first?

I don't understand the question.  The entire point of the facility I
am proposing is to facilitate creating small clean changesets.  Go
back and read my original proposal, or Junio's statement of more or
less the same idea, to see how it is proposed to do this.

quoted text
> You can verify it, but you do that _after_ you committed changes but
> before you publish them.

Again, this is requiring two steps when it is otherwise not required,
creating an inefficient workflow that is error prone.

quoted text
> BTW, policy may include that it should be
> compiled and tested on a few platforms, so you cannot do that in
> your working directory anyway.

Huh?  I have done that every day for 15+ years.

quoted text
> I think the source of your confusion is that you consider git commit
> as cvs commit

No.  I have experience with a wide array of source control systems.
CVS fits my mental model the least well.  git is pretty close, but it
is not there yet.  The current partial commit facility is the biggest
misfire, in my view.

I like that git's philosophy does not include a draconian policy of
not changing history.  That's fine, it's practical, and it's useful,
to cover common scenarios in which you'd like to quickly recover from
a mistake.  However, I am afraid that these facilities have been
abused and turned into something that they are not well-suited for,
i.e., the use of lines of development as both keepers of history and
of scratch spaces where you scribble around with temporary things, all
the while git having no clue which is intended.  That these ideas are
conflated is a mistake.  That's my opinion.  These activities ought to
occur in separate, logically distinct spaces in which they occur,
because they have different requirements and common use-cases.

Bob
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html