I often find myself typing
git add -u
with the intention of adding everything that is modified but tracked in the whole repository. However, it gets annoying and tedious when I'm in a subdirectory. For example if all my modifications are in src/ but I'm currently in the test/util directory, then I need to type
git add -u ../..
which is error-prone and slow (because I need to compute the number of ../ in my head).
I would like to create a git alias au such that it automatically detects the toplevel (usually, the first ancestor directory in the path that contains the .git directory). It doesn't have to be perfectly portable, since I use git from bash. Any ideas?
No need to detect the top-level.
You can type in any subfolder:
git add -u :/
This is short for:
git add -u :(top)
See git glossary:
A pathspec that begins with a colon : has special meaning. In the short form, the leading colon : is followed by zero or more "magic signature" letters (which optionally is terminated by another colon :), and the remainder is the pattern to match against the path.
top: The magic word top (magic signature: /) makes the pattern match from the root of the working tree, even when you are running the command from inside a subdirectory.
Related
Question title is pretty much the question. Here's a look at what I get:
I am trying to export a mercurial repository to git, but to a different directory. hg gexport works just fine without the --cwd parameter, but I don't want that -- I want to change the working directory to another one, but strangely, it says unknown command when I use that command line switch.
Any ideas?
Real hgexport is not native hg command, it's part of hggit extension
According to wiki, this part ("Using hg-git to interact with a hg repository with git") is outdated and may not reflect current state of extension
>hg gexport --cwd $PATH work in my own tests without errors (so-so, see below) with command-line expanded accordingly to requirements
hg gexport --cwd i:\Work\Personal!whyhq\ -R i:\Work\Personal!whyhq\site
without -R gexport will not find source hg-repo after cdto target location
And last, but not least: even properly used, hgexport in current hggit
hg id
15457fc67631 0.8.13
do nothing (nothing changed on target). I suppose, for getting git-repo from hg you have to use trivial hg push <git-URL> today (yes, it work, with minimal tricks on your side: branch_bookmark_suffix = $STRING in .hgrc)
Side note
If you have hggit extension enabled (globally or per-repository) hg-repo is mirrored automagically into bare git-repo (at least it seems so) in .hg/git directory, you can just copy&rename it
Let's say I have this alias defined in mercurial config:
pushb = push -B `cat .hg/bookmarks.current`
How can I view what command will be called after all substitutions apllied?
Example:
My .hg/bookmarks.current file contains some_bookmark text. How can I view that when I call hg pushb it'll actually call hg push -B some_bookmark?
When you use -B <bookmark> in push and this local bookmark exist, you can see
pushing to ...
searching for changes
...
exporting bookmark <bookmark>
in push output in case of correct expansion or
bookmark <bookmark> does not exist on the local or remote repository!
in latest string in case of problem and getting bad name. Anyway, your can see resulted bookmark's name in both cases
We have a sub-repository in mercurial that was created using hg convert. For about three weeks we've had people modifying and checking in changes (using Tortoise under Windows) before we noticed that we have two versions of the originally converted files:
e.g.
Dir\Project/FileName.ext
Dir/Project/FileName.ext
I've tried hg rename, hg forget, hg remove, but when we always seem to end up with both files gone, or both files present. I've also looked at the case folding suggestions, but they don't appear to apply.
Any suggestions on fixing would be appreciated. If we lose the history on the \ version that would not be the end of the world.
Thanks
I've seen this happen with converted SVN repositories (using hgsubversion but I bet hg convert has the same issue). In the cases I've seen it there was an svn properties change for the path which apparently resulted in a "filename containing backslashes" (not path) being stored in svn.
In the first case I saw it was a directory path which caused me to immediately encounter the problem - a zero-length file was created with the directory path on Windows, and then later in the update Mercurial aborted because it was unable to create the directory of the same name.
I expect the sequence that created the double entries is something like:
Update to revision which contains filepath with backslashes
The new file shows as untracked because the Mercurial manifest currently contains a path with backslashes, but when looking at the working dir it normalises all file paths to forward slashes - so it doesn't appear in the manifest.
User adds the "new" file.
On subsequent updates, both paths are updated but one overwrites the other in the working directory. If you've been lucky the new version is the one that's ended up in the working dir.
You probably can't fix this on Windows but you should be able to remove the backslash versions on Linux (or other UNIX-like OS with case-sensitive filesystem) by single-quoting the filename e.g. hg rm 'Dir\Project\FileName.ext'. If you update to a revision with the problem on Linux you should see files actually named 'Dir\Project\FileName.ext' in the root of the working directory.
Just make sure that the backslash version is the one that should be removed - if not you may need to manually merge them together to get the result you want.
I have configured hg log in ~/.hgrc to only list commits from the current branch by default:
[defaults]
log = --branch .
However, occasionally I'd like to really see commits from all branches. Is there a way to tell hg log when invoked form the command line to not use the configured defaults but fall back to the built-in behavior? As a brute-force solution ignoring ~/.hgrc altogether for this particular invocation of hg log would be fine for me.
I'm aware that defaults are deprecated in favor of aliases, but aliases cannot be created with the same names as existing commands, which is what I want in order to not have to learn new command names, esp. when ~/.hgrc settings are to be shared by multiple developers.
Edit: Not being able to create aliases with the same names as existing commands was a regression that has been fixed.
You should be able to use --config to override the setting in your .hgrc:
hg --config defaults.log= log
From the man page:
--config set/override config option (use 'section.name=value')
I have gone through the bug reports on the Mercurial website and cannot find any workarounds for this, the response being a blanket "this is deprecated".
Personally, not learning the commands to me is not a valid reason for not migrating away from default command values. A possible alternative would be to move away from per-repository settings and have some settings at the user level, so you can set your own defaults / aliases.
Defaults are now deprecated, so you should likely remove this and specify the arguments each time. Confirmed in the documentation:
https://www.mercurial-scm.org/wiki/Defaults
(defaults are deprecated. Don't use them. Use aliases instead)
Try:
[alias]
blog = log --branch
Usage:
hg blog <branch name>
hg blog default
I know I'm resurrecting an old question here, but this statement
aliases cannot be created with the same names as existing commands
is incorrect.
In your .hgrc file in the [alias] section, you can, for example, have:
[alias]
add = add --dry-run
This will make the add command always do a dry-run, instead of actually recursively adding all unknown files in the repository.
It seems the best solution to my use-case indeed it to temporarily ignore the ~/.hgrc file altogether. This can be done by setting HGRCPATH to an empty string, which causes Mercurial to only read the .hg/hgrc file from the current repository:
HGRCPATH="" hg log
I'm working in a project
I used to do things like:
hg grep TODO
to find stuff that needs fixing for example.
But now I have included source code from other projects and
hg grep TODO becomes useless because of the existence of TODO's in the added source code projects which is not mine. Now I can add an parameter --exclude=frameworks to the command but
typing that each time is annoying...
The alias section of hgrc is suited for this. You could add this to your local .hgrc or if this is relevant for just this repository, to your .hg/hgrc:
[alias]
xgrep = grep --exclude=frameworks
A workaround is adding an alias in your shell's configuration file (for example ~/.bashrc) or profile (~/.profile):
alias hg-grep="hg grep --exclude=frameworks"
type . ~/.bashrc or just start a new shell to have the setting in effect. You'll get the behavior you want with hg-grep TODO, but can still use the original with hg grep TODO.