Re: An alternate model for preparing partial commits

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