Choose wisely when to use issue inference

[shubhamshuklaer]

trafficstars

This problem was originally reported by @caifara in a different issue(#289) . I am just creating a separate issue for it.

When issue inference is possible(for eg on a branch named 288_fix) the following commands causes problem

• ghi open abc -m "Hello how are you" instead of creating a new issue just shows the inferred issue or re-opens it if its closed.
• ghi milestone -l instead of listing all open milestones just shows the milestone assigned to the inferred issue.
• The same problem with ghi milestone abc -m "Hello".

Actually we do need some way to

• reopen or show the inferred issue.
• show the milestone assigned to the inferred issue.
• Edit the milestone assigned to the inferred issue.

But we also need to(When inferring is possible)

• Create a new issue
• List all open milestone
• Create a new milestone

The fix #224 for #198 which gives an option to disable inferring isn't a good one. Inferring is a very good feature, we don't want to disable it. I suggest that either there should be some flag in the commands telling when to use inferring and when not to. Or the interface can be changed to make it more intuitive. For eg

• ghi open will only open issue
• ghi reopen issue_no will re-open issue. It will either take issue_no as argument or infer it.
• ghi milestone -l will always list milestones.
• ghi milestone --show milestone_no will show milestone. It will either take milestone_no as argument or extract it from the inferred issue.
• Similarly milestone creation and editing.

If anyone knows another command in which the inferred issue causes problem please comment below.

[caifara]

@shubhamshuklaer glad this thing is moving!

Maybe a bit of a side note here, but as you're mentioning the interface, I would argue that the milestone part feels like an afterthought as you need to do everything with flags (whereas this isn't the case with issues). I would be more in favor of this kind of interface:

• ghi milestone list
• ghi milestone show x
• ghi milestone new -m "name"
• maybe ghi new can be shorthand of ghi issue new

I definitely think/agree that an intuitive interface goes a long way! So maybe these issues can be solved in an "interface-driven" way. It will surely force some kind of solution to the inferred issue problem (I agree that it can and should be inferred if the command needs it).

[shubhamshuklaer]

@caifara you are right. The interface you mentioned is better. There is also a TODO written in the milestone.rb file about improving the milestone interface.

[gregglind]

+1 on this. I am often in issue labeled (121-fix-the-thing) branches and want to open a new issue.