zakaria.boutami

That's correct. Git intentionally does not allow the server to make changes to clones; it's a security consideration, to ensure a malevolent server cannot "attack" clients through their configuration.

Best regards,
Bryan Turner
Atlassian Bitbucket

git config bitbucket.project return project key only when run from Bitbucket Server. If run from local machine where the repository is cloned doesn't work, right?

Starting from 4.12, all repositories now track their Project.getKey(), Repository.getSlug() and Repository.getHierarchyId() in their git config. These properties are available as bitbucket.project, bitbucket.repository and bitbucket.hierarchy. If a repository is moved to another project, or renamed, these properties are automatically updated to track those changes.

This change obsoletes the bitbucket-reponame-plugin. Upgrading to Bitbucket Server 4.12 will automatically uninstall the bitbucket-reponame-plugin if it is installed and will not allow it to be reinstalled. This is necessary to ensure there aren't conflicts between how the properties are managed by Bitbucket Server and how they were managed by the plugin.

Best regards,
Bryan Turner
Atlassian Bitbucket

Details: These bitbucket.project, bitbucket.repository and bitbucket.hierarchy properties are not stored in config directly. Instead, they are stored in repository-config, which exists on disk alongside config and is included into it using an include.path directive. This allows repository-config to be rewritten without requiring changes to config, which avoids various locking issues. Running, for example, git config bitbucket.project in a repository will return the project key even though the property does not exist directly in config. These properties need no special actions to access.

mironov.dev

I uploaded 2.0.2, the version we're using internally, but noticed it was suffering from a regression in early Bitbucket Server 4.0.x releases. So I fixed that and released 2.0.3 and uploaded that instead. Note that the 2.x version of the plugin sets bitbucket.project and bitbucket.repository, not stash.project and stash.repository. If this is something you're depending on in a script, you'll want to update it.

Longer term, I've done a bit more investigation and I believe I've come up with a way to set these properties that is efficient enough to be shipped in the core product after all. As with the current bitbucket-reponame-plugin, my changes set bitbucket.project and bitbucket.repository. They're not set in the config file, but they will be available for git config (e.g., git config --get bitbucket.project will return the value; no extra hoops to jump through).

I've got all of those changes working locally. We're a bit late in the 4.10 release cycle, so I'm planning for that change will ship in 4.11 instead. (It still has reviews to go through, and some internal torture testing, so it may not ship. 4.11 is just my current plan. I'll close this issue and set a fix version once the release it will be included in is finalized.) When that change ships, if you've got the bitbucket-reponame-plugin installed (or stash-reponame-plugin, the system will automatically uninstall it for you as part of the upgrade. So you might use the plugin as a temporary solution, for now, and the system will assume those responsibilities later, on upgrade.

Best regards,
Bryan Turner
Atlassian Bitbucket

For that case, I'm inclined to leave it in the stash-reponame-plugin, which can already be installed on any Bitbucket Server (or Stash, by using a 1.x version) instance

Can you provide new version of this plugin? On the download page https://bitbucket.org/atlassian/stash-reponame-plugin/downloads provided version 1.0.1 is not working with Atlassian Bitbucket v4.8.6. I tried to build latest version from source, but after several hours of fighting with maven i surrendered =(

Storing the project (key) and repository (slug) in config opens up issues with keeping the data accurate. Project keys can be changed, and repositories can be renamed or moved to different projects. A single project key change could trigger updating many repositories, each requiring its own fork of a git config process.

Instead, I think a better approach is to provide this in an environment variable whenever a git command is forked. That means code like this becomes unnecessary:

#!/bin/sh
PROJECT=$(git config --get stash.project)
REPO=$(git config --get stash.repository)

Instead, you'd be able to simply refer to $STASH_PROJECT and $STASH_REPOSITORY to get the values. (That's more efficient as a bonus, since your script doesn't need to fork off two git config processes to extract the config values.) Since the environment variables would be exported on each process, they'd automatically pick up any key or slug changes, making them more resilient to changes without an additional effort.

STASH versus BITBUCKET for naming the new variables is a sensitive decision. Changing existing $STASH_* environment variables could break things in subtle ways, which is why we've left them as-is, and splitting our naming between STASH and BITBUCKET makes using the "right" variable harder. I'm inclined to use STASH for the new variables for consistency.

There is, of course, the "repository at rest" consideration, where an administrator is looking at a repository on disk and they want to know which Repository it is in the system. An entry in the config file could help there, but only if it's reliably up-to-date with any changes that have been made since the repository was created. For that case, I'm inclined to leave it in the stash-reponame-plugin, which can already be installed on any Bitbucket Server (or Stash, by using a 1.x version) instance to add bitbucket.project and bitbucket.repository config entries (stash.project and stash.repository for 1.x versions) and keep them up-to-date over time.

Best regards,
Bryan Turner
Atlassian Bitbucket

Benjamin,

It's not possible for multiple Repository objects in Stash to point to a given repository directory, so setting the ID doesn't add anything: The directory name is the repository ID.

Best regards,
Bryan Turner
Atlassian Stash

Including the repository id (s?) would also be a nice. Where there is a problem with a repository on disk it would be helpful to be able to quickly correlate it with the specific repos that point to it.

I like Brian Engert's suggestion of using a section in .git/config to store these variables, but would suggest using a different config-key than [stash] only because of git's built-in command git-stash. This could result in a future conflict were git to add support for config vars under that name.

I would suggest namespacing it with a vendor prefix using [atlassian-stash]

[atlassian-stash]
    hierarchyid = 9b3731760974b2b323e7
    repository= test-repo
    project= PROJECT

+1

Ok, we'll go with the config file and use the structure that bengert@soliantconsulting.com suggests.

As a result, mironov.dev's hook code will be:

#!/bin/sh
PROJECT=$(git config --get stash.project)
REPO=$(git config --get stash.repository)

I actually like that idea as well. I think the description file solution is ok for the causal poking around on the filesystem but storing it in the config (under the stash section) is as clear and has the added benefit of being available to existing tools.

I like the idea of putting it in git config as it's a standard configuration file and there's already parsing tools. I wonder if it makes sense to move project and repository into stash so it's less generic.

something like

[stash]
    hierarchyid = 9b3731760974b2b323e7
    repository= test-repo
    project= PROJECT

Hi, Brent!

In our hooks now we are using code like this:

#!/bin/sh
PROJECT=$(git config --get project.name)
REPO=$(git config --get repository.name)

How we can get this vars from .git/description?

Hi mironov.dev,

We're working on something like this now. Our proposed solution populates the .git/description file with the text "projectKey/repositorySlug". Are you particularly interested in querying with git or will this work?

Thanks,
– Brent