¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Single Messages Topics Expanded Polls

Re: Changeset Evolution as an aid to Test Driven Development.

 

> I'm? with Ron on this. I want the history to be clean, for sure, but even more I want it to be correct. That means it should reflect what I did in the order that I did it.

I admit I used to do that, I wanted the commit log to be static so it reflected the experimentation and testing I have done, and hence resisted using this tool.

However, I can still get that from following the predecessor successor nodes in mercurial if I want.... and I find in practice I seldom want.

But as I discovered the advantages of sequencing the types of commit to achieve more useful purposes... I have willingly abandoned that without a backward glance.

Admittedly I'm now dreaming of a CI system that will wake up on every commit or evolve, rather than on a push, and will prove the invariant (after every evolution every changeset on the branch passes).

It should also be able to automagically isolate the transformation that broke it...

That is something that should be automatable.

Yup, it will require some hefty compute power (and/or cunning algorithms) and I'm quietly brewing plans for that in the back of my head.

Pretending I wasn't so stupid in the past is by far the weakest reason for doing this. (A nice warm fuzzy feeling of absolution maybe, takes some of the bite out of imposter syndrome maybe, but a lousy reason).

The powerful growing observability and diffing logs debug technique is an excellent reason.

Having strong proofs, that just keep getting stronger, that refactorings are indeed pure refactorings is an excellent reason.

The "keeping up with the herd of cats" to avoid Bing Bang integrations is an excellent reason.

Being able to drop the extended unit tests into the mainline to stop the herd of cats accidentally breaking things, even if the rest of the branch isn't ready, is an excellent reason.

Floods of microcommits of "obviously correct" tiny refactorings is an excellent reason.

Using coverage analysis to see where you're starting to walk on shaky ground, and then retroactively? brace with unit tests _before_ all your changes is an excellent reason.


On Tue, Jun 15, 2021 at 9:55 AM Charlie Poole <charliepoole@...> wrote:

I'm? with Ron on this. I want the history to be clean, for sure, but even more I want it to be correct. That means it should reflect what I did in the order that I did it. For example, maybe I got carried away in refactoring and made real (behavioral) changes, which broke some tests. If I haven't yet committed, I can fix that locally. But if I have, I'll leave it in and make a correction. Some of those corrections may be a bit embarrassing, but that will help me remember to do it right next time.

One thing I sometimes do, which is similar to what the OP suggests: When working on a script, which __only runs on a particular CI server _ (e.g. AppVeyor), it may take me several tries to get it right, especially if I don't fully understand how the CI server works. In that case, I'll eventually do a rebase, eliminating all my failed attempts. So sue me!

Charlie

On Mon, Jun 14, 2021 at 2:45 PM Ron Jeffries <ronjeffriesacm@...> wrote:
Hi Al,

sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.

On Jun 14, 2021, at 9:22 AM, Al Chou via <hotfusionman=[email protected]> wrote:

?I can't remember or quickly find the blog post where I first saw it espoused to treat your private "feature" (in Git Flow terminology) as your own to rewrite commit history as you wish. I do it very frequently to better-organize the content of commits (e.g, pretend I wrote those tests at the same time as the production code and glom them together into the same new commit by squishing the two commits together, which has the advantage of making them an atomic package). I admit I only skimmed John's original post in the current thread, but I got the impression that's the kind of thing he was saying he uses the ability to rewrite VCS history for.

Yes, sounds similar. Why do you want to pretend those things? Do you go back and read the revised history or something? I wonder, because I always work on the tip of the spear, and only very rarely check out a prior version, generally to figure out when something changed. When I do feel the need to do that, I usually consider it a bit of a failure.

I'm about what the code is now?so I truly think wonder why folks care about the order of things in the past.?

Thanks,

R



--
John Carter
Tait Electronics? ? ? ? ? ? ? ? ?? ? ???
New Zealand


This Communication is Confidential. We only send and receive email on the
basis of the terms set out at

Join [email protected] to automatically receive all group messages.