The "created" date is lost after I push my files to git. When I clone my repository the "created" date is the current date. Is that normal?
When you clone a repository, Git does not check files out using the original time specified in your commits. Instead, it creates the files as normal, using the current time.
This is in fact normal, and it also has the nice benefit of working properly with Make, which uses the file time to determine whether a file is in need of being rebuilt. Since Git always uses the current time, and files Git has checked out will be considered as changed, and Make will build any products that depend on them.
Yes that's normal.
As far as file metadata (created, last modified, executable or not, etc.) goes git only saves if the file is executable or not. The other values like when it was created are completely managed by your filesystem independent from git.
When you clone the repository the files are created now on your filesystem - so the created metadata of the file is the current date.
Related
I'm using git as a VCS and I got several commits in a project. I'd like to upload every change made after a specific commit that is not the latest. Currently, if I want to do this, I have to upload practically every file in my project, or manually search for the modified files after a certain date. Both options are kinda tedious.
Is there an option that helps finding the modified files from a certain commit? Or possibly a combination of searching and selecting the files modified in a given range?
Use git log -n 1 --name-only <revision> to get files modified within a specific revision, or git diff --name-only <revision_1> <revision_2> for files that were changed between two particular revisions.
Here's my situation: I have a checkout from a repository that has long since been moved to a different site. This working copy of mine is from an old revision of said repository, and there are local modifications as well. The author's method of moving the repository involved deleting the contents of the old repo, leaving a single text file named something along the lines of "MOVED", with instructions.
The new repository still has the same (or similar) structure. What I would like to do is "merge" (I apologize if I'm using the wrong terminology) what is in the new repository with what I have in my working copy. I'm a little hesitant about doing this since I learned that TSVN will overwrite local changes without prompting me sometimes.
How can I go about merging the new repository in my local WC?
I suggest you to Check Out your "new" repository into another folder and overwrite the files with Copy-and-Paste. As the project structure was significantly modified, after overwriting this local copy, check file by file using Diff command.
At finishing, Commit the modifications and Update your other local copy. The local changes from this local copy won't be lost. The most that can happen is some conflicts.
I am working with a CVS repository found on a remote server.
I check out the code to a local directory code_local
Then I copy code_local, into code_local_2
Do I have now two independent local copies of the repository? Can I change files, commit, update etc. on each directory independently, is if it was done form two different computers?
(this may depend on the way CVS stores information about a local copy)
Yes I do know it's not a straight forward use of CVS, just asking if it will work
Do I have now two independent local copies of the repository?
Yes you have two independent LOCAL copies.
Can I change files, commit, update etc. on each directory
independently?
No, both copies point to the same file on the same repository. so they are independent as long as you haven't committed them. when committed the last commit operation will overwrite the previous one.
in fact there is a CVS folder beside every folder of your code that keep repository information of files inside that folder. so when you copy a project or a package, the CVS folder will be copied along with, so the same repository entries will be referenced, no matter how many copies have you made.
Even if you past the copied folder to another package hierarchy, whenever you commit the files it will replace the original files in repository where it first created.
If you want to have independent copies you have to copy and place your source code (.java) files only and commit it through Eclipse for example, in this case the CVS plug-in doesn't find any existing CVS folder beside the new folder and generates a new one in the local and new entries in the repository.
Is there a way to exclude a specified file from the merge process? when merging from our production branch to the test branch for the testers to use, we want to exclude a config file which contains the SQL connection string. Preventing the need to edit it post merge. I did see a comment about using the cloak option but i can only see this available for folders not files.
Tim
There are a few different ways you can do this. If you don't plan on changing your config file in the future and you just don't want its current contents to make it to the parent branch, you could simply do a "tf merge /discard" on the file and check that in. That basically says, never merge the changes that have happened to this file to the target branch. However, if the file changes again, it will be a candidate for a merge.
So, if you plan on continuing to change the config file in question, then you have two options. The first is to always cloak this file in the target branch workspace that you are performing the merge in. Yes, it is possible to cloak files, it is just the picker in the dialog doesn't make this easy. If you navigate all of the way down to the containing folder, select that and then manually enter the file name at the end of the folder string, the cloak will work on the file. This approach has the downside that you have to remember to always cloak this file in the workspace that you are performing the merge in and if someone forgets to do that, the file will be merged up.
The third, and likely best, solution to this problem is to use the tfpt.exe power tool with the branches command to cloak the config file from the parent's branch mappings. You can download the latest 2010 power tools here. You will want to run "tfpt branches /properties /collection:" and then select the "mappings" channel. In there you will probably just see a single mapping for the root of the branch. You will want to create a cloak mapping for the file you do not want to be merged and then click OK. On all subsequent merges to that branch (note, from any other branch) the file in question will not be merged.
Not a very nice solution, but you could remove the checkin security on that file so you are unable to checkin the file after a merge.
When I rename a file using Mercurial, and then commit without any changes, why does it still send the full file to the repository? (I can tell because the subsequent push to the remote repository shows how much data is being transferred). Isn't it obvious to it that it simply needs a rename?
I'm using the latest version of TortoiseHG under Windows, and the file in question is a 20MB text file.
This is a known deficiency in the storage format used by Mercurial. You can search for "lightweight copies" for the full story, but briefly, the problem is that a new revlog is created for the new file name when you rename. The new revlog starts with a compressed snapshot of the full file — this is normally not a big problem, but it's still bigger than a zero-sized delta.
There's little you can do about it now unless you want to patch your Mercurial and run experimental code. The good news is that you just have to wait: the patches that we've been working on will be able to convert your existing repository into a more space efficient one automatically. This will happen when you hg clone over the network or if you use hg clone --pull locally.