Dependencies for issues

[kolaente]

It would be nice if you could define dependencies for issues.

This would mean you define that this issue (#1) depends on this other (#2), so you can't close the first one (#1) unless the other one (#2) is closed.

[lunny]

A good idea.

[bkcsoft]

As long as it only checks one jump. e.g. #1 => #2 => #3. #1 only checks #2 and #2 only checks #3.

Otherwise the lookup-time would be painful...

[lafriks]

And what about autoclose with commit? Should than pre-receive hook fail?

[lunny]

@bkcsoft So that one issue only dependent only 1 issue?
@lafriks autoclose with commit will then check the dependecies

[kolaente]

@lunny but autoclose commit would then need to also close the other issue. To not make it too complicated, i would propose to not close the issue if it has another one depending on it.

So, if i committed something to #1 to autoclose #1, but #1 depends on #2 and #2 is still open, it would simply not close #1. Maybe a logmessage to the issue why it couldn't be closed.

[lafriks]

@lunny @kolaente There are two options either as @kolaente described not to close issue even if in commit with fixed #1 message or not allow pushing commits for issues that can not be closed yet

[bkcsoft]

@bkcsoft So that one issue only dependent only 1 issue?

@lunny So that one issue only depends on the closest issues

[lunny]

@bkcsoft I mean one issue maybe dependent two or three issues?

[kolaente]

@lunny @bkcsoft I'd say one issue should be able to have more than one dependent issue. (And all dependents must be closed)
Example:
#1 depends on #2, #3 and #4, so #2, #3 and #4 must be closed before #1 can be closed.

[lunny]

@kolaente not only issues, but also pull requests.

[bkcsoft]

@lunny @kolaente Never said anything about multiple dependencies, only that an issue should only be linked to it's closest related dependency.

[kolaente]

I'll start working on this (But bare with me, my go skills are not the best 😁 )