The hg history command shows me results in the following format:
changeset: 1:000000000000
user: somebody
date: Fri Jun 06 22:38:10 2014 +0000
summary: Do something clever.
The "date" seen above defaults to using the time the revision was committed to its original repository. Is there a parameter I can give it to get the time it was pushed to the upstream, or pulled to my local repository, instead? Both hg help history and Google ({hg history timestamps}, {hg config revision timestamps}, {hg revision timestamps local}, ...) are drawing a blank for me.
(Alternatively, is there any other way for me to quickly eyeball the history and see what revisions were done in a particular timeframe, when one of the committers has a computer clock which is always off but not consistently by the same amount?)
You can select changesets by users and date using revsets (see also hg help dates for how dates are formatted):
hg log -r "user(soandso) AND date('2014-05-21 to 2014-05-30')
The dates will still be the commit dates. I'm not sure if or where any other dates are stored.
Related
In my project, the number of HTML files are growing. How will I temporarily remove all the files which are not going to be changed in the git sub branches?
My problem is that when I merge it with the master branch, the files then got removed in the master too.
This is not how git is supposed to work. Therefore, as others have suggested it's not advisable. Having said so and considering that git is not designed with such capability, there are a couple of ways to achieve what you want to do. But again, it might not be a smooth quick process given that this is something that is not desirable long term to manage a project.
Method 1 (smoother)
create your new branch and start working on it git checkout -b branch_name
first thing to do after creating new branch is to delete ALL your files that you don't want on this branch and then commit. As every commit, this will generate a hash (e.g. 4f8046) that identifies it. The hash can be found with the command git log.
Continue with your workflow and commits as usual. Showcase to your clients etc.
Before merging to master, undo the commit where you deleted the other files that are still on master, so that when you will merge the unmodified files will be kept there. do this with git revert <commit_hash> therefore in this example git revert 4f8046.
merge your code in master.
Example: if git log outputs something like:
commit a3712a
Author: developer 1
Date: Thu Jul 16 18:00:00 2017 +0100
Feature 2
commit 66e427
Author: developer 1
Date: Thu Jul 16 17:00:00 2017 +0100
Feature 1
commit 4f8046
Merge: 4f6e4e9 030a11c
Author: developer 1
Date: Thu Jul 16 16:00:00 2017 +0100
Deleted Files that I don' want on this branch
Then you will use git revert 4f8046 (to reintegrate deleted files) and then git merge master.
Method 2
A second approach is to use git cherry-pick which is the opposite of git revert. This commands lets you pick a specific commit and apply it to the current branch (therefore manually applying the commits from your branch to master). However, this would entail not merging the new branch into master:
Create your new branch and start working on it git checkout -b branch_name
Delete your files that you don't need on this branch and commit. You can do this even in multiple commits. Just make sure that enhancement/feature and deletion of files that you don't want on this branch are in separate commits
Make modifications to your files in this separate branch, trying to keep the number of commits small.
Save the hash of all the commits that you would like to apply from this branch to master (i.e. all the features that you created). Again, git log will print all commits and their hashes.
Go back on master git checkout master
Using git cherry-pick apply all the commits chronological order to master.
Example: if git log outputs something like:
commit a3712a
Author: developer 1
Date: Thu Jul 16 18:00:00 2017 +0100
Feature 2
commit 66e427
Author: developer 1
Date: Thu Jul 16 17:00:00 2017 +0100
Feature 1
commit 4f8046
Merge: 4f6e4e9 030a11c
Author: developer 1
Date: Thu Jul 16 16:00:00 2017 +0100
Deleted Files that I don' want on this branch
Then you will go on master and use the commands git cherry-pick 66e427 and git cherry-pick a3712a in this order (cronological), and omitting the commit in which you deleted the files to be kept on master.
This assumes that the files modified with features are still in master and have not been modified further on master (so that cherry-pick will not generate a conflict).
Keeping only certain files per branch is not a best practice; there is no "best way" to do it.
You mention that the idea is to provide subsets of the files in client demos. That suggests perhaps they're for different projects and should be in different repos. If there are other scenarios where you need to coordinate across repos, you could consider using submodules.
If really it is better to think of them as one project - e.g. maybe changes are typically coordinated across multiple sets of files - then you should find a different solution for creating your demo packages (perhaps with a suitable build tool)
We are using Kiln as our mercurial server and I there are three developers working on the same repo and i get this issue often and I am not quite sure what is happening.
Every once in a while I will do an hg pull.
Then when I run hg up I get the following message
abort: crosses branches (use 'hg merge' to merge or use 'hg update -C'
to discard changes )
ok so I run hg merge and I get
abort: outstanding uncommitted changes (use 'hg status' to list
changes)
ok so I run hg status and I get something like this
! Safemail 3.0\CSM3.0\AddinSetup\Release\AddinSetup.tmp
! Safemail 3.0\CSM3.0\Outlook2007Addin\Outlook2007Addin_TemporaryKey.pfx
no idea what to do with that.
If I run hg commit again it says no changes.
Finally if i run hg heads I get
changeset: 51:daea74a29d5c
tag: tip
parent: 49:b88e6e522672
user: Rahul Chandran
date: Mon Jan 23 13:30:54 2012 -0800
summary: added login code
changeset: 50:cb6f6e1eec5e
parent: 46:d83431c322ad
user: dthompson#Jabberwock.lan
date: Mon Jan 16 22:10:11 2012 -0600
summary: Adjusted Email-PDF formatting
Clearly I do not come from a DSCS background and I am probably missing some basic understanding of what is going on . Any help appreciated.
What I do know is that the code that my co worker checked in via a push has like no files in common with my changes. I would not expect like a merge conflict or some such in a non distributed source control system . essentially I am having some trouble understanding what is happening here exactly
Check out the help for hg status. It will tell you that ! means:
! = missing (deleted by non-hg command, but still tracked)
So you deleted some files that are tracked in your repository. If you didn't mean to track them in the first place (they look like good .hgignore candidates) you can hg forget FILENAMES; hg commit them. If, instead, you do mean to track them you can hg revert FILENAMES them (to get them back into your working dir from your repository.
Once hg status agrees you have no uncommitted changes you'll be able to hg merge.
Consider taking a little time to read the first few chapters of the (free) Mercurial book. These basic concepts are easy when presented well and in order, but horribly frustrating when you try to pick them up piecemeal from google searches and Stack Overflow questions. It's worth the 30 minutes to save you hours.
I'm attempting to use the hg log command to show a series of revisions, x through y.
When I do this:
hg log -r 1+5
I get this:
changeset: 1:7320d2a9baa5
user: Tim Post <tpost#whereiwork.com>
date: Fri Sep 30 20:38:29 2011 +0800
summary: Foo foo everywhere is foo
changeset: 5:8d6bea76ce60
user: Tim Post <tpost#whereiwork.com>
date: Fri Sep 30 20:51:42 2011 +0800
summary: Blah blah blah
Which is Mercurial understanding that I want to see revisions one and five instead of one through five.
Oddly enough, this works:
hg log -r 1+2+3+4+5
But, that gets extremely cumbersome, especially when trying to get a summary between revisions that are +500 away from each other.
Is there a way to get logs for revisions x through y instead of x and y without concatenating every revision in the series?
I'm using the output in order to determine how many commitments each developer made in a given series. If I simply can't do that using the hg command, I'm more than open to using the Mercurial API. I resorted to the hg command because I did not see an obvious way of doing it via the API.
By API, I mean just using Python via a hook or extension.
hg log -r1:5.
Mercurial has an entire mini-language devoted to selecting revisions for commands (not just for logs). For more information, see hg help revsets (needs Mercurial 1.6+).
I'm new to Mercurial, and I made the mistake of making different changes on different systems before the main repository was up to date. (I understand this is what Mercurial is built for, but my thick brain is struggling to resolve the issue.)
Now on my primary development server, everything is up to date and committed. However...
$ hg push
abort: push creates new remote branches: 4f2672f039d7!
(use 'hg push --new-branch' to create new remote branches)
I don't really want a new branch. I just want all the changes to be merged.
$ hg heads
changeset: 459:ff5f94e44aba
branch: 4f2672f039d7
tag: tip
parent: 458:e63d02baf4cf
parent: 455:267abda62069
user: mike#...
date: Tue Sep 13 14:25:16 2011 -0400
summary: Images from prof
changeset: 455:267abda62069
parent: 453:a74757e26357
user: mike#localhost.localdomain
date: Tue Sep 13 09:08:12 2011 -0400
summary: images for FLC
Point me in the right direction?
EDIT: (adding detail)
When I try to merge, I get the following result:
$ hg merge
abort: branch '4f2672f039d7' has one head - please merge with an explicit rev
(run 'hg heads' to see all heads)
I have tried hg merge ff5f94e44aba, and all of the revs listed above, and each one returns the same result:
$ hg merge 267abda62069
abort: merging with a working directory ancestor has no effect
It looks like you've accidentally created a branch with a silly name. What you most likely want to do is reapply your changes with a branch name that makes better sense. There's no totally automatic way of doing this, but you can extract each changeset as a patch, revert to the point where you messed up and reapply those changes on the proper branch.
Basically what you need to do is look at the changelog; probably by running hg out to see what's missing from the central repository. Make a note of each of the revs that you want to keep.
Next update to the last good revision. Make sure that you are on the branch you wanted your commits to be on.
Now you will apply each of the changes you made and commit each one. You can automate this process something like this:
BADREVS="123 124 125 126"
recommit() { hg di -c $1 | patch -p1; hg ci -m "$(hg log -r $1 --template '{desc}')";}
for rev in $BADREVS; do
recommit $rev
done
Now you've got your changes in your local repository twice; once as the commits on the weird branch and again on the right branch. You can push those changes to the central repo using hg push -b GOODBRANCH so that only the changes to the right branch go up; Alternatively, you can install the strip extension to remove the changes you didn't want from the local repo and then you can push as normal.
By the sound of it; you will still have to deal with the changes made to the central repository before you can push, since you pushed changes from another repo. You probably want to do this merging after you clean up the change history in the local repo.
Pull from remote and then update / merge / commit first. Then you won't make new branches.
I've had this happen when I missed a merge. I like the TortoiseHg workbench for this because it can be a little easier to find what you missed through visualization.
A good way to avoid this in the future, how I stopped getting this error, is the fetch extension. Set your post pull to fetch and it will automatically merge for you, which is very nice. If there's a conflict it brings up whatever conflict resolver you use.
I have a repository named master which keeps product releases. It has several tags (such as 1.0,2.0,3.0) as baseline. When I want to create hot fix for one version, for example 1.0. I use command as following:
hg clone master#1.0 hotfix_1.0.1
cd hotfix_1.0.1
hg tip
changeset: 14:b2492c2611a1
tag: tip
user: codingboy <codingboy#gmail.com>
date: Thu Dec 09 14:03:23 2010 +0800
summary: fix bug4
I find tip version is what I need, but is not tagged with 1.0. It will cause my changes in hotfix_1.0.1 can not be push to master. the error is
(abort) unknown 1.0 revision.
I check master repository. the log shows below
changeset: 15:3497c46cbc7f
tag: tip
user: codingboy <codingboy#gmail.com>
date: Thu Dec 09 14:03:27 2010 +0800
summary: Added tag 1.0 for changeset b2492c2611a1
changeset: 14:b2492c2611a1
tag: 1.0
user: codingboy <codingboy#gmail.com>
date: Thu Dec 09 14:03:23 2010 +0800
summary: fix bug4
so it seems cloned repository lost changset#15. My understanding is hg clone src#tag dest should clone tag which I need. But this operation can not clone child of changeset#14 which is do tagging. So what I have done is to use command
hg clone master hotfix_1.0.1 -u 1.0
I do not like this command. if master repository is huge and I just want to fix old version, It will waste time to clone and push changes.
Do I have any other approach to clone one repository from one baseline or tag correctly?
thanks...
Due to the design of Mercurial tags, the tagged revision does not contain that tag. In other words, 1.0 doesn't "know" it's 1.0.
Mercurial recommends the solution you give at the end. A possible mitigation for the performance issues is to keep (pulling as needed) a single clone of master that you don't modify. Then, (as needed) clone that locally and update to the desired version. The clone will (assuming same volume and a modern filesystem) use hard links, minimizing the required copying.