We have created git bare in the shared mode and created the data repository by cloning the git bare.
As both git bare repo and git data repo lies on the same file system, it seems the object files are hardlinked to save space.
I wanted to backup the git bare repository now and delete the data repository.
I am afraid that deleting the data repository will leave the bare repository in the stale state due to the object files being hardlinked.
Is there a way where I can copy all the object files from the data repo that are hardlinked to the bare repo, so that I can delete the data repo and backup the repo?
Your help is much appreciated.
Don't be afraid. You can simply delete one of the copies without losing the other. There is not one "original" and one "copy". Instead, both are "original" files that will continue to exist without the other side. Only the file's content is shared on disc and thus stored only once.
That's not a feature of Git. It's exactly the way how hardlinks have always worked (in contrast to softlinks/symlinks, which have a clear distinction between the link file and the file linked to). It is also the reason why hardlinks don't work across filesystem boundaries within one machine. And it is also the reason why functions (in several programming languages) that remove a file in UN*X-like systems are often called "unlink" instead of "remove".
Of course, since the file contents are stored on disc only once, both copies will change if you edit one of them. But that is no problem. Git never _changes_ files in the object database, if only adds them (and occasionally removes (= unlinks) them on garbage collection). Since object files in Git are immutable, the fact that they are hardlinked to other immutable files doesn't matter at all (apart from saving disc space), which is why the -l option is now the default in git-clone.
Related
I'm using the free plan on bitbucket to hold a repo in mecurial. There is one other person using the repo with me. When we first started we were putting everything into the repo. That included a folder called documents that held a ton of pdf files. We have now excluded that folder but all those documents and their history are still in our repo. The free version of bitbucket allows for a repo of 2 gig. I'd like to remove the history of this documents folder from the history because we are closer to the 2 gig limit then i'd like to be. Is there a good way to get rid of that history. What are my options. I'm not finding much online but that could very well be because i'm using the wrong words to search.
I tried to use hg remove Documents* but that didn't work because it's telling me that there are no tracked files.
Update --
I looked in TortoiseHg and on rev 91 i added a ton of files in the Documents folder (it has sub folders as well if that matters). So I think that is likely where the size of the repo blew up. So if anyone knows how to remove those from history i'd be interested.. and is it safe to remove them. We do not need them in the repo.
The normal way to remove history is to create a new repo using hg convert
Before you start you tell everyone to stop using the repo.
then your run hg convert specifying the files you want to exclude.
Once you are done you tell everyone to start using the new repo.
After running my new Flutter app for a first time on iOS, git status is reporting untracked files
ios/Runner.xcworkspace/xcshareddata/
Should I add this to version control or add them to .gitignore?
The xcshareddata folder does not contain any user sensitive data, or even machine sensitive data.
That directory, as the name implies, is used to store shared settings, e.g: Schemes. In my experience, it is best to add it to version control, as there seems to be no good reason to keep it from being versioned.
The MSDN documentation lists four options, with limited explanation:
Overwrite "Overwrite existing writable files if they conflict with the downloaded files." Does this apply to all files, or just ones we've told TFS we've edited?
GetAll "Gets all files." What files does TFS not normally get?
Preview "Executes a get without modifying the disk." This one seems pretty clear.
Remap "Remaps existing items on the disk to the server items where the content and disk location are not changing." I have no idea what this means.
Overwrite: will blindly overwrite writable files that you have not pended for edit. If you have marked a file as 'writable' then you have violated the contract with TFS and it assumes that you have done this for a good reason (eg, modifying the file without taking a checkout, because you were working offline). This will generally produce a writable conflict on the file, but if you specify this flag, then the writable file will be overwritten.
This only applies to server workspaces (local workspaces are always writable). This has no effect on files that you have pended for edit. Get will always produce conflicts for files that are edited locally and updated on the server; if you want to update files that are checked out, you must undo the checkout (or resolve the conflict with TakeTheirs).
Get All: will download every file and update it, even if TFS believes that the local version is the same as the remote version and that downloading a new version would be a noop. TFS tracks every version that you have locally, as well as remotely, so this is only useful if you edit files locally without checking them out.
If you have kept them writable, then then - as mentioned above - this will be a writable conflict. If you have then marked them read-only then TFS assumes that you have not made any changes and will not bother updating them when you do a get (because it knows the file contents haven't changed). If you have manually changed the file contents, then marking this will update those files to the server version.
Preview: will just fire events and provide results that indicate what would be downloaded with the given parameters.
Remap: is a clever option that allows you to perform an in-place branch switching (which is very common with some version control systems that branch at the repository level - like Git - but somewhat complicated in TFVC.)
Consider that you have mapped $/Foo/main to C:\Foo, and done a get latest. If you update your working folder mappings so that $/Foo/branches/feature now points to C:\Foo, then issue a get with Remap, then the server will download only the changed files between main and branches/feature, so it's an inexpensive way to update your local workspace to a feature branch.
(If you're looking for an example, this functionality exists in the command-line interface and in Team Explorer Everywhere but not in Visual Studio.)
I have a TFS workspace which I need to move to my new PC. I have copied the whole folder structure over and ensured that the workspace is mapping to the correct folders. However the "Latest" column for every file displays as "Not downloaded". How can I reconcile this such that TFS is aware that the files match the server version?
The standard answer seems to be to re-download the whole thing. Unfortunately the repository is huge, my connection is unreliable, and I have monthly download quotas. Is there anything in the command-line tools or power tools that can make it compare file hashes or similar and realise that the files are identical?
Thanks.
There's a binary metadata file inside the working copy that stores the mapping of every path in your repo, to the path on the filesystem.
It uses absolute paths - so unless your new project folder occupies the exact same location as it did on the original computer they won't match.
Because it's a binary format, you can't do something simple like mass replace the paths with a text editor or sed.
I am currently working on a Ruby on Rails repository where the folder structure is pretty complex, and i often need to restructure the files (for example moving js files and css files from folderA to assets folderB and in many cases integration of file A and file B into file A, and I delete file B in my local).
I notice that git and bitbucket by default does handle versions by incrementally maintaining changes to the existing and new files while still maintaining the older files and folders under earlier commits.
As a result, when I download the entire rails repository from bitbucket at a later stage, I get a very complicated and structure of files and folders that is not representative of my latest repository structure as it contains earlier versions of files that have been deleted or moved. (in the case above, file B still appears on the download)
How do I ensure that my directory structures and files are representative exactly of what i have saved down as my latest version and do not include prior deleted files.