Re: An alternate model for preparing partial commits

[Jakub Narebski <jnareb@gmail.com>]

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

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