Unable to sync all existing branches

[Former user]

It's impossible to add all existing branches from the repo at once. We creates new branches every week and our JIRA admin can't control it and promptly update Jigit's settings.

Add an option to add all branches from a repo at once, please. It would be very useful!

[Николай Рождественский]

And our developers needs option "All branches" (include existing and new).

[Dmitriy Ibatulin]

Actual for us too

[Sergey O.]

Diff file of a hack I created based off dmitry_apanasevich-jira-jigit-plugin-94fda6df649f.zip download.

The idea is to scan for branches that have had recent commits and process them. Only works with gitlab.

Maybe it'll be helpful for implementing this issue.

[Dmitrii Apanasevich]

Hi!

Thanks for your help, but I've nearly implemented this feature. Wait several days, pls.

If you are interested in implementation of interaction with API's you can take a look at the first commit to branch index-all-branches

[Dmitrii Apanasevich]

Add "Index all branches" setting

Allows users to index commits from all branchesof repo, without specifing them.

Resolves: #9

→ <<cset ba9f7775a83a>>

[Dmitrii Apanasevich]

Good news everyone! New version is already available to install.

[Sergey O.]

Hi, I took a very quick look at your commit and there's one concern I have. I might be misreading the code (it was a very quick look :)), but it does look like you're adding ALL branches to getBranchForcePushHandlers() which are then subsequently processed.

In our case we have like zillion of branches (for historic reasons) but only a few of them are actually active. In my 'hack' I try to only add branches that have recent commits to getBranchForcePushHandlers()

So the concern is -- would a lot of 'inactive' branches negatively affect the performance of the scanner? Also -- does only adding branches with recent commits to getBranchForcePushHandlers() break something down the line?

[Dmitrii Apanasevich]

Your approach doesn't break something , but it can't be applicate to GitHub API. Also, newly installed add-on would lost commits unmerged to the main branch if they were created more then a week ago.

In your case indexing will take more time, because add-on will waste time on lots of stale branches. You can use this GitLab feature if it is possible in your case to get rid of stale branches https://docs.gitlab.com/ce/api/branches.html#delete-merged-branches

[Sergey O.]

Thanks for the clarification! Perhaps you would consider adding option to only scan 'recent' branches for the backends that support that (e.g. GitLab)?

[Dmitrii Apanasevich]

Well, I've started to think about "recent branches" feature after your comment. Thanks for advice.

Have you tried to switch your repository to the new way of branches indexing? Does it work more slowly than earlier? I would be grateful for feedback :)

[Sergey O.]

No, I did not switch to your implementation. It's a production system and there really are a lot of those old branches, I don't want to risk it, sorry. That's why I started by reviewing your code and asking the question :)

[Dmitrii Apanasevich]

Ok, I see.

I just want to mention that there is a method to delete all stale branches which have already merged. You can use this command if it's possible in your company's workflow.

[Dmitrii Apanasevich]

Perhaps you would consider adding option to only scan 'recent' branches for the backends that support that (e.g. GitLab)?

Could you please also create a new issue for this?

[Sergey O.]

Sure, created issue #11 for that.

Regarding deletion of old branches -- I am, unfortunately, have only a surface knowledge of GIT. The branches themselves are mostly the result of migration from Mercurial where we used them to create releases (because apparently in Mercurial you cannot tag something that doesn't 'yet exist' in repository, you have to create a branch, commit changes, and then make a tag for that).

Those branches were then closed -- but they weren't ever merged into default/master -- because they are actually different from the default/master (because you have to adjust Maven pom.xmls to actually do a release).

So I am sure there is some valid solution for those branches but I have no idea what it is :) For now they don't seem to affect much of anything (well, except Jigit integration), so they are not a priority to address. It seems with GIT it is possible to push local changes directly to the tag (without having to have a branch), so I don't expect we'll have that many new branches going forward.

[Dmitrii Apanasevich]

Thanks for details.