Feature #5386
openBranch/Tags in Changeset Description
0%
Description
Our development team uses branches pretty thoroughly and it would be useful if the changeset description could include the branch name in the description. Preferably just appended onto the end.
Files
Related issues
Updated by Eric Thomas over 14 years ago
- File Screenshot.png Screenshot.png added
Here is a really rough sketch of what I mean (sorry I'm horrible at graphics programs).
Updated by Colin Mollenhour about 13 years ago
- File 2011-10-12_1834.png 2011-10-12_1834.png added
Yes, there is no easy way to find which branch someone committed their code to using Redmine. I propose the names of the branches containing a commit also go in the Associated Revisions section:
There are other places in Redmine this list should also be added but this is the most important IMO.
E.g. as an QA/integrator I look at a ticket and see an associated revision, but to do a "git checkout" I have to know what branch they pushed to.
Updated by Colin Mollenhour about 13 years ago
- File 2011-10-13_0039.png 2011-10-13_0039.png added
- File 5386-branches-in-associated-revisions.diff 5386-branches-in-associated-revisions.diff added
I implemented the recording of branches per revision using "git branch --contains" and listing the branches next to each associated revision as links to the branch browser. Patch and screenshot attached.
Updated by Toshi MARUYAMA about 13 years ago
As I described at https://www.chiliproject.org/issues/268#note-2 ,
Git branch is not stable. Git branch is the pointer to the specific revision. So, Git branch cannot be stored in database.
Mercurial named branch is stable.
Please see http://mercurial.selenic.com/wiki/GitConcepts#Branch_model .
Updated by Colin Mollenhour about 13 years ago
I understand that git branches are not "stable" but I don't understand why that would preclude this feature. If a new branch is added, all of the commits will be updated with the new list of branches. If a branch is deleted, the branch will be hidden at render time (Redmine doesn't have a branch-deleted hook of any sort). It might not be perfect, but it does work and it is extremely useful. Again, all this is doing is basically caching the result of "git branch --contains [scmid]". If this is an officially supported git command then what is wrong with supporting it in Redmine?
Updated by Jan Ivar Beddari almost 13 years ago
I think Colins arguments are valid.
This is just caching the output of a valid git command, nothing more. It does not matter if git branches are stable or not. As long as people know git they will understand this feature.
Hope to see this merged. Without this patch my team still need to run gitweb just to be able to correlate commits to branches.
Updated by Paul Stevens almost 13 years ago
We are also in a position were we use branches a lot. Many of us also look at the Activity view (via RSS) and it's a huge nuisance that we do not have any way to determine whether a commit belongs to the master (which must be always working) or some hot-fix development branch. I also can't count the number of times one of my developers committed a bugfix and I had no way to see in Redmine which branch this was in.
Right now, Redmine 1.2.x and 1.3.0 is completely unusable in regards to showing git commits in the Activity view and the associated revisions.
Updated by Colin Mollenhour almost 13 years ago
Just an update on this issue. I've been using it for a while and am still tweaking the patch but it is extremely helpful so far. Only issue is when you have lots of branches that were branched way back the list gets cluttered. Working on a solution.. (hiding branches based on merge status)
Paul, I use a gitolite hook I wrote to require commits to have issue references to avoid that situation:
https://gist.github.com/1248871#file_update_require_issue.sh
Updated by Paul Stevens almost 13 years ago
So I added your patch to our 1.3.0 installation (had to rename one file and added a patch to app/models/changeset.rb to show the branches in the activity view) and so far it is a huge success. Everybody loves it.
Two caveats though: 1) As you noted esp. older commits have a huge list of branch names which makes it impractical), 2) when creating a new branch and pushing it to the server, it takes a LONG time to rescan.
Updated by Anonymous almost 13 years ago
Really would like to branch name in associated revisions on ticket page for SVN! Maybe somebody did that already and want to share a patch?:)
http://www.redmine.org/attachments/6661/2011-10-13_0039.png
+1
Updated by Colin Mollenhour over 12 years ago
Kamil, this would be quite difficult to do if not impossible in SVN since SVN branches are nothing like git branches.
Updated by Anonymous over 12 years ago
Sadly thats true. Probably most people use standard layout i.e.:
/branches
/tags
/trunk
But you can't assume this as standard. Maybe I will make a patch which will assume everything starting with "branches" is a branch or something like that.
Updated by artack artou over 12 years ago
Thank you for this patch !
But it doesn't work with redmine 1.3.3
Is there a way to update this patch for this version ?
Thanks
Updated by Anonymous about 12 years ago
I just want to add my support behind this feature. I feel that the Low priority is not correct it should be much higher.
For example we use Feature branches and release branches in git.- Feature branches are named with the issue number + description.
- When we commit we mention the issue number
But there are exception, and then it becomes a hassle to figure out where it was committed.
- So it is nice we have cross reference in Redmine in which branch it was committed
- When a feature has many subtasks it is possible that this subtask is then commited in is in its parent branch
- When a related issue is discovered it is possible that we have to commit to the same branch of the related because it can depend on some code that is in that branch.
I can use indeed my git UI tool to start searching for the issue and the commit tag and see where it was, but is is just nice to see it right away in Redmine to avoid that step.
Even nicer in case I can click on the branch name in the commit message, that it would open the branch in the repository.
Updated by Joel SCHAAL over 11 years ago
colin yu Mollenhour +1
Marc Horowitz Van Olmen +1
This is really something we would like to see.
What is blocking the inclusion of this patch to a forthcoming release ?
Paul Lacey Stevens How long is 'LONG' (for the rescan time) ?
Updated by Colin Mollenhour over 11 years ago
Joel SCHAAL wrote:
Paul Lacey Stevens How long is 'LONG' (for the rescan time) ?
I noticed the times getting longer as the number of tickets grew as well, so I just changed my git hook to do the update in the background. If I make a lot of pushes in a very short period of time (e.g. 5 in 20 seconds) it will lock up the server but some sort of locking mechanism either in the git hook or in Redmine would resolve this.
Updated by Toshi MARUYAMA over 11 years ago
Joel SCHAAL wrote:
What is blocking the inclusion of this patch to a forthcoming release ?
See my note-4 comment.
In following case, git branch becomes incorrect.- delete branch
- git branch -D branch
- git push somewhere :branch
- force push
- git push -f somewhere branch
Updated by Toshi MARUYAMA over 11 years ago
Colin Mollenhour wrote:
If a branch is deleted, the branch will be hidden at render time
5386-branches-in-associated-revisions.diff calls "git branch --contains hash" per associated revisions.
In the issue which has many associated revisions (e.g. #61),
It becomes terrible performance regression.
Updated by Colin Mollenhour over 11 years ago
I don't doubt these issues with correctness/performance could be solved with some clever redesign, but I am not a ruby programmer and the solution I came up with works beautifully for me. I personally don't even notice the performance hit (updates in background, no noticeable delay on page loads with many revisions) so am not compelled to improve it. I'd love to see this feature in the core, just letting everyone know that I won't be submitting any further patches on this issue in case that's what the hope was.
Updated by Toshi MARUYAMA over 11 years ago
- git branch
- git ls-tree
- git log
So, robot excludes repository page.
source:tags/2.2.3/app/views/welcome/robots.html.erb#L3
Current issue page does not call git command.
If issue page will call git command, robot should exclude issue page, too.
Updated by Evzen Sindelar over 11 years ago
- File 5386-branches-in-associated-revisions-2.3-stable.diff 5386-branches-in-associated-revisions-2.3-stable.diff added
Thank you, very helpfull for me, I fixed some small changes to patch for redmine-2.3.
Updated by Evzen Sindelar over 11 years ago
- File 5386-tags-in-associated-revisions-2.3-stable.diff 5386-tags-in-associated-revisions-2.3-stable.diff added
The same for tag names.
Updated by Tobias Fischer over 11 years ago
hey Evzen,
thanks for providing these patches. Unfortunately they're not working with latest 2.3.1 :-(
Updated by Anonymous over 11 years ago
Any chance of getting this resolved in the latest releases?
Updated by Mischa The Evil about 11 years ago
- Related to Patch #7829: Show branches changsets belongs to on issue page added
Updated by Mischa The Evil about 11 years ago
- Has duplicate Feature #10831: Branch field and clickable link added
Updated by Mischa The Evil about 11 years ago
- Has duplicate deleted (Feature #10831: Branch field and clickable link)
Updated by Mischa The Evil about 11 years ago
- Related to Feature #10831: Branch field and clickable link added
Updated by Anthony Mallet over 10 years ago
- File tags.patch tags.patch added
Here is a small patch (against 2.4.3) implementing more or less this for git.
The patch adds the branch and tags names to the revision id, in a way similar to what git log --format=%h%d would do. At the same time, it makes the git branch and tags retrieval more efficient, since my patch reimplements GitAdapter::branches and GitAdapter::tags with a single method (and a single fork).
I wish I could easily add <span> tags around the branch/tag names so that they can be styled, but atm I could not manage to find an easy solution.
What do you think?
Updated by Josh Davidson almost 10 years ago
Would love to see this implemented for Mercurial. Scanning through the revision list is currently confusing when multiple revisions on different branches reference the same issue #.
Updated by Marco Descher over 9 years ago
Love to have this +1; Anthony I would have liked to apply your patch to 2.3.4, but unfortunately it fails and I don't have a clue about ruby ... could you possible provide a patch for 2.3.4.stable ??? THANKS!
Updated by Anthony Mallet over 9 years ago
- File tags.patch-2.6.1 tags.patch-2.6.1 added
Marco, here is my patch updated against 2.6.1
It may not apply directly to 2.3.4 (you really mean 2.3.4?), but you may be able to apply it 'manually' by checking which files are changed and what changes are brought in, then adapting the redmine code to what is provided in the patch (this does not strictly require ruby knowledge, just some visual pattern matching :)
Updated by Marco Descher over 9 years ago
Anthony, thanks for them ... unfortunately I fail to port them correctly leaving me with a non-working isntallation. Yes, we use 2.3.4 - productive system, no upgrade requirement - just this feature missing!
Updated by Marco Descher over 9 years ago
Anthony Mallet wrote:
Here is a small patch (against 2.4.3) implementing more or less this for git.
The patch adds the branch and tags names to the revision id, in a way similar to what git log --format=%h%d would do. At the same time, it makes the git branch and tags retrieval more efficient, since my patch reimplements GitAdapter::branches and GitAdapter::tags with a single method (and a single fork).
I wish I could easily add <span> tags around the branch/tag names so that they can be styled, but atm I could not manage to find an easy solution.
What do you think?
Anthony, I managed to apply your patch! But it seems like that the respective information is always only included for the head commits of a branch or tag respectively. Most of the commits are not annotated with the releases they are located in - this seems inherent to the git show-ref command.
Updated by Marco Descher over 9 years ago
whoops my mistake ... obviously the tags patch ;)
Updated by T Leish over 9 years ago
I ran across this same problem in our team. Although, I realized that history is maintained based on when the history has been imported. If a commit has been merged into another branch later, then this branch relation information would be missed (we often ask ourselves, was this change merged into master yet?).
In git, you can simply run
git branch --contains {hash}
As such, I created a Redmine plugin which patches the revision detail page and allows you to see the branch information for a particular checkin. Each time this page is accessed, it will run the command git branch --contains {hash}, which will make sure it's up to date, which is pretty fast even for a large repo.
For details on the plugin, see: https://www.redmine.org/plugins/redmine_revision_branches
Updated by Niklaus Giger about 4 years ago
I ported the plugin redmine_revision_branches to the master branch.
Works fine for us.
We would like to have it in the next redmine release.
I am willing to add tests, changes requested by maintainers, etc to make this happen.
Updated by Niklaus Giger almost 4 years ago
Here a reworked patch with Minimized changes to settings.yml
Updated by Niklaus Giger almost 2 years ago
- File 0001-5386-Branch-Tags-in-Changeset-Description-4.2.patch 0001-5386-Branch-Tags-in-Changeset-Description-4.2.patch added
Attached the patch for redmine 4.2 as used in our productive environment
Updated by Marco Descher 3 months ago
(bump) This issue is open for 14 years now, and obviously relevant - is there any way we could sponsor this
to finally find its way into the official redmine distribution?
Updated by Marco Descher 3 months ago
Info - patch from https://www.redmine.org/issues/5386#note-39 applies to Redmine 5.1
Updated by Jan Catrysse 3 months ago
We are very pleased with the patch and using it daily in production on Redmine 5.0.