Fwd: An alternate model for preparing partial commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 27, 2008 at 9:03 PM, Dmitry Potapov <dpotapov@xxxxxxxxx> 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.

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

>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux