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.
Related
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.
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.
So i've made the switch from CVS to mercurial for my website.
The biggest issue I am having is that if i'm working on some files that I don't want to commit, I just save them.. I then have other files I want to push to the server, however if someone else has made changes to the repository, and I pull them down.. It asks me to merge or rebase.. either of these options will cause me to lose my local changes that I have not committed.
I've read that I should clone the repository for each project on my local host and merge it into the live when it's ready to do so. This not only seems tedious, but also takes a long time as it's a large repository.
Are there better solutions to this?
I would have hoped that Mercurial would see that I haven't committed my changes (even though I have changed the file from what's on the server) so it'd just overlook the file.
Any input on this would be greatly appreciated. Thank you!
Also, i'm using the hg eclipse plugin to work on my files and push/pull from the server.
hg shelve is your friend here I think.
which comes from the shelve extention (maybe - see below)
from the overview:
The shelve extension provides the
shelve command to lets you choose
which parts of the changes in a
working directory you'd like to set
aside temporarily, at the granularity
of patch hunks. You can later restore
the shelved patch hunks using the
unshelve command.
The shelve extension has been adapted
from Mercurial's RecordExtension.
or maybe its the attic extension
This module deals with a set of
patches in the folder .hg/attic. At
any time you can shelve your current
working copy changes there or unshelve
a patch from the folder.
it seems to have the same syntax as the shelve extension, so I'm not certain which one I've used
I second #Sam's answer. However, if you prefer to use standard Mercurial, a simple workflow is to
save your working dir changes in a temporary file,
sync your working dir with a specific revision, then
push, pull, merge .. whatever you want to do and which requires a clean working copy, and
get back your changes from the temporary file into the working dir.
For instance:
$ hg diff > snapshot.patch # save your uncommited changes
$ hg up -C # get a clean working copy
$ hg pull # do things ..
$ hg merge # .. you need a clean ..
$ hg commit -m "merge" # .. working copy for
$ hg import snapshot.patch # get back your uncommited work
First, are you working from the commandline, or using something like Tortoise?
If you're working from the commandline, and you've done a pull, mercurial will not ask you to do anything, as it merely updates your local repository.
If you then do an hg update and have local changes, it should do what you're used to from CVS. It will update to the tip of the current branch, and attempt to merge your outstanding changes in. There are some caveats to that, so refer to the official docs at http://www.selenic.com/mercurial/hg.1.html#update.
Also, for temporarily storing changes, I would recommend MQ over shelve. Shelve only provides one storage area, whereas MQ provides as many as you need. MQ takes some getting used to, but worth the investment.
I need to delete my "uploads" folder from the repository with all its history because it contains only junk testing data.
Please help.
You'll want to use the convert extension that ships with mercurial. Since you want to scrub a directory from the history you'll have to completely filter you're existing repository, CONVERTing it into a new one.
Assume the following made up structure of your repo:
/
src
doc
images
upload
Create a simple text file with the following content
exclude upload
You can do more with this file but keep it simple to get to your goal. The path to be excluded is relative to the repository root
Now run mercurial convert
hg convert --filemap path/to/the/textfile old-repo new-repo
Change to the directory of the new repo. Notice that mercurial created a bare/null rev repo (no content but the .hg directory). Run the following to update to your latest changset. Notice the upload directory is gone!
cd path/to/new/repo
hg update
WARNING: I do not know how this handles named branches or tags. You're on your own. At least you're not modifying the original repo. Make as many copies as you need to get it right.
Before pulling from the central repositiry, I usually use the 'hg incoming' command to see what I will be pulling. However, this only gives me a list of changesets with some comments, and not a list of the actual files that have been modified.
1) In such a situation, how can I get a list of modified files (including some basic info about the chane, like Removed, Moved, etc)?
2) Similarly, when I do an 'hg status', I get the differences between my local working copy and what is currently on the repository. However, a more useful feature would be to get the differences between what is incoming and my local working copy. How can I get this?
Thanks!
1/ Most options are presented in "how to see files in repository before running 'update'":
hg incoming --stat
Notes:
For remote repository, using --bundle avoids downloading the changesets twice if the incoming is followed by a pull.
--stat: output diffstat-style summary of changes.
(ie: Statistics of changes with the following format: "modified files: +added/-removed lines")
2/ See RDiff extension (and the SO question "Using Mercurial, is there an easy way to diff my working copy with the tip file in the default remote repository")
If you don't have a recent enough version for --stat, you can get a similar overview using status:
cd repo
// grab the newest changes into a bundle
hg incoming --bundle morechanges.bun
// get an id for the current tip
hg tip
changeset: x:abcdef
...
// see what's changed by overlaying the bundle on the repo
hg -R morechanges.bun status --rev abcdef:tip
//info you're looking for
// everything's good; add the bundle to the repo
hg pull morechanges.bun
rm morechanges.bun