27 Sep
2014
27 Sep
'14
10:40 p.m.
On Sat, Sep 27, 2014 at 11:16 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
On 09/27/2014 03:36 PM, Eduard Moraru wrote:
Ah, cool then! I looked at a few github projects for that kind of stuff but
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
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs