Re: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 6 Apr 2015 15:01:22 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > I actually don't understand why those changes were pushed piecemeal,
> > and not as a single commit.  They sound like a single changeset to me.
> 
> There are many ways to divide changes into changesets. Sorry if mine
> was a little too detailed. The way I learned to do DVCS was to make
> commits small enough to be human-readable, but large enough that each
> one corresponds to a full working state (all tests passing, etc).

What's below follows my personal preferences, so please don't take it
as a mandatory requirement of some sort, just food for thought.

> Each one of these commits makes a significant change to at least 2
> functions, and I found them hard to read in a single commit so I split
> into a few. (In retrospect, the "package-install" commit turned out a
> bit trivial, and could be part of another one).

What I would do in this situation is work on a branch, make
fine-grained commits there, and then merge them all onto master in a
single merge-commit.  Then, if someone follows first-parent, they'd
see a single commit with the feature, while still being able to
discern the separate commits you made during development.

IOW, I personally prefer not to see partial commits when I follow
first-parents.

> Do we have an objective definition of what a changeset should be?

No, it's a judgment call.  For me, an important question that helps
the decision is "will I ever want to revert that single changeset?"
YMMV, most probably.