Fwd: An alternate model for preparing partial commits

From: Robert Anderson <rwa000@gmail.com>
Date: Jun 28, 2008, 06:31 UTC
Message-ID: <9af502e50806272331vfdbf35ap10fc4375518de946@mail.gmail.com>
In-Reply-To: <9af502e50806272320p23f01e8eo4a67c5f6f4476098@mail.gmail.com>

On Fri, Jun 27, 2008 at 9:03 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:

> Do you think commit only tested changes is a common policy among
> Git users?

I think there are various flavors of "tested" for which the answer is certainly yes. I think that a line of development which always builds, for example, is very, very common.

> And as I said before, git commit
> is probably closer to saving a file than to what cvs commit does.

That is putting scm into the development process at a level which is far too intrusively fine-grained for my workflow, and for the workflow of any developer that I work with, which is dozens. I do not need to record every "save of file." That is useless and intrusive to me. It is, however, useful to me to record (commit) at points significantly more coarse grained than that: points which represent logically distinct changes to the code that compile, for example. Until then I prefer to forget about my scm and have it stay out of my way until it is needed to create those desired recorded states.

Show 5 quoted lines

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

Fine, you like doing extra work for no benefit.  Enjoy yourself.

> I don't see why you think that is inefficient or error prone.

Plainly not.  This is why I will construct some examples.

> You have your working directory let's say on Linux, and you have to
> test your changes on Windows. So what do you do?

I rebuild on about a dozen platforms simultaneously on a cross-mounted disk.

Show 6 quoted lines

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

Yes.

> I don't see why git should know it.

Clearly not. Example 1: is it ok to publish? If temporary commits exist, git should stop you. But git has no idea if temporary commits exist or not.

Bob