Re: Fwd: An alternate model for preparing partial commits

[Dmitry Potapov <dpotapov@gmail.com>]

On Fri, Jun 27, 2008 at 11:31:24PM -0700, Robert Anderson wrote:
> 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.

Well, I don't think it is very common. Almost always builds, yes. As I
said before, with Git commit means more like saving your changes in
logical steps. Making sure that they are good enough to be publish is
done later, and it usually includes testing and may include something
else like code review, and code review is much easier if your work is
recorded in small logical steps, and when you can share these changes
easily and continue your normal work while your changes are reviewed.

> >> 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 where you find this extra work. Maybe, pressing a button
to save the file is also extra work? As to benefit, they are real for
me as it saves a lot of time and allows me to work more natural, in
the same way as you edit document. Your first version of document
does not have to be perfect, you can review and improve it later,
instead you focus on main ideas you want to express, and later, you
will proofread and rearrange things, but it is very important to
being able to save your changes even if they are not perfect yet.
Extra work like pressing the save button is negligible comparing
to everything else.

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

Does it work for MS Visual Studio? The last time I tried, it did not
allow to build the project on a shared disk. Anyway, your compilation
time is going to be worse due to network latency, and simultaneously
building on different platforms will be more difficult to organize.
With Git, you get everything for free. You committed your changes
and they immediately available everywhere, and when all tests passed
you can push changes to the main branch, or send to the integrator a
request to pull, or to send a request to code review. It all depends
on your policy...

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

There are no such thing as temporary commits in Git. There are changes
that are ready to be accepted to the main branch and those that are not.
It could be different reasons why these changes cannot be integrated to
the main branch now.  Maybe, you should receive feedback from someone
who does code review your changes.  Maybe, these changes deem too risky
to be integrated now. Maybe, they will clash with someone else's work,
which has a higher priority, maybe something else.  So, I don't see how
you expect Git to know all of that. It is like to expect that your word
processor to know what whether your document is good work publication or
not, and don't let you to send the document out if it is not.

Dmitry