I use kdiff3 on Windows as the visual merge tool for TortoiseHG / Mercurial.
Often when doing a merge or rebase it will show a dialog like this:
Another variation is that the two files being merged were "binary equal".
Since these messages are basically saying that there is no conflicts / nothing to do, I'd like to suppress them - is that possible?
I don't see anything pertinent in the kdiff3 command line options.
Although having a bit misleading name, --auto option does what you want.
From the documentation:
--auto No GUI if all conflicts are auto-solvable. (Needs -o file)
This help text can also be accessing from the command line with kdiff3 --help.
I want to squash images using tools like imageoptim-cli on MacOS from git history to shrink repo size. Can BFG support running some more arbitrary commands? My git filter-branch looked something like this: https://gist.github.com/zbeekman/7482ccd0e87f495387951bd612dc390e
git filter-branch --prune-empty --tree-filter 'pwd ; ls -a ; imageoptim -a -q --verbose -d <path/to/img/dir/here> || true' -- --all
But this ran the image tools on those files every commit, even after they had been introduced.
BFG doesn't currently support running arbitrary commands on commits, trees or blobs it encounters. There are a couple of PRs and issues that request this, notably #169 and #165, so you may be able to fashion something from those efforts, or collaborate there.
I am just getting into using Mercurial and I saw that someone was using the command
hg pull - - update -vvv
what does -vvv mean?
Thanks
Not 100% certain (-vvv isn't a standard switch in Mercurial), but -v on its own makes the output verbose. When performing a verbose pull-with-update (hg pull --update -v), this outputs a tad more information, primarily which files are being updated, etc.
Running your command (using -vvv) has the same effect as -v, so Mercurial is treating it as a verbose switch. The output certainly doesn't come out more verbose.
My guess is that the person in question has a stuck key :)
Im looking for a convenient way to sort the ouput of
hg status
to see the newest file at top.
Here is a possible solution that will only work in Linux-like environments (I am trying it in Windows using MSYS). You could use ls to list files sorted by time, passing it the output of hg status:
$ hg st
M modified.txt
A added.txt
R removed.txt
? unknown.txt
$ ls -t1 `hg st -n -a -m -u`
unknown.txt
modified.txt
added.txt
Using this method you lose the MAR?... status, but it shows the files that are changed, added, or are untracked, sorted by modification time. However, it does kind of rely on your allowed parameters to ls.
Effectively you're using the backquoted mercurial command to provide a list of filenames to ls, which will do the sorting for you. Don't think there's a simple way to do this in vanilla Windows. Possibly by using a for loop?
First, create a file with this content:
changeset = "{files}"
file = "{file}\n"
Let's say you call it sorted.txt and put it in your home directory. Then you can give this command:
hg -q outgoing --style ~/sorted.txt | sort -u
I often notice a few unwanted changes when I review my working copy (with hg status and hg diff) right before a commit. For example, I might have temporarily added or remove some code just for the duration of a debugging session.
I know I can use hg revert to remove unwanted changes, but this removes all the changes in the entire file. Is there a way to revert just a part of a file?
I'm not sure if you can revert individual lines explicitly, but what I do in situation like yours is to commit the good code and revert the rest (the bad code). This workflow is easy using Mercurial's record or crecord extension (I recommend the latter one).
I've been doing this with the interactive ncurses style ui hg revert -i that lets you walk around and select the parts you want to destroy, either file, diff chunk or line by line, as you please, depending on how deep you unfold your changes.
I am not sure if this is a standard hg feature or not, you can verify easily enough if yours has it:
> hg revert --help --verbose | grep -- -interactive
-i --interactive interactively select the changes (EXPERIMENTAL)
Just remember that the changes you mark (X) will be what gets nuked, not what you retain.
Assuming you have the record and shelve extensions enabled, you can do as follows:
hg record -m "garbage" # pick out and commit the change you want to revert
hg shelve --all # temporarily hide other changes
hg strip tip # remove the garbage changeset
hg unshelve # restore the changes you want to keep
One way is using a graphical diff tool like kdiff3. If you feed it the diff and choose "merge current file" you can go line by line and pick what you want.
The better way is to commit more often. If you make a habit to commit right before adding debugging code, then either commit or revert your debug code before adding your "real" code, it makes it very easy to remove your debug code because it has its own revision. Alternately, you can put your debugging code in a separate branch altogether.
The TortoiseHg GUI's "Commit" window has a "Hunk Selection" tab that allows selection of specific sections of a file's changes to be committed.
I've got a different answer for your problem, which is the same problem I have. This is a great use case for mercurial queues!
When I am about to start adding debugging code to a change that I think is ready, I do the following:
hg qnew -m "fix for bug #123" fix.patch # basically a local-only commit
hg qnew -m "debugging" dbg.patch # prepare the next changeset at the tip
[add my debugging]
hg qrefresh # update the changeset at the tip
[...]
hg qpop # pop the debugging off the repo history
It takes a little bit of getting used to -- you end up having to reorder your patches to then fold whatever fixes you made into the original work patch.
Also, check out Bill Barry's attic extension. This page talks about how to use it for a few different workflows and how that compares to using mq. https://www.mercurial-scm.org/wiki/AtticExtension
If the commit where you want the change is e.g. ba1c841aaff4,
the easiest is to use:
hg meld -r ba1c841aaff4^ <filename>
Now click on a right arrow (pointing to the right) in the middle to revert your lines, save the file and close meld. kdiff3 (old and unintuitive) can be an alternative.
Side note: in order to use meld you need to configure it in our ~/.hgrc file:
[extdiff]
cmd.meld =
[merge-tools]
meld.args=$base $local $other
Download and install meld https://meldmerge.org/
(You should have Mercurial installed locally or TortoiseHg)
Launch Meld and select Version Control View and then select you will be asked to choose a parent directory of the file you want to modify.
Select the file which has the uncommitted changes
Choose which lines you want to revert to the last commit by selecting the arrow. The document on the left is from the last commit and the right document is the file with the uncommitted changes.