search

driusan / bug

Distributed bug tracking with the filesystem and hg or git
GNU General Public License v3.0
205 stars 7 forks source link

Richer commit messages - new/del/updated issues mentioned by name #3

Closed Komosa closed 8 years ago

Komosa commented 8 years ago
Komosa commented 8 years ago

And question: Description field is mandatory for issue?

codecov-io commented 8 years ago

Current coverage is 19.36%

Merging #3 into master will increase coverage by +4.99% as of 38983fc

@@            master      #3   diff @@
======================================
  Files           23      23       
  Stmts          800     857    +57
  Branches        30      38     +8
  Methods          0       0       
======================================
+ Hit            115     166    +51
- Partial         17      19     +2
- Missed         668     672     +4

Review entire Coverage Diff as of 38983fc

Powered by Codecov. Updated on successful CI builds.

driusan commented 8 years ago

Thanks for the pull request! But can you rebase this onto/resend to the 0.4-dev branch? I'm trying to keep master at the latest stable release so that go get will get a stable version, and not a development branch.

(It would also be a little easier for me to review if it was split up into smaller pull requests that only do 1 thing.)

Komosa commented 8 years ago

Sure, I will see what form two options will be easier.

I splitted work it a way, that each commit does single thing. Do you really need separate PR for each one?

driusan commented 8 years ago

The answer to the question about Description being required is:

Git requires at least one file to be in any directory that's tracked, otherwise it won't checkout the directory. Having an empty "Description" file means that there's no need for some kind of hack like adding a hidden .keepdirectory file just so that git will monitor it.

Other than that, nothing should fail without a Description file. As long as there's something else in the issue directory (a status, a priority, a tag, etc..), it isn't required, but "bug create -n" uses an empty Description in order to avoid having to create some other file just for git.

Komosa commented 8 years ago

I will open new PR in a moment.

driusan commented 8 years ago

It's not necessary to have a separate pull request for each thing (especially since the contributing.md doesn't mention it), but I find it's best with a GitHub workflow (as opposed to, say, a git format-patch based workflow) because:

  1. GitHub makes it easier to see the diff of the pull request of a whole than it does individual commits, making it easier to understand the change and
  2. GitHub only allows you to merge/not merge pull requests as a whole. There's no way to merge individual parts short of dropping to a command line and doing a cherry-pick. That means that, in my experience with other projects, uncontroversial changes sometimes get held up because they're mixed in with other unrelated changes,

So for that reason, I think it's good practice to try and keep pull requests atomic.

Komosa commented 8 years ago

I see the point. There is small problem (sometimes): what if some PRs are based on anothers? I should wait until dependencies are accepted?