I changed a badge in one of my company's repos but I messed up the url. Now I can't find the old url. Is there a way I can find the badge's old url?
This is easy in github via git show HEAD~:README.md since badge state and history is stored in the git repo, but I don't see where gitlab stores badge state.
No, there is no history or revert option for badge URLs. The only state is the current state. As soon as you change the badge URL, the old state is lost forever, unless you are self-hosting GitLab and perhaps you have access to logs or database backups...
You will just have to figure out the correct URL somehow. Maybe ask a colleague if they know what the previous URL was.
In the future, it may be good to know that you can preview badges to make sure they are correct.
Related
I've a problem with a Gitlab self-hosted community edition. Recently I've rewrite history on a git repository, and that changed a lot of SHA-1 of commits. I've tried to place the "replace" references, but Gitlab still in Merge Request uses the old commit hashs. After some trials I've tried to export the project and check inside the exported files, and I noticed that Gitlab uses its database to hold the commit hash codes. Is there a safe way to change those commits? I'm the system administrator, so I have full access to gitlab instance and also root access to the machine hosting it.
Thank you all.
In short, no, there's not a way to change this for MRs.
The most you can do is remove the content of the commits from GitLab (the SHA and links will still appear in the MR UI, but they will result in a 404 error after they are removed). This will also remove the ability to see the diffs of these MRs.
To do this, follow the documentation described here for cleaning up repos after history rewrite. After using git filter-repo and uploading the commit map to GitLab, the old commits will be remapped to the new ones (removing all the old references) and the rewritten history will be removed forever.
I've had a success exporting the project, modifying the json file inside the tar gz changing the old commit/new commit, and importing the project.
Yes, now the events are done by the importer (and no more the original committer/pusher), but this is accetable, as the story is now navigable in gitlab with the correct commit as company rules.
We recently migrated from using Subversion and Trac to Git and GitLab. We successfully migrated all of our old data.
I'm still trying to learn GitLab and generally like it better than Trac, but one thing I don't like as much is that when you reference a GitLab Issue in the git commit, it adds a reference and link to that commit under the issue, but you have to browse to the commit itself to see the associated Git commit message.
In Trac, we had it configured such that the Subversion commit messages were all displayed in the Trac ticket with the commit link, so it was easier to view all the relevant information for that ticket in one place.
Is there a way to configure GitLab to display the Git commit message with the Git commit link that shows up under Issues? The message does show up in the commit list, but not on a referenced Issue.
I thought about trying to use a server hook to generate a note with the Git commit message when a commit is made, but just wondering if there is an easier/better way to accomplish this?
There is no built-in way to show the commit message of a crosslinked commit in the issue log. After all, commits are handled the same way as any other mentions: in the issue's history/mention log.
While the example in GitLab's documentation unfortunately misses the opportunity to show an example of a mention in the commit, here's an issue from GitLab itself with a mention. This commit also shows how mentions often get used within commits—with keywords:
Merge branch '65375-broken-master-gitlab-svg-path-test-failing' into 'master'
Update failing jest snapshot
Closes #13186
See merge request gitlab-org/gitlab-ee!14933
These kind of commits close the specific issue and don't require any further user action. Adding that kind of noise to the discussion/comment section of an issue is, in my opinion, only cluttering the discussion between actual humans*. However, the commit still shows up in the log and is clickable and hoverable.
To get back to your question:
Is there a way to configure GitLab to display the Git commit message with the Git commit link that shows up under Issues?
If you hover over the linked commit, then you'll get the commit's subject. There's nothing more that can be achieved within GitLab itself.
I thought about trying to use a server hook to generate a note with the Git commit message when a commit is made, but just wondering if there is an easier/better way to accomplish this?
If you follow the usual commit/merge message based issue closing and use [Closes?|Fix(es)?] #issue in your commit message, you may end up with more noise in the comments than you would like too.
* well, except for some bots
I have accidentally deleted a Wiki-page from our repository in Azure DevOps.
(How) can I recover it?
That is not an option for us, since we will loose many changes that
were made after the last version no. up until the date I accidentally
deleted the wiki page.
You can choose Clone wiki to download the wiki repo to local machine.
Then use git commands(git revert or what) locally to get the deleted page, once you find the deleted page, publish it and add it back to Wiki page as a new commit.
I was just able to do this without too much fanfare. The resource that was helpful was this VS community topic. There is an answer that provides a solution that doesn't require you to clone the repo.
The key insight is that you can navigate to the Azure DevOps repo UI for the Git repo that's backing the wiki. The solution author says that the shape of the URL is something like https://dev.azure.com/<organization-name>/<project-name>/_git/<wiki-name>.wiki. This didn't quite work for me because we have a different URL scheme in our organization, but I was able to figure it out after a little trial and error. I later saw that you can get the URL by using the Clone Repo UI in the wiki - it gives you the URL, so you can just copy it and navigate to it.
Anyway, the steps were:
Figure out the URL of the git repo that backs the wiki
Navigate to the revision history for the entire wiki
the current UI shows you the Contents tab by default - switch to History
Scroll until you find the commits that deleted the pages you want to restore
it's one of those list views that populate themselves as you scroll, so you won't be able to use the browser page search efficiently, unfortunately
Revert the commits
In my case, this required clicking on them and creating pull requests to revert, but I was able to merge them myself without involving code reviewers. YMMV
All in all, not a wholly terrible experience, but completely undiscoverable.
Assuming you're managing a provisioned wiki (vs using published code as a wiki):
Look in the top-right corner for the vertical 3-dot menu, where there's an option to view revisions:
Choose the revision you want to revert to (e.g. the one prior to deleting the needed wiki page), from the list (click on its version hash):
From the revision details, select "Revert":
At this point, your wiki should be at its prior state, and your wiki page should once again be available.
Note: If you're using published code as a wiki, you would recover/revert your changes as you would with any other code commit.
More details may be found here.
I couldn't find a way to do this through the Azure DevOps web interface but you can restore the page by reverting the commit that deleted it if you clone the wiki locally.
Clone the wiki to your computer - find the clone wiki option in the menu at the top of the left bar which shows the wiki contents, copy the URL and use to clone locally using your usual git client.
Find the commit that deleted the page, the commit message will start with "Deleted page" then the name of the page you deleted.
Restore the page and commit the change. There are various ways to do this - I reverted the commit, you could checkout the commit and copy the page out to make a new commit. You may get a merge conflict on '.order', I'm not sure what the best thing to do is but I kept the current version and haven't had any problems.
Push the changes to Azure DevOps, refresh and you'll see the page has been restored.
This works even for Project Wikis. I wonder if Azure DevOps has added the functionality that enabled this since some of the other answers have been written.
I mistakenly removed default gitlab page (type of user.gitlab.io/project)
How can I restore this?
Thanks you in advance.
Is it possible at all?
Brief Version:
Delete repo, repush and wait.
Detailed Version:
Keep the repo in your local,
Delete repo on gitlab (which will cause losing MR history, but that's not critical for me at least),
Create new Repo (no matter it's same name or not)
Push the code
Then I deleted .gitlab-ci.yml as a commit and added it back as another commit, so that you will see "Congratulations! Your pages are served under: https://username.gitlab.io/project-name" in Gitlab Page Setting, (I am not sure this step is required or not, if I am wrong please correct me, it just automatically worked)
Then you might still get "404 The page you're looking for could not be found." from that link, what you need to do is just WAIT. For me it's about 3 hours (while I am frustrated to looking for other solution, it just worked at some point)
Some explain:
I did step 5 because: it seems gitlab is always automatically enable the default gitlab page once it finds an .gitlab-ci.yml file in your repo.
Our team members are not all familiar with git, some members may take a mistake to force push the local branch on to server especially if they are using Windows GUI tools.
I'm wondering if there is any way to control the force push permission for different roles. I googled, but found no answer. I'm using latest Gitlab.
Not yet (should be in GitLab 6.8+): there is a pull request in progress: "pull 6190", which stemmed from this suggestion.
GitLab already has protected branches that prevent push for all except masters. However, there's still the problem of accidental history rewrites and force pushes by masters that can wipe out the whole repository (has happened in real life).
Therefore it is useful to additionally have protection against branch deletion and history rewriting.
The code changes are visible here and are based on a pull request on gitlab-shell, with a definition in lib/gitlab_update.rb:
def forced_push?
missed_refs = IO.popen(%W(git rev-list #{#newrev}..#{#oldrev} --)).read
missed_refs.split("\n").size > 0
end