I'm trying to follow the tutorial instructions here : https://rtyley.github.io/bfg-repo-cleaner/
I clone a new copy of my github based repo with --mirror
I follow the instructions for running bgf and reflog
My local repository has now removed the big blog. Great.
When I go to push back to github I get
To github.com:interstar/myproject.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'git#github.com:interstar/myproject.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
So I try to git pull from github to ensure sync. (Even though this repository was cloned cleanly from github at the start of the process)
And it pulls down all the blobs I want to get rid of. So my repo is back up to its previous size.
So I run bfg and reflog again. Nice small repo.
Try to push back to github
Same error message.
What am I missing?
OK.
I solved this. It was my own stupid fault, but leaving the question in case anyone else does the same thing.
Although the first time I cloned the repo from github I used --mirror, at some point I tried again and forgot to use the --mirror option.
When I started over with that option it worked as the tutorial suggested.
Related
A coworker got this error after pulling from the repo. I searched for an answer online on how to solve it but couldn't find anything. I figured out a way to solve it so posting it below for anyone else with the same issue.
I asked everyone else working on the repository to check their user cache folder (C:\Users\username\AppData\Local\largefiles on Windows) to see if they had a file with that id ("XXX" from the title).
One of them did, the original author of the file.
I asked him to send it to me, I remote connected to the server that has the central repo. I then copied the file both to the server's cache and into .hg\largefiles
The user could then pull again and push and everything worked.
LF extension seems not compatible with keyword extension.
With these both extensions, at the commit, the LF is NOT put in the configured folder on the PC and then raises this error at push.
If you disable the keyword extension, it's perfectly working.
Unfortunately, I've not found any additional explanations.
If someone could provide a stable solution, it will be great.
It looks like hg pull is happily sparse, but hg push is not; thus you need all largefiles for every revision not already present on the new remote, so that it can populate for history and allow clients to successfully pull at any revision. Which makes sense.
When migrating to a new hg server, I hit this issue. The "within Mercurial" solution was to download all largefiles, for all commits, to my local repo, and then push to the new server repo:
$ hg lfpull --rev 1-tip
$ hg push newbox
(Disclaimer: my Mercurial-fu is weak, I only use it for this one largefile repo)
I'm using TortoiseHg with the hg-git Mercurial plugin to interact with Github without using Git at all, only Hg. On Github, I forked the pandas repo. I successfully cloned my fork to my computer. I want to add the original pandas repo as a URL in Hg, so I can pull changes from that repo and integrate them with whatever changes I make myself. I added the original pandas repo in the URLs in TortoiseHg under the name "upstream".
However, if I try to pull from that original upstream repo, Hg hangs for a long time and then eventually issues a "504 - Gateway timeout" error. If I directly clone the pandas repo (instead of cloning my fork of it), I can pull from it fine.
The strange thing is that this doesn't seem to happen with all repos. I did the same process (fork, clone the fork, then try to pull from the original) with the matplotlib repo, and it seems to pull from the original repo just fine.
Even stranger, if I clone the original repo, and then add my fork as an extra URL, I can pull from both. So somehow the URL as set during the original clone is okay, but setting the same URL manually as a source doesn't work.
This seems to indicate that the problem is with the pandas repo specifically. Is this possible? Is there some setting on Github that could be affecting my ability to pull from that repo? What can I do to make it work?
I repeated the process with hg-git via the command line and couldn't replicate the problem. So there are a few possibilities:
There's either an issue with (your) TortoiseHG (config).
You've made a typo of some type when entering the URL into TortoiseHG.
There's a weird corner case in hg-git.
Something is causing trouble in your hgrc -- either your global one (hidden in your home directory) or your repository specific one (found in .hg/hgrc).
If you provide your hgrc files as a Github Gist (anonymizing them as need be), that might provide some insight.
In the meantime, one solution is to do the git stuff by hand and then force an update:
cd path/to/hg/repo
git fetch https://github.com/pydata/pandas.git # equal to hg pull,
hg gimport # pulls the changesets from the hidden git repo into the mercurial repo
If this works, then there's probably something wrong with the saved URL.
You still have to worry about merging and rebasing and whatnot, but you can do that within Mercurial. The hidden git repo will be automatically when you do a push to a git remote, or you can force it to update via hg gexport.
A noob question... i think
I use Mercurial for my project on my laptop. How do i submit the project to an online server like codeplex?
I'm using tortoisehg and i cant find the upload interface for submit the project online...
From the command line, the command is:
hg push <url>
to push changes a remote repository.
In TortoiseHg, this is accessed through the "Synchronize" function, which seems to show up if you right-click in a Windows Explorer window but not on any file. It's also available in the workbench; the icon is 2 arrows pointing in a circle.
For these things, I find the best way to go is to use the command line interface - TortoiseHG is OK if you need to perform some common operations from the file browser, and it's a nice tool to visualize some aspects of your repository, but it doesn't implement all of mercurial's features in full detail, and it renames and bundles some operations for no apparent reason.
I don't know how things work at codeplex, but I assume it is similar to bitbucket or github, in which case here's what you'd do:
Create an empty repository on the remote end (codeplex / bitbucket / ...).
Find the remote repository's URL - for bitbucket, it is https://bitbucket.org/yourname/project, or ssh://hg#bitbucket.org/yourname/project.
From your local repository, commit all pending changes, then issue the command: hg push {remote_url}, where {remote_url} is the URL of the remote repository. This will push all committed changes from your local repository to the remote repository.
Since the remote's head revision (an empty project) is the same as the first revision in your local copy (because all hg repositories start out empty), mercurial should consider the two repositories related and accept the push.
For an introductory guide to command-line mercurial, I recommend http://hginit.com/
I have a problem when I'm pushing my code and files to the remote server.
It says that the changes (after they were commited) were pushed successfully onto the remote server but the changes are not visible on the server.
Since I don't have access to the server, how would I go about debugging this problem to find out where the problem occurred (the logs on the server don't show anything I am told)?
Maybe important note:
I had to force push the changes because it wouldn't sent them otherwise.
Second question:
How can I re-push my changes?
If
$ hg outgoing
shows nothing, then the changes are already there on the server — I promise! If you had access to the server, then running
$ hg log
would reveal that the changesets are really there. The confusion must be that the working copy on the server is not updated when you push changes to it. So someone needs to run
$ hg update
on the repository on the server to actually make the working copy update. Normally, you don't need a working copy on the server, but if you're using Mercurial to publish, say, a website, then you'll want a push to also update the working copy.
The solution is to add
[hooks]
changegroup = hg update
to the .hg/hgrc file on the server. Maybe you can ask some admin to install that hook for you?
I have a local machine ("laptop") and a shared Mercurial repository on another machine ("server").
The shared repository is set up as a multi-repository as described in the Mercurial documentation using Apache, the hgwebdir.cgi script and Mercurial 1.4.
The setup works in the sense that I can browse the projects (repositories) in the web browser, I can clone and pull from the server, and I can push from the laptop when the project/repository already exists on the server.
But I cannot create a new project on the laptop (hg init, do stuff, hg commit) and push it to the shared multi-repository (hg push http://server/hg/my-new-project-name) - I get "abort: HTTP Error 404: Not Found", presumably because the directory/project repository does not exist yet.
How can I push a new project/directory structure to a Mercurial running elsewhere? I couldn't find anything in the documentation, how do you guys do it?
You cannot create new remote repositories over http with the built-in functionality. Your options are to either:
create with a ssh clone: `ssh clone local-repo ssh://you#remote//path/to/repo'
log in to the remote repo and do a hg init where you want the repo. After that you can push to the new empty repo
Use a cheesy http-creation CGI like the one I wrote here: http://ry4an.org/unblog/UnBlog/2009-09-17
Update
I tried using Dropbox as described below, but couldn't make it sufficiently reliable, so I'm not recommending that option.
Original answer below, kept for context.
/update
I found one more option: Skipping both http and ssh altogether and using Dropbox for shared repos.
For the one-person-multiple-computers scenario, it looks like the simplest option of the lot, and you get backups as a nice side effect.
Here is a discussion on Hacker News