What if a commit fixes a bug, but it's not marked as fixed before in a later commit? Then you wouldn't have the implicit connection anymore.
Though I guess sometimes having an implicit connection is better than never having one, people just have to make sure to not commit an issue as solved in a separate commit if they find out after it's pushed.
Maybe an optional field to specify what commit an issue was fixed in? Then the CLI could have an option to look at HEAD similar to how git does.
I definitely agree! That's one of the features I love about Phabricator Maniphest: you can link commits, pull requests (Differentials, on that platform), and issues together in any fashion.
I think part of this is a matter of training developer habits. Since the commit would typically go through a PR, the lack of a closed task could actually be something a reviewer could catch. But, since what's done is done, the developer would still need to manually associate the task with the commit.
Perhaps it would be useful to have some sort of optional notation: you could say -1 for the commit number, to say "back one".
What if a commit fixes a bug, but it's not marked as fixed before in a later commit? Then you wouldn't have the implicit connection anymore.
Though I guess sometimes having an implicit connection is better than never having one, people just have to make sure to not commit an issue as solved in a separate commit if they find out after it's pushed.
Maybe an optional field to specify what commit an issue was fixed in? Then the CLI could have an option to look at HEAD similar to how git does.
I love the idea to link issue (and fixes) to a git commit. This is something we don't find in tracker.
I don't use git bisect but maybe another field to specify where the issue started can be useful too.
I definitely agree! That's one of the features I love about Phabricator Maniphest: you can link commits, pull requests (Differentials, on that platform), and issues together in any fashion.
I think part of this is a matter of training developer habits. Since the commit would typically go through a PR, the lack of a closed task could actually be something a reviewer could catch. But, since what's done is done, the developer would still need to manually associate the task with the commit.
Perhaps it would be useful to have some sort of optional notation: you could say
-1for the commit number, to say "back one".I think consistency with git would be essential, so HEAD1 and HEAD~1 and short/partial hash