[darcs-devel] [patch1743] rename test for issue1702 to mark as fai... (and 3 more)

Ben Franksen bugs at darcs.net
Mon Nov 19 02:12:11 UTC 2018


Ben Franksen <ben.franksen at online.de> added the comment:

>>   * rename test for issue1702 to mark as failing
> 
> Fine, I've lost track of what's actually going on with this test,

The test is fine but optimize relink doesn't (fully) work as expected
(the link count is 2, not 3) and I have no idea why.

>>  * fix in output of log command
>>    I think the 'not' here got lost during a refactor.
> 
> This also changes a variable reference from 'files' to 'paths'
> and doesn't compile for me yet (as you already warned about).
> I'll come back to it once I find whatever other patch makes it work.

I think I did some of these files->paths renames in the course of the
FileName->AnchoredPath refactor.

> In general patches with "extra" changes often cause disproportionate
> effort on the reviewing side for this kind of reason. But it's only
> an occasional issue so no big deal, and to a large extent it's my
> own fault for being so far behind on reviewing.

There are other factors that come into play here. One lesson is that
being able to commute patches is not always a win. Here I should have
put in a semantic i.e. explicit dependency, but it is hard to think of
such things at the right time. It would help if darcs could
automatically add dependencies based on the outcome of a test. I am
thinking of something similar to 'darcs test': obliterate one patch
after the other (if dependencies allow it) until the test (cabal build,
whatever) fails, in that case add the patch to the list of dependencies
and continue until we hit a clean tag or some such.

Another lesson for me is to try harder to avoid mixing "extra" changes
with a refactor or bug fix. I have become better at this but now and
again I still forget to record such changes separately. Doing such a
separation as an afterthought can be a very tedious affair up to the
point at which it is easier to throw away all changes to a file and
re-do the them manually. I also find myself using amend --unrecord a lot
lately to pull apart things I previously lumped together in a single patch.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1743>
__________________________________


More information about the darcs-devel mailing list