On Fri, Jun 27, 2008 at 07:57:02PM -0700, Robert Anderson wrote:
quoted text
> On Fri, Jun 27, 2008 at 7:14 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > 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.

Do you think commit only tested changes is a common policy among
Git users? I seriously doubt that. And as I said before, git commit
is probably closer to saving a file than to what cvs commit does.


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.

I don't see it is a problem. In fact, it saves time for me, because
I can work while tests are running, and considering the whole cycle
with different configurations may take 3 hours, I really want to do
something useful while it is running... Besides, I really believe
in review, so it cannot be one-step process anyway...

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. 

If you use CVS like workflow, you may have the policy of no commit
until your patches are reviewed. In case of Git, you do commit but
only push to fast-forward only branch after receiving okay (or the
maintainer pull your changes to it). With Git, commit is more like
saving file, except that you save not a single file but the whole
changeset with the commit message and relevant information.

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.

I don't see why you think that is inefficient or 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.

You have your working directory let's say on Linux, and you have to
test your changes on Windows. So what do you do? With Git, it is
simple as you commit your changes and then run testing automatically
on different platforms and they use exactly what you put into the
repo. So if everything is okay, you can publish.

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.

Do you have your personal experience of using it, or it is just some
abstract considerations? Certainly, any feature may be misused but, in
general, it is handy and I have not had any problem with it. And, yes,
if I split a very complex patch then I will use stash to facilitate
me with this work, but it is rare.

quoted text
> 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.

I don't see why git should know it. The policy depends on workflow
and is usually enforced by hooks. I don't see why Git should care
about it deeply. It is like a word processor can be used for writing
a draft of a document or the final version for publication. Sure,
you can mark something as work-in-progress (use tags or comments),
but it is not something about Git should care deeply inside.

Dmitry
--
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