Re: An alternate model for preparing partial commits

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

On Fri, Jun 27, 2008 at 4:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Robert Anderson" <rwa000@gmail.com> writes:
>
>> There are good reasons for desiring a workflow that does not routinely
>> change history as part of the usual workflow.  Maybe there are clones
>> of your repo.  Maybe as part of your workflow discipline you do not
>> want HEAD states that cannot be pushed to public, because you don't
>> want to manually keep track of when it is ok and when it is not ok to
>> push HEAD to public, since git cannot tell you this.
>
> Surely you can arrange that.  You keep track of what you pushed out, and
> you refrain from rebasing beyond that point.

First, the constraint of achieving this workflow when there are clones
of the repo in question removes any need for additional rationales.

That being said...

In the existing model which is being suggested as a way to get the
desired workflow, there are two distinct classes of commits:  commits
that are "for real", and commits that are "temporary", that are being
used as some kind of workspace for orthogonalizing a set of changes,
which will eventually be replaced by "for real" commits.  Yet git has
no metadata to distinguish these two types of commits.  When only "for
real" commits exist, I can push HEAD.  When "temporary" commits exist,
I cannot, or insidious problems will ensue.  This metadata concerning
"for real" or "temporary" commits is only maintained manually in the
developer's head.  But, this is the sort of thing that computers are
for, and should not be the burden of the developer to maintain this
information in his mental cache, especially when the price of making
an error can be quite high.  It would be very easy to forget that you
intended to do more work on your last N commits, and push HEAD because
somebody asks you to make sure you've pushed your latest work.  Your
tools should prevent this kind of scenario.  Git cannot, because it
doesn't know what you intend when you "commit" because two different
ideas are being conflated with "commit" in this model.

In my proposed model, there is a clear distinction, kept track of by
git, not the developer, between changes which are in the "temporary
workspace" which is still being worked on, and changes which are "for
real", that can be shared, either through a push to a public repo or
if there are clones of my repo.  They become "for real" when they are
committed.  That's the purpose of a "commit" in this workflow.  To
bless a change as ready for viewing by others, even if you do not want
to make it available yet (by a push to a public repo).  I can walk
away from a working tree for six months, come back, and there can be
no confusion about which changes were "temporary" and possibly in need
of revision, and which changes are blessed as ready for public
consumption.  If I come back to a branch on which there are several
commits which have not been pushed yet, how do I know which are
"temporary" and which are "for real" commits?  I cannot.  It is
impossible.  The information is not there.

But, all of this is moot when you consider the simple case of a repo
which has been cloned, on which you'd like to make partial commits,
and test the committed state before doing so.

Thanks,
Bob