On Sat, Sep 27, 2014 at 11:16 PM, Sergiu Dumitriu <[email protected]> wrote:
> 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. > Ah, right... I did notice something like that. I guess the following workflow does not make sense when using GitHub: 1. Detect and fix a problem 2. Create an issue to track it 3. Create a pull request and push your changes (mentioning the issue) 4. Profit I`m assuming GitHub is intended to jump directly from step 1 to step 3 (which is the issue) in an effort to get to step 4 as soon as possible, stressing the "agile" part of a project's development. So one way of seeing this is that issues are for the project's committers and pull requests are for the project's contributors. Both are used to track changes... and, while committers can be a bit more disciplined to first create an issue and then reference it in the commit message, contributors are not expected to do that and the pull request created is considered enough. Thanks for the clarifications, Eduard > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
