Re: An alternate model for preparing partial commits

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Jun 28, 2008, 04:03 UTC
Message-ID: <20080628040344.GK5737@dpotapov.dyndns.org>
In-Reply-To: <9af502e50806271957o2df9e0abt9dadcb0514dd4173@mail.gmail.com>

On Fri, Jun 27, 2008 at 07:57:02PM -0700, Robert Anderson wrote:

Show 13 quoted lines

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

Show 6 quoted lines

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

Show 6 quoted lines

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

Show 5 quoted lines

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

Show 6 quoted lines

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

Show 8 quoted lines

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

Show 8 quoted lines

> 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