Re: An alternate model for preparing partial commits

["Robert Anderson" <rwa000@gmail.com>]

On Sat, Jun 28, 2008 at 10:12 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Robert Anderson" <rwa000@gmail.com> writes:
>
>> On Sat, Jun 28, 2008 at 7:34 AM, Stephen Sinclair <radarsat1@gmail.com> wrote:
>> > The answer is simple: you should not be making partial commits to a
>> > repo that has been cloned.  You should instead be working somewhere
>> > else and then pushing to it.  So this whole sentence is just a moot
>> > point itself.
>>
>> Let me amplify my objection to this.
>>
>> Who has 100% foresight that what they are doing is going to end up in
>> a state where they'd like to make partial commits?  To take a quote
>> from a blog post, 'Git means never having to say, "you should have"'.
>> And mostly it doesn't, and that's big improvement over other systems.
>> But, that is what you are saying here.  I "should have" realized that
>> I should have pulled and fiddled with my changes there, and then
>> pushed.
>>
>> Well, Dmitri and others will now say, why not just always pull and
>> work somewhere else?  And the reason is that because this creates
>> extra, unnecessary steps the vast majority of the time when I do
>> create a commit that I like and want to keep as-is in the first try.
>> Why should I have to pull, commit, hack, and push, when hack and
>> commit is all I need to do the vast majority of the time?  It is
>> redundant, unnecessary work and complexity that I should not have to
>> pay for when I don't need it.
>
> I think that in most cases the setup looks like the following: there
> is private non-bare repository, ehere you can use topic branches,
> and change and rewrite those changes at will, be it using plain rebase,
> rebase --interactive, or some patch management interface like StGit
> or Guilt.  That is where you clean up your commits till they all fill
> some standards / convention, like compiling (at least), or pass the
> testsuite.

In my opinion it looks like that because git has poor support for
creating good partial commits the first time around.

I also think all of this rebase -i style approach is fine for an
experienced power user if they like that approach, but that splitting
the changes in a working tree is a very basic usage that should be a
part of a "Git in 20 minutes" tutorial.  StGit, rebase -i, etc.,
should not.

In my experience this is pretty much the *first* thing a developer
faces when they decide that having a good incremental change history
is a good practice they want to follow.  They usually shrug, commit
the hairball, and resolve to do better next time.  But this is an
unavoidable scenario in real world development, and a good SCM manager
should have convenient facilities for dealing with it, that don't
reach into the power user toolbox like rebase -i (and let's face it,
that is an absurdly counterintuitive command for the job at hand), or
require auxilliary tools like StGit.  The index is a start.  But, IMO,
it isn't sufficient.

Stay tuned for some proposals about improving partial commit support.

Thanks,
Bob