Question about Source Control

[Chris Angelico]

On Wed, Mar 19, 2014 at 1:12 PM, Tim Chase
<python.list at tim.thechases.com> wrote:
> On 2014-03-18 21:38, Terry Reedy wrote:
>> At least with hg, one should best test the code in the working
>> directory *before* committing to the local repository.
>
> I don't know if this is a hg-vs-git way of thinking, but I tend to
> frequently commit things on a private development branch regardless
> of brokenness, but once I get it working, I flatten & clean up those
> changes ("rebase" in git terms, which I believe has been adopted as a
> standardly-available-but-not-enabled-by-default module in hg) into
> logical units of change-sets that I then test individually before
> applying them to my more public-facing branch.  This produces clean
> history that makes it easy for others to see what's going on.

My approach to rebasing is derived from the accountancy concepts my
Dad taught me. You create transactions, invoices, whatever, and you
can freely edit them so long as they're the "current batch". It's very
clear what the current batch is and where history begins. Then when
you update that batch, it becomes history and is indelible; if you
find an error in history, you put a new transaction through that
updates it (or maybe reverses it completely, so you can then do a new
clean transaction), which will have its own date (the date of the
correction) and its own identity. [1] In git terms, that means commits
above origin/master are freely editable, but as soon as anything's
pushed, it's not to be changed. I violate that rule only very VERY
occasionally, and only with the understanding that every clone of the
repo will have to be manually updated.

The "git rebase -i" command is perfect for this - it lets you rewrite
anything that isn't pushed yet, by default. I made myself a hook
script that helps with this; between that and the "autosquash" feature
of git rebase interactive, it's easy to fiddle with unpushed changes.
Let's say you discover a typo in an unpushed commit, and go and fix
the corresponding file. As long as it's a one-file edit, and the most
recent edit to that file is the commit you want to fix up, just type:

$ git commit -amf

or

$ git commit some-file -mf

and it'll make a fixup commit marked with that commit's message. Then:

$ git rebase -i

will notice that (if autosquash is enabled) and offer to squash the
two commits together. In all cases, only unpushed commits are
considered; everything from origin/master is untouchable.

If anyone wants the script, I'm happy to share, though it is
git-specific. Porting it to hg (does hg do hooks? I'm sure it must) is
left as an exercise for the reader :)

ChrisA

[1] Linking this in with a previous thread on identity vs value: a
transaction definitely has an identity, which may or may not be
representable with some sort of database ID field. The identity might
be something like "third row of the current batch" and nothing more,
but it has one.