"Copy BitBucket link" (or open) uses wrong commit hash

[Simon Str]

Hi,

I generate a link from the context menu for the file in the project view. The link that is generated uses the correct server and path but it uses the most current hash in the branch for the "&at=" parameter. But BitBucket only has entries for the hashes where the file I'm linking to was actually changed.

Say this is the log (simplified, obviously):

hash1 Change file 1
hash2 Change file 2

Creating a link to file1 will use hash2 but BitBucket will not recognize that revision for that file. When I create the link from the "Git history" dialog then it uses the correct revision (hash1, in my example).

Sorry if I use the wrong wording, I've only recently switched from svn to git.

I enabled debug logging but am a bit wary attaching the file as it might contain sensitive information. I checked it and only found entries for the plugin which say

Remote URL path '/scm/xyz' matches Bitbucket Server repository path pattern 

Thanks.

[Patrick Savelberg]

I think I'm experiencing the exact same issue here. If I right click any opened file in the editor and select Open in Bitbucket or Copy Bitbucket link it generates a hash in the link that Bitbucket reports a 404 on. Same thing for the same action on any file or folder I right click in the project explorer.

What does work is if I do the opening/copying on the entries that are shown after "VCS" > "Git" > "Show History"

In this case it seems like it is using the the local (unpushed) commit hash instead of the last remote commit hash.

[Daniil Penkin]

Hello @pragmatick and @PSavelberg,

I'm sorry for a really delayed response. Over the last month I've been working hard on a project that had been incubating for 9 months before that :) So I hardly had time to get to reviewing Bitbucket Linky issues. Hopefully from now on I will be able to carve out more and more time for that.

The thing is that at the moment Linky doesn't check whether a commit has been pushed to remote or not. When you create a link for a file, Linky just adds current local commit hash to construct the URL.

@pragmatick, are both commits hash1 and hash2 in your example pushed to Bitbucket? When you create a link from the editor, Linky will pick current local commit you're at – that will be hash2. I assume that hash2 is not pushed to Bitbucket, so it doesn't recognize it, as you say. In Git world, commit basically links to a state of the whole repository, so if the commit has been pushed, you'll see file state at that commit even if that file wasn't changed in that specific commit.

Making Linky a bit smarter so that it detects whether a commit has been pushed or not (i.e. whether it is safe to generate a link against it) is in my backlog but quite far from its top...

So could you guys please verify that the problem persists when all commits have been pushed? In that case I'll look further.

Thanks in advance!

Cheers, Daniil

[Daniil Penkin]

Resolved in version 3.5: Linky now shows a warning if the link was created for a commit that has not been pushed to the remote repository.

[Simon Str]

This took me waaay to long to respond to but yes, problem was solved. Thanks so much.

[Daniil Penkin]

Thanks for letting me know @pragmatick, I'm glad to hear this.

The warning I added is still not the best what Linky could do in such cases but better than nothing anyway :) Hopefully at some point I will make it smarter (something like find the last pushed commit and if the file has not been modified, generate a link to that version)

[Daniil Penkin]

Removing version: 3.4 (automated comment)