issues service has conceptual issues related to pulls from other repos (BB-2403)

Thomas Waldmann avatarThomas Waldmann created an issue

imagine you have:

  • a master repo with master issue tracker for the sw project
  • a forked repo with own issue tracker for the subproject that some developer is working on

the developer works in his repo as usual and uses "Fixes #42." in his commit comments to close #42 in HIS issue tracker.

at some time later, you decide that you want to pull the stuff from the developer's repo into the master repo.

the master repo's issue service will then see "Fixes #42" in the comment of the pulled changeset and close the MAIN issue #42 also (which is usually something completely different).

This is very annoying, because you manually have to fix all those issues afterwards.

The only work around I can think of currently is to disable the issues service before pushing changesets you pulled from another repo using its own issue tracking with issues extension.

Comments (7)

  1. Thomas Waldmann

    after some more thinking:

    just using a simple 1..n number is just not enough. if one would insist on that, one would also always have to tell what repo is meant, so it would be "Fixes user/repo/bugno".

    but as that isn't short anyway, one could also just use some UUID for bugs (e.g. hash computed from bug report, like it is also done for changesets). That UUID would be unique with very high probability, so if you say "Fixes #425a3ebf", that likely will fix only the bug you really mean.

  2. Martin Geisler

    Maybe a good answer is that a changeset can only close an issue in one repository, namely the first repository it is pushed to. So after closing the issue in the fork, it wont try to close any more issues when pulled into the main repository.

  3. Dylan Etkin

    Hi Guys,

    Thanks for bringing this up. It is certainly a bit complicated, I am not entirely sure what the best solution is.

    I have put the issue into our backlog but I don't think we will be looking at it within the next few months.

    I think it would be good to see where the conversation on this issue goes.

    Cheers,

    Dylan

  4. Jon Langevin

    When a Mercurial repo is configured with nested repos, and the hg client cascades commits from the root repository, to each nested repo (with outstanding changes), users may experience unexpected results, as issuetracker won't know that the mercurial client cascaded the same commit message to each disparate repository.

    A change in workflow is all that is required to avoid such possible issues, at least until "Fixes #1" can become more explicit.

    Example nested repo structure: master master/nested1 master/nested1/nested2

    The master and both nested have changes. I committed in the root of the master, using cli hg, referencing fixes to 2 tickets in the master repo. Mercurial cascaded the commit message into each nested repo's own commits.

    Perhaps the solution to our woes, would be a client-side extension or pre-commit hook that could modify ticket ID references to be repo specific? Then a commit message could still be specified as "Fixes #1", but would then be automatically updated to "Fixes #1:2346-8472-1374:" or "Fixes #1/user/repo-name" (as suggested by other commenters)

  5. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.