#71 Pushing "Fix" to a branch closes the issue

Open
opened 3 years ago by Tsyesika · 8 comments

Pushing a "Fix # - My message here" to a branch which isn't master shouldn't close the issue. Currently it does close the issue but I think the issue should only be closed when the branch is merged into master.

Pushing a "Fix #<issue number> - My message here" to a branch which isn't master shouldn't close the issue. Currently it does close the issue but I think the issue should only be closed when the branch is merged into master.

That sounds like something that should at least be configurable.

That sounds like something that should at least be configurable.
Jessica Tallon commented 3 years ago
Poster

I'd argue this is not a feature request but a bug report. The convention in a git project is that you typically have a "master" branch which contains the latest code and then branches are often used as feature branches or work in progress. There is obviously exceptions to this, and it being configurable could be cool but, as it works right now doesn't really make sense for most people I don't think.

Currently this prevents people saying "Fix" in their commit messages or it means everyone has to constantly re-open issues.

I'd argue this is not a feature request but a bug report. The convention in a git project is that you typically have a "master" branch which contains the latest code and then branches are often used as feature branches or work in progress. There is obviously exceptions to this, and it being configurable could be cool but, as it works right now doesn't really make sense for most people I don't think. Currently this prevents people saying "Fix" in their commit messages or it means everyone has to constantly re-open issues.
zPlus commented 3 years ago

@Tsyesika can you try this again? Maybe it's fixed in the new version of Gogs

@Tsyesika can you try this again? Maybe it's fixed in the new version of Gogs
Jessica Tallon commented 3 years ago
Poster

@zPlus I've just tested it again on notabug.org, it's still broken. Steps to reproduce are:

  1. Create a new repo
  2. Add a file to said repo
  3. Push the file
  4. Create an issue
  5. Create a branch for said issue
  6. Commit a change with "Fix #issue-number - I fixed the issue"
  7. Push the change.

This will close the issue despite the fix still being on the branch and not merged into master.

EDIT: I note, this is still marked as a "Feature request" I still strongly disagree, this is a bug. A common if not the conventional work-flow in git is to fix a bug or implement a feature which has an issue, to commit that (often using "Fix #59 - User unable to login" or some such) and then commit that to a branch where it's often reviewed by others or at least discussed. Once the feature is deemed to be stable/reviewed/whatever it then gets merged into master which is when you want the auto-closing of "Fix #59 - ..." to close issue #59.

@zPlus I've just tested it again on notabug.org, it's still broken. Steps to reproduce are: 1. Create a new repo 2. Add a file to said repo 3. Push the file 4. Create an issue 5. Create a branch for said issue 6. Commit a change with "Fix #issue-number - I fixed the issue" 7. Push the change. This will close the issue despite the fix still being on the branch and not merged into master. EDIT: I note, this is still marked as a "Feature request" I still strongly disagree, this is a bug. A common if not the conventional work-flow in git is to fix a bug or implement a feature which has an issue, to commit that (often using "Fix #59 - User unable to login" or some such) and then commit that to a branch where it's often reviewed by others or at least discussed. Once the feature is deemed to be stable/reviewed/whatever it then gets merged into master which is when you want the auto-closing of "Fix #59 - ..." to close issue #59.

it could be argued that anything that is merged will make it's way into master eventually - if that is not true then there would be no reason to merge it - once merged then no further discussion is necessary so is better to give users the confidence that the issue was addressed in a timely fashion - that is the standard practice on bug trackers to close the issue as soon as the problem is solved - typically an estimation is given as to which future release version will use the patch which is often several months in the future

it could be argued that anything that is merged will make it's way into master eventually - if that is not true then there would be no reason to merge it - once merged then no further discussion is necessary so is better to give users the confidence that the issue was addressed in a timely fashion - that is the standard practice on bug trackers to close the issue as soon as the problem is solved - typically an estimation is given as to which future release version will use the patch which is often several months in the future
Jessica Tallon commented 2 years ago
Poster

What happens is your branch does not need to be merged. If you push to a branch with the fix followed by an issue number (i.e. "Fix #XX") the issue is automatically closed.

Marking an issue as "Fixed" or "Closed" suggests that it has indeed been resolved. If it's waiting on a feature branch then the user would have to checkout said branch before being able to use the feature. It is also the case that in a workflow where reviews occur prior to a merge happening that in a review issues would be flagged up which could make the "Fix" invalid or needing more work. In that senario the user should not and/or maybe could not even use the "fix" even if they checked out the branch.

The issue is fixed when the fix has landed in master where the user can actually use the fixed version (git clone and build) and it's then on track for the next release. It's also not uncomon for fixes to die on the vine and never get merged due to review problems or other difficulties, this would lead to issues being marked as fixed when the fix is not available, usable nor useful anymore.

What happens is your branch does not need to be merged. If you push to a branch with the fix followed by an issue number (i.e. "Fix #XX") the issue is automatically closed. Marking an issue as "Fixed" or "Closed" suggests that it has indeed been resolved. If it's waiting on a feature branch then the user would have to checkout said branch before being able to use the feature. It is also the case that in a workflow where reviews occur prior to a merge happening that in a review issues would be flagged up which could make the "Fix" invalid or needing more work. In that senario the user should not and/or maybe could not even use the "fix" even if they checked out the branch. The issue is fixed when the fix has landed in master where the user can actually use the fixed version (git clone and build) and it's then on track for the next release. It's also not uncomon for fixes to die on the vine and never get merged due to review problems or other difficulties, this would lead to issues being marked as fixed when the fix is not available, usable nor useful anymore.

indeed you are wise jessica - you have convinced me - especially the part about code review

the behavior you are asking for im pretty sure i how github handles it - gogs mimicks github so closely it surprises me when gogs does anything differently than github - but again i will say the way forward with this non-trivial sort of feature is to request it to gogs first and then ask again here if they refuse to implement it

i will add this tho that notabug is in the process of writing it's own git server and so may be moving away from gogs soon anyways - i think that the very reason this issue is still open after all this time is that the admin is saving some of the better feature requests as ideas for the new system

indeed you are wise jessica - you have convinced me - especially the part about code review the behavior you are asking for im pretty sure i how github handles it - gogs mimicks github so closely it surprises me when gogs does anything differently than github - but again i will say the way forward with this non-trivial sort of feature is to request it to gogs first and then ask again here if they refuse to implement it i will add this tho that notabug is in the process of writing it's own git server and so may be moving away from gogs soon anyways - i think that the very reason this issue is still open after all this time is that the admin is saving some of the better feature requests as ideas for the new system

if notabug is not going to replace gogs then this is yet another stale issue that would be best handled upstream if at all

if notabug is not going to replace gogs then this is yet another stale issue that would be best handled upstream if at all
Sign in to join this conversation.
No Milestone
No assignee
4 Participants
Loading...
Cancel
Save
There is no content yet.