This one’s simple. Just disable the GUI and solve two problems at once. ./configure --without-tcltk \ --prefix=$HOME/Environment/local \ && make && make install
In contrast to the simple single-line nicely-behaved “git submodule add” command, removing a submodule requires you to: $ git submodule deinit -- path/to/submodule $ rm -rf .git/modules/path/to/submodule $ git rm -f path/to/submodule $ git commit -a -m "Remove submodule" Apart from the multiple steps with “rm -rf freely being tossed around willy-nilly, note the second command where you manually fiddle with the guts of the repository structure. That does not get propagated up to any remotes in a push or any repos that pull from you or a shared remote.
One of the great strengths of Git is the multiple and flexible ways of handling remote repositories. Just like Subversion, they can be “served” out of a location, but more generally, if you can reach it from your computer through any number of ways (ssh, etc.), you can git it. YonderGit wraps up a number of a common operations with remote repositories: creating, initializing, adding to (associating with) the local repository, removing, etc.
Git offers two ways of viewing differences between commits, or between commits and your working tree: diff and difftool. The first of these, by default, dumps the results to the standard output. This mode of presentation is great for quick summaries of small sets of changes, but is a little cumbersome if there are a large number of changes between the two commits being compared and/or you want to closely examine the changes, browsing back-and-forth between different files/lines, search for specific text, fold away or hide non-changed lines etc.
Merge conflicts suck. It is not uncommon, however, that you often just know that you really just want to accept all the changes from the branch that you are merging in. Which makes things a lot simpler conceptually. The Git documentation suggests that this can also be procedurally simple as well, as it mentions the “-s theirs” merge strategy which does just that, i.e., unconditionally accept everything from the branch that you are merging in:
When you pull and update your local, it would be nice to easily see all the commits that you have applied in the pull. Sure you can figure it by scanning through the git log carefully, but adding the following to your ‘~/.gitconfig’ gives you an easy way to see it in a glance: whatsnewlog = !"sh -c "git log --graph --pretty=format:'%Creset%C(red bold)[%ad] %C(blue bold)%h%C(magenta bold)%d %Creset%s %C(green bold)(%an)%Creset' --abbrev-commit --date=short $(git symbolic-ref HEAD 2> /dev/null | cut -b 12-)@.
To search content of all tracked files in the current working tree for a pattern: git grep To search content of all commit messages for a pattern (‘-E’ for extended grep): git log [-E] --grep To search content of all commit diffs for lines that add or remove a pattern (‘-w’ for pattern only at word boundary): git [-w] log -G To search content of entire working trees of previous revisions for a pattern:
The following will enable you to have a Git-aware “cd” command with directory path expansion/auto-completion relative to the repository root. You will have to source it into your “~/.bashrc” file, after which invoking “gcd” from the shell will allow you specify directory paths relative to the root of your Git repository no matter where you are within the working tree. gcd() _gcd() " prev="$$2" dirnames=$(cd $TARGET; compgen -o dirnames $2) opts=$(for i in $dirnames; do if [[ $i !
With multiple upstream repositories and branches, and different branches on different upstreams, an enhanced “log” view will help greatly in taking stock of everything. Adding the following line to your “~/.gitconfig” will give you a new command, “git slog” (for “short log”) that does just that: < p> # colorful 1-line log summary slog = log --pretty=format:'%Creset%C(red bold)[%ad] %C(blue bold)%h %Creset%C(magenta bold)%d %Creset%s %C(green bold)(%an)%Creset' --abbrev-commit --date=short This command will provide a colorful one-line summary of the project’s commit history, showing not only the commit date, SHA-1, commit message and author, but, most importantly in this context, an indication of the symbolic references associated with various commits in nice, bright [magenta].