Feature #5386

Branch/Tags in Changeset Description

Added by Eric Thomas over 8 years ago. Updated over 3 years ago.

Status:NewStart date:2010-04-27
Priority:LowDue date:
Assignee:-% Done:

0%

Category:SCM
Target version:-
Resolution:

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.

Screenshot.png (28.4 KB) Eric Thomas, 2010-04-27 10:45

2011-10-12_1834.png (23.5 KB) Colin Mollenhour, 2011-10-13 00:40

2011-10-13_0039.png - Screenshot of working version (7.79 KB) Colin Mollenhour, 2011-10-13 06:41

5386-branches-in-associated-revisions.diff Magnifier - Patch to add list of branches to associated revisions (3.88 KB) Colin Mollenhour, 2011-10-13 06:41

5386-branches-in-associated-revisions-2.3-stable.diff Magnifier - Patch to add list of branches to associated revisions for redmine 2.3 (4.2 KB) Evzen Sindelar, 2013-05-23 11:01

5386-tags-in-associated-revisions-2.3-stable.diff Magnifier - Patch to add list of tags to associated revisions for redmine 2.3 (3.23 KB) Evzen Sindelar, 2013-06-05 18:19

tags.patch Magnifier - display git branch/tag names next to revision id (3.65 KB) Anthony Mallet, 2014-02-25 23:26

tags.patch-2.6.1 (3.34 KB) Anthony Mallet, 2015-02-12 15:36


Related issues

Related to Redmine - Feature #3909: Mercurial: show repository graphic history Closed 2009-09-23
Related to Redmine - Feature #4455: Mercurial overhaul Closed 2009-12-21
Related to Redmine - Feature #5501: Git: Mercurial: Adding visual merge/branch history to rep... Closed 2010-05-11
Related to Redmine - Feature #2120: Different views between develop and funcional New 2008-10-31
Related to Redmine - Defect #7984: Confusing revisions links on repository root New 2011-03-24
Related to Redmine - Feature #7246: Handle "named branch" for mercurial Closed 2011-01-07
Related to Redmine - Feature #8876: Activity commits improvement - display branch New 2011-07-21
Related to Redmine - Feature #13715: show SCM identifier (repository) in associated revisions New
Related to Redmine - Patch #7829: Show branches changsets belongs to on issue page New 2011-03-11
Related to Redmine - Feature #10831: Branch field and clickable link New
Duplicated by Redmine - Feature #3878: View tags, branch related to revison Closed 2009-09-16

History

#1 Updated by Eric Thomas over 8 years ago

Here is a really rough sketch of what I mean (sorry I'm horrible at graphics programs).

#2 Updated by Colin Mollenhour about 7 years ago

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.

#3 Updated by Colin Mollenhour about 7 years ago

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.

Screenshot of working version

#4 Updated by Toshi MARUYAMA about 7 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 .

#5 Updated by Colin Mollenhour about 7 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?

#6 Updated by Jan Ivar Beddari almost 7 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.

#7 Updated by Paul Stevens almost 7 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.

#8 Updated by Colin Mollenhour almost 7 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

#9 Updated by Paul Stevens almost 7 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.

#10 Updated by Anonymous over 6 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

#11 Updated by Colin Mollenhour over 6 years ago

Kamil, this would be quite difficult to do if not impossible in SVN since SVN branches are nothing like git branches.

#12 Updated by Anonymous over 6 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.

#13 Updated by artack artou over 6 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

#14 Updated by Marc Van Olmen about 6 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.

#15 Updated by Joel SCHAAL over 5 years ago

@Colin Mollenhour +1
@Marc 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 Stevens How long is 'LONG' (for the rescan time) ?

#16 Updated by Colin Mollenhour over 5 years ago

Joel SCHAAL wrote:

@Paul 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.

#17 Updated by Toshi MARUYAMA over 5 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

#18 Updated by Toshi MARUYAMA over 5 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.

#19 Updated by Colin Mollenhour over 5 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.

#20 Updated by Toshi MARUYAMA over 5 years ago

Repository page calls three git commands.

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.

#21 Updated by Evzen Sindelar over 5 years ago

Thank you, very helpfull for me, I fixed some small changes to patch for redmine-2.3.

#22 Updated by Evzen Sindelar over 5 years ago

The same for tag names.

#23 Updated by Tobias Fischer over 5 years ago

hey Evzen,
thanks for providing these patches. Unfortunately they're not working with latest 2.3.1 :-(

#24 Updated by Jason E over 5 years ago

Any chance of getting this resolved in the latest releases?

#25 Updated by Mischa The Evil about 5 years ago

  • Related to Patch #7829: Show branches changsets belongs to on issue page added

#26 Updated by Mischa The Evil about 5 years ago

#27 Updated by Mischa The Evil about 5 years ago

  • Duplicated by deleted (Feature #10831: Branch field and clickable link)

#28 Updated by Mischa The Evil about 5 years ago

#29 Updated by Anthony Mallet over 4 years ago

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?

#30 Updated by Josh Davidson almost 4 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 #.

#31 Updated by Marco Descher over 3 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!

#32 Updated by Anthony Mallet over 3 years ago

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 :)

#33 Updated by Marco Descher over 3 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!

#34 Updated by Marco Descher over 3 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.

#35 Updated by Marco Descher over 3 years ago

whoops my mistake ... obviously the tags patch ;)

#36 Updated by T Leish over 3 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

Also available in: Atom PDF