partial commits

[Greg Ward]

On Fri, Aug 7, 2009 at 2:35 PM, Edward Peschko<horos11 at gmail.com> wrote:
> of course.. I'm working with other people, they've been modifying whilst
> I've been modifying.. My point is that, IMO, people shouldn't have to be
> forced to their current working directories and rebuild the world to
> support partial commits.

Ahh, right, I get it.  Hmmm.  Not sure of a good solution offhand, but
I see how it's happening.

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

> I need to (in addition to doing the original commit):
>
>      1. have 2 separate repositories
>      2. go to another directory
>      3  do a pull 1 file commit from a separate repository
>      3. do yet another pull from upstream.
>      4. commit that merge in the other directory
>      5. push to original directory.

Yeah, that's clunky as heck.

> Hg attic will work for me, but I would think that hg would want that
> functionality in the core, and probably integrated into hg update..

I think the last time anyone suggested attic for the core, there was
some concern about possible confusion with MQ -- in implementation
terms, they overlap slightly.  (Personally, I think the main use cases
are sufficiently different that it's not a huge concern.)

> If on the other hand, you are saying that this error (multiple branches)
> should only occur when the files that you are committing and pushing
> to the central depot have already been changed by somebody else,
> then I agree with you. Mercurial should not behave that way. It should
> be smart enough to realize to look at the central repository and see that
> the files you are committing have not been changed and do the push regardless.

I know where you're coming from: I used to think Mercurial should work
this way too.  You have to get away from thinking about files as the
primary abstraction.  They're not.  That view of the world started to
go out of fashion 10 years ago when Subversion came along, and Git and
Mercurial are doing everything in their power to obliterate it.  *The
changeset is primary*.  Changesets are the alpha and the omega.  Files
are just an implementation detail.

Once you bow to the inevitable, drink the kool-aid, and accept that
"yes, master, the changeset rules all" (chanted in a cult-like
monotone), everything makes sense and you will put up with any amount
of nonsense.

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

> However I'm using 0.9.4 and am reticent to upgrade because of potential
> incompatibility issues, and I cannot upgrade my depot version of hg. But
> I will download attic and see how well it works for my needs.

Which incompatibility issues in particular?  Mercurial moves fairly
fast, and that's a pretty old version.  You really should try your
workflow with 1.3.1 first.  Like, before posting.

Greg