Redmine

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 .

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?

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.

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.

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

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.

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

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

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.

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

I just want to add my support behind this feature. I feel that the Low priority is not correct it should be much higher.

• 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.

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

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.

Joel SCHAAL wrote:

What is blocking the inclusion of this patch to a forthcoming release ?

See my note-4 comment.

• delete branch
  • git branch -D branch
  • git push somewhere :branch
• force push
  • git push -f somewhere branch

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.

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.

• git branch
  • source:tags/2.2.3/lib/redmine/scm/adapters/git_adapter.rb#L81
• git ls-tree
  • source:tags/2.2.3/lib/redmine/scm/adapters/git_adapter.rb#L134
• git log
  • source:tags/2.2.3/lib/redmine/scm/adapters/git_adapter.rb#L198

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.

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

Any chance of getting this resolved in the latest releases?

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 #.

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!

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!

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.

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

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