partial commits

[Jilles Tjoelker]

On Fri, Aug 07, 2009 at 10:49:20PM -0400, Greg Ward wrote:
> On Fri, Aug 7, 2009 at 2:35 PM, Edward Peschko<horos11 at gmail.com> wrote:
> > I haven't seen it with git, I haven't seen it with
> > svn, I haven't seen it with CVS even..

> You won't see this with Subversion or CVS because they have a
> file-oriented view of the world (especially CVS, obviously).  git has
> basically the same worldview as Mercurial -- changesets (aka commits)
> are primary, and files are just the stuff managed by changesets -- so
> they must have some clever trick to avoid this.  I wonder what it is.

> (OK, OK, somehow git avoids this particular nonsense.  So it must be
> possible.  It could just be that Mercurial is being over-protective of
> you by insisting that merges be done in a clean working copy.  That
> seems like a reasonable restriction to me, but what do I know.)

Git's trick is the index, which can be explained as a persistent version
of the selection in a GUI commit tool, including per-hunk selection.
Although it causes a lot of complication, it allows doing and committing
a merge with local changes elsewhere in the tree.

This provides similar safety to mercurial's clean work dir policy: the
index must be unmodified when starting the merge and only the entire
index can be committed for a merge.

It is somewhat better than temporary stashing in that the timestamps of
the local changes are not changed, which may save rebuild time.

-- 
Jilles Tjoelker