On 09/27/2014 03:36 PM, Eduard Moraru wrote: > On Sat, Sep 27, 2014 at 3:32 PM, Sergiu Dumitriu <[email protected]> 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 http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
