Re: An alternate model for preparing partial commits

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 28, 2008, 17:12 UTC
Message-ID: <m3d4m1iivq.fsf@localhost.localdomain>
In-Reply-To: <9af502e50806280930u788f81e2j77adf147a0e4d135@mail.gmail.com>

"Robert Anderson" <rwa000@gmail.com> writes:

Show 24 quoted lines

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

Then you merge it into one of long-lived "development" branches, and push to your public (usually bare) publishing repository, which can be for example on repo.or.cz, or on kernel.org.

That said "git stash (save|apply) --interactive" would be good improvement for the situation where you have realized that you have several unrelated changes in working directory, and want to decouple them. One solution would be to commit, then split using interactive rebase (or patch management tool), but with stash I guess it could be simpler.

You should avoid such situation by stashing and changing the branch, or refrshing current patch (to return to it later) and generating new one if you use StGit or Guilt...

-- 
Jakub Narebski
Poland
ShadeHawk on #git