On Sat, Sep 27, 2014 at 3:32 PM, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
On 09/26/2014 06:10 PM, Eduard Moraru wrote:
P.S.: I`m fairly sure that writing a quick
greasemonkey userscript for
GitHub to simulate a Jira-like "Commits" tab would be quick and easy to
do,
since issues are already supported to be
referenced from commit messages.
What is missing right now is the other way around, for issues to list all
commits referencing them.
That already happens, see
https://github.com/phenotips/phenotips/issues/1116 for example. Just
that commits are mixed with other activity. This is like Jira's Activity
tab, with all events listed. The requirement is that commits mention
#NNN, so this still requires an issue number. Pull requests numbers are
assigned when the PR is made, so after the commits happened, so in this
case the user has to either guess the PR number (and hope that nobody
else makes a PR first), or amend all the commits to insert the issue
number.
Ah, cool then! I looked at a few github projects for that kind of stuff but
did not find it. I did see issues being referenced in commit messages, but
on the issue's page I did not see anything about those commits. Maybe it's
something you need to explicitly enable for your repo, anyway.
I don`t really see the connection with Pull Requests here, since the
*issue* can be created (if it does not already exist), the commits can be
made with that issue mentioned and then they can be published through a
pull request. Perhaps you were describing a different flow, where someone
commits, makes a pull request and only after they think about creating an
issue to track it, so they have to amend the commits...
Pull requests and issues are almost the same thing on GitHub. Well, at
least one way, pull requests can be issues, but not the other way around:
- a pull request has a number (and the same sequence is used both for
issues and PRs)
- pull requests can have labels, assignee, target milestone
- they appear in the milestone's list of open/closed issues
- they are included in the issue search if you remove the "is:issue"
search filter
So yes, another workflow possible on GitHub is to just make a pull
request and treat it as an issue. Otherwise, there are two places where
the discussion happens: in the pull request, and in the issue. And you
have to make sure only one of them is assigned to a milestone, otherwise
users will see both.
--
Sergiu Dumitriu