One thing this project does really well is to start the readme with a screenshot. I open the link, scroll down to the readme, and I immediately see what sort of user interface/experience I will get. Some commenters have noted that Gita is similar to other multi-repo tools, but both Repo and wstool are more effort to evaluate, because their readmes don't have pictures.
Nice, but is there a way to just run any command? I.e. just `gita <optional repo names/paths> <pass entire command line git -C repodir>`. This has advantages in that you don't have to go round via a command file, don't have to keep it synced across machines, don't have to remember what you put in the file etc, and can just use the git syntax which already took long enough to learn by heart :P
I've used multiple multiple repository tools and in the end all I happen to use is one (usually versioned) file to store a list of repositories and then a command which just loops over all repos and applies anything to it. If I need custom commands I use git aliases so that works both for normal git and whatever tool used.
→ cat ~/bin/git-all
#!/bin/bash
# Exit on error. Append "|| true" if you expect an error.
set -o errexit
# Exit on error inside any functions or subshells.
set -o errtrace
# Do not allow use of undefined vars. Use ${VAR:-} to use an undefined VAR
set -o nounset
# Catch the error in case command1 fails (but command2 succeeds) in `command1 |command2`
set -o pipefail
# Turn on traces, useful while debugging but commented out by default
# set -o xtrace
help() {
cat <<EOF
usage: git all <any-git-command>
Runs the git command for all repositories in the current directory.
Examples:
What just happened?
git all log -1 --oneline
What am I doing now?
git all status --short --branch
What is everything I'm working on?
git all branch -vv
EOF
}
banner() {
echo -e "\\033[1m=== $1 ===\\033[0m"
}
main() {
if (( $# < 1 )); then
help
exit 1
fi
folders=$(find . -maxdepth 2 -name .git -print0 | xargs -0 -n1 dirname)
for folder in $folders;
do
banner "$folder"
git -C "$folder" "$@" || true
done
}
main "$@"
This is an interesting idea. I never thought about it before. My previous thinking is that if something really complex needs to be done, then I will go to that directory.
Another similar tool is myrepos (it supports other VCSen too). There are several other similar tools, see the related software section of the myrepos website:
I wrote a similar tool (along with some other git helpers) a while ago: https://github.com/tkrajina/git-plus. Note that there is another (more popular) git-plus repository used in Atom. My own has nothing to do with it (but it's older).
The biggest problem with multiple repositories is to manage consistent versions (commits).
For example, let's say that I have a release 1.0, which consists of a bunch of commit IDs of various repositories. How do I go back to that release without manually checking out the specific commit ID in each repo?
We use tags for that. Upon each release all repos get the same tag. Alternatively with tools like mr [1] you can for each release keep a .mrconfig somewhere which keeps the commit SHA for each repo (not 100% sure if mr can create such file by itself, but it's not really hard) so that if you do a fresh clone it checks out each repo at the correct commit.
I hate to say it but because I don't feel comfortable with git enough whenever I am about to do anything outside of my comfort zone I make a hard copy of my whole directory just to be sure if I get myself into a FUBAR state I can delete the FUBAR'd directory and copy it again. This has saved me many a headache. Also gives me a fresh state from which to ask for help from. Anytime the word rebase is mentioned my coworkers shriek.
Have you ever had a look at the combination of 'git reflog' and 'git reset --hard <ident>'? You can find the point before you did the uncomfortable operation and restore your state to exactly then. Saves having to make that backup copy (which, again, can be slow for a big repo).
Most of what I do is handled by my tooling for me. It's when I have to do more than just the basics that UI tools somewhat fall short. I prefer the UI that JetBrains IDE's give because I can see visually what I am about to commit. I've made a lot less mistakes than my colleagues who either don't pay attention to the UI or swear by the command line but still miss simple things quite often, the worse I do is a typo here or there which a command line approach would of never saved me from either.
To be fair I don't even remember anymore when I've had to do anything extensive, it's been quite a while. I'm even able to handle merge conflicts right away from within my editor.
Did you just call git a fad? The vast majority of software in version control is in git, including some of the largest and most important open source projects.
Evidence of widespread adoption is not evidence that something is not a fad. It might even be the evidence that it is a fad.
Faddishness is in the process of adoption. Why is the vast majority of software using git? Is it really the most suitable for their use case? Is it really the most usable, given the notoriously poor orthogonality of the CLI? Or is the adoption driven by adoption of github and git as the new "default"?
I don't follow, what's the specific advantage here? And just for context, we use both git and a cvs (yes, it's still going!) at day job. Both are pretty slow.
Since a centralised system doesn't carry all the history with every checkout, the checkouts are smaller and there's less risk of running out of SSD space with a large monorepo. It's also quicker to make a new one. svn/p4 will let you checkout a subtree of a "monorepo". p4 in particular is pretty fast, although as a closed source CASE tool its days must be numbered.
(re: carrying all the history, I used to work somewhere where they checked the build artefacts in to svn on every release build. A naive "git svn" import was in the 10s of gigabytes.)
We don't have space issues on our machines but you are right, you don't need multiple copies of the entire history and that's why I suggested the worktree feature.
