Back to issue list Export

I originally thought that I could get away without having issue dependency fields for issues. However, something at work has convinced me that I do need them, so add them.

travisb 2012-07-19 14:19:24
hash: 1d0d915363db035f499b242ec6ba1c968efaf399dda16c32f6186cbb7129b9b4
Date: 2012-07-19 14:19:24
User: travisb

Through discussion with bug tracker users it would also be very useful to have automatically propagated duplicate bug metadata. So have that as well.

travisb 2012-07-19 20:02:02
hash: bf365b83a535325725e4f484f200f240bc40fcb7b222cb53ea24a1faae6f5076
Date: 2012-07-19 20:02:02
User: travisb

One interesting issue would be flattening the duplicate graph (and possibly also the dependency graph). Not flattening it would be easy, but less user friendly.

travisb 2012-07-19 20:06:13
hash: 42cf948781f218deff8393eb5cfef3d97ea7c39ab03880e11424e34af2ada006
Date: 2012-07-19 20:06:13
User: travisb

This has been left for 09100e3a

travisb 2012-07-19 23:46:40
hash: d85635daf933589706ef6e23f0f5ba10c1b49a589eed42e6d37303d969e06c5f
Date: 2012-07-19 23:46:40
User: travisb

Support for this has been added. However, existing Nitpick repositories won't have all the metadata required to be compatible. The quickest way to solve the issue is to update the metadata of the issues outside Nitpick. To do this you first need to write a small script such as: #!/bin/bash awk '/--/ {print "Depends_On:\nDuplicate_Of:";} {print}' $1 > $1.tmp mv $1.tmp $1 I called this script Then in each of the project directories you can run the command: find .nitpick -name issue -exec /path/to/ \{\} \; After that is done you should test with Nitpick and if the issues load fine you can go ahead and commit this change manually.

Tracked by Nitpick