my hgrc:
[ui]
style=compact
[extensions]
graphlog=
color=
but hg glog has no color. and, how many style for hg log, help, man can't get any information.
The four command line styles available are:
default
compact
changelog -- looks like a Gnu-style changelog file
xml -- provides log data as an XML structure
This is found by looking inside Mercurial's template's directory, which on my system ends up in usr/share/mercurial/templates but may differ on arch.
With mercurial 1.6.4 I do get color in glog but only if I"m using the default style. The compact style doesn't seem to have color codes.
Related
We are looking for a way to add / update a custom tag at the beginning of each file being committed during a commit. Its some kind of local timestamp we need.
I was thinking of hooks.
Unfortunately I cannot find a useful hook for that:
precommit: unsuitable as it fires before hg knows any metadata of the commit
pretxncommit: unsuitable, as the documentation clearly states that we should not change the working dir at this point
commit: unsuitable, as it fires when the commit has already happened.
EDIT:
I can not use hg's inline changeset-hash and / or datetime. For the following reason:
Our files get later imported into an external system (we do not have control over) which does not support any kind of versioning.
To simplify stuff: let's say tag is an ever-incrementing no. (everytime we commit). This tag is then used to help getting an idea of the version / status of the file on the system in respect to the file in the repo - like "no. of changes we're missing" and such.
Any ideas?
I would suggest a two-stage solution. First, create an alias along the following lines:
[alias]
tcommit = !tag-changed-files && $HG commit "$#"
Here, tag-changed-files would retrieve a list of modified and added/moved files via $HG status -ma -n or $HG status -ma -n -0 and tag them. I am assuming that re-tagging files that have been modified but aren't being committed yet is a harmless operation; more on that below. Note that you can even redefine commit if you absolutely want to via:
[alias]
commit = !tag-changed-files && $HG --config alias.commit=commit commit "$#"
However, this is potentially problematic, because it may confuse scripts.
You could also integrate the commit step in the program if you wanted to, and even try and parse the command line arguments to only tag those files that you are committing. For this approach, using hglib might be appropriate to avoid the overhead of invoking Mercurial multiple times. (Note that hglib and other tools that use the command server ignore aliases and command defaults, so this works even if you alias commit).
Second, you'd install a pretxncommit hook that verifies that files that are being committed have indeed been tagged appropriately (to ensure that the tag-changed-files program hasn't been bypassed by accident).
This should work without a problem on full commits; for partial commits, any files that were changed but have not been committed would also have been retagged, but since they will be either committed later (and get tagged properly at that point) or reverted, that should be harmless.
an idea of the version / status of the file on the system in respect to the file in the repo
Just one idea
Stop reinvent the wheel
Incremental counter is just shit, if you task is "to know, which version is on LIVE and which - in Mercurial's tip" (and this is your real business-task, yes?!)
Keyword Extension give you last changes per file.
If you want to inject changeset of repository into files (it's reasonable good way), re-read this part of wiki-page
If you just want to version your entire repo, do not use this
extension but let your build system take care of it. Something along
the lines of
hg -q id > version
before distribution might be well enough if file-wise keyword
expansion in the source is not absolutely required
You can insert hg id output into files at export stage (in planetmaker's sed-style), bu you can also have this additional metadata in files permanently in VCS with special encode|decode filters
There is - to my knowledge - no intrinsic system in mercurial which supports what you describe. However I can recommend an approach which somewhat is adopted from building a software release package from the repository: Make a small export script which replaces a certain KEYWORD in your files with the version information you need. A Makefile target could look like which creates a zip export for revision XXX with version information in all files which support it (thus contain the verbatim KEYWORD - use something truely unique here):
VERSION=$(hg log -rXXX --template="Version: {node|short} from {date|isodate}")
export:
hg archive -rXXX -t files export
for i in $(hg ma -rXXX); do sed -i "s/KEYWORD/$VERSION/g" $i; done
zip -9rq export.zip export
I use a similar approach in my Makefiles where I create versioned export for the source of a particular revision of my software.
EDIT: if your purpose (as stated by the comment) is only to implant the number of commits made to that file: then you can use indeed a pre-commit hook and modify the file. You can count the number of modifications made to a file with hg log FILENAME --template="{node}\n" | wc -l. Do that for every file and do the sed replacement in the header of each file in the pre-commit hook.
i looking to get the files which are tagged with a specific changeset.
I would like to copy it to another directory, how can i do it ?
Thankss
The question isn't clear, but if you want a complete set of files from a specific tag just do:
hg archive -r <tag> <destinationdir>
See hg help archive for details.
hg st --change [rev] will show a list of the files that changed in a given revision. Since mercurial recognizes a tag name for a revision automatically (assuming it's unique to the revision hashes) this will work with a tag name as well.
If you want to copy these files in an automated fashion, you'll need a clean list; also, you probably just want the files that are there, not the ones removed/deleted. For this you'd use
hg st -man --change [rev]
Using this list to copy these off somewhere else will be platform/shell dependent. From Windows commandline, at the root of your repo, you could do something like
for /f %I in ('hg st -man --change [rev]') do copy ..\changes
, although that won't preserve subdirectory paths. I'll leave that as an exercise for the reader :)
UPDATE
Sorry, I should also have noted that you'll need to update to the revision in question if you want to copy the files as they were at the time of said revision (I'm assuming here, but this seems like the natural reason to want to do this...).
Is there a way, in TortoiseHg, to hide whitespace changes when annotating file?
I know that there's an option in hg, but didn't see a support for it in TortoiseHg.
I'm having nightmares, searching for the changeset where the actual change has took place...
You can set flags in TortoiseHg settings. Open section "Diff and Annotate" and select options you want.
Screenshot:
How can I browse the history of a chunk of a file, or the whole file if only that is possible, oven though the file was moved?
For example, file r/a/b.txt was moved to r/b.txt but had a history while in r/a,and I would like to see that history, if possible focused on a certain chunk/set of lines of the file.
You see the history of a file with
hg log --follow your-file
This will simply list the changesets that touch the given file. You can add --patch if you want to see the patches along with the log messages.
I don't know of a tool that can focus on a particular hunk. The closest is the annotate command. I always use it from TortoiseHg (works on all Windows, Mac, and Linux) which allows you to right-click on a given line and annotate the parent changeset of the changeset that touched the line. That makes it really convenient to "peel off" layers of history in the file.
When I create a new repository, I can ask TortoiseHG to give me a .hgignore file. Is there a way that I can customise what that file will look like, rather than having to go and get one manually from somewhere every time?
It's an old question, put still popped up as the first result on google, so here is an update:
In the TortoiseHg settings under the tab TortoiseHg users can specify the path of a Repo Skeleton. You can put your predefined .hgignore there, and it will be automatically copied during hg init.
See also:
#3569 Allow user-defined default .hgignore file when creating a new repository
TortoiseHG Docs
Like Tim already said in his comment, apparently it's not possible to do this.
Take a look at the following issue from TortoiseHG's bug tracker:
#966 Include some reasonable defaults in .hgignore on repo creation
Quotes from this link, both by Steve Borho (THG project lead):
This topic comes up on the Mercurial mailing list once a year or so and Matt always shoots it down. There is already support for user level ignore files; one could add these globs to a global file and be done with it.
and:
If a user has files or directories that they always want to ignore, they can add those to a global ignore file without having to introduce any new behaviors in THG.
So putting the things you always want ignored in a user-global ignore file seems to be the only option (even though it's not exactly what you're asking for):
Would like to create some defaults for my .hgignore files in TortoiseHG/Mercurial
(the question that I posted in my comment above)
Global hgignore usage