#git bot interface

Active triggers

Click on one of the triggers to get its edit history. Global list of recent changes

!3rdparty (aliases: !third)
Your question is about a third-party tool or service, not a core `git` component. It is OK to ask, but replies are not guaranteed
I only respond to !ping
Git is not an acronym, nor a proper noun ("git" is equally valid). All-caps is heresy and will be punished with SVN or possibly SCCS. https://git.wiki.kernel.org/index.php/Git_FAQ#Why_the_.27Git.27_name.3F and 48a8c26c625a4d3631c4f614bceb38933e741408
!HEAD (aliases: !head)
HEAD is a 'pointer' to the currently checked out branch (or commit, if HEAD is !detached). In bare repositories it tells clients which branch to checkout initially after cloning. Unlike commonly believed, HEAD is *not* something that exists separately for every branch. It also is *not* necessarily the newest commit in the repo (that's hard to define in a DVCS, anyway...)
!IntroToGit (aliases: !introduction)
Randal Schwartz has an introduction to git video http://vimeo.com/35778382 and slides http://www.slideshare.net/RandalSchwartz/introduction-to-git-11451326
!SIGPIPE (aliases: !sigpipe)
Hooks that are specified to receive a list of things on stdin, in particular {pre,post}-receive, MUST read their entire input. (If you do not need it, 'cat >/dev/null' to discard it.) Otherwise, the git process that writes to it may randomly die due to SIGPIPE. This is very hard to diagnose if you haven't seen it before.
!UGFWIINI (aliases: !not_intended, !ugfwiini)
You appear to be Using Git For What It Is Not Intended - https://www.google.com/search?q=UGFWIINI Are you sure git is the right tool for the job? See also !wrong
You can set up alias to be used by git, see: http://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
Use `git commit --amend` to combine your current staged changes with those in the previous commit. If you have already pushed the last commit, this counts as a !rewrite
!annex (aliases: !lfs, !media)
git-annex, git-media, and Git LFS are some solutions to the !binary problem. They work by keeping the blobs outside of the repo, storing a reference to the blob in the repo instead. http://git-annex.branchable.com https://github.com/alebedev/git-media http://git.io/git-lfs
Usually, it does not help to ask for someone specific to help you. Without knowing your specific problem, nobody knows if they can be of assistance. Please ask your question and wait until somebody speaks up.
Please see http://www.catb.org/esr/faqs/smart-questions.html#urgent
Yes, it's okay to ask questions here.... in fact, you just asked one! ;-) Pretty much any question is fine. We're not terribly picky, but we might be asleep. Please be patient and you should get an answer soon.
git update-index --assume-unchanged is sometimes suggested for keeping yourself from committing changes to a file, but it's actually a promise to Git that the file is identical to the committed version, to reduce unnecessary disk reads. Not only will Git feel free to discard the flag, it will also happily overwrite your changes whenever a checkout/merge/rebase/... updates it.
@ is a shortcut for !HEAD
Use this to atomically switch deployments: http://rcrowley.org/2010/01/06/things-unix-can-do-atomically.html
!backup (aliases: !backups)
Worried about your data while trying stuff out in your repo? The repository in its entirety lives inside the .git directory in the root of your work tree so to backup everything `cp -a path/to/workdir path/to/backup` or equivalent will suffice as long as the repo is not modified during backup. See also http://sethrobertson.github.io/GitBestPractices/#backups
!bare (aliases: !non-bare, !non_bare, !nonbare)
A bare repository is used to push/fetch (useful for running a git server), and contains only the contents of .git/ from a "normal" repo. Read more: http://bare-vs-nonbare.gitrecipes.de/
!bazaar (aliases: !bzr)
Bazaar is a competitor to Git: http://bazaar.canonical.com/en/ -- want to use Bazaar repositories in Git? http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
Bear repos are very dangerous. Approach with caution! https://youtu.be/DvduCPXO_FE
!beer (aliases: !wine)
Beer! It's what's for dinner!
!best_practices (aliases: !bestpractices)
There is no one right answer for git best practices, but a consensus from #git is available at http://sethrobertson.github.io/GitBestPractices/
!bestway (aliases: !best_way)
You want to know the best way to do X? If you can give us a proper definition of "best", we'll give you a proper way to do X ;)
!bfg (aliases: !BFG)
A tool designed to remove large files, or passwords from history: https://rtyley.github.io/bfg-repo-cleaner/ (!rewrite applies)
!binary (aliases: !balloon)
Storing binary files in git causes repo balloon, because they do not compress/diff well. In other words, each time you change a file the repo will grow by the size of the file. See !annex for some solutions
Bitbucket is a code-hosting site for both public and private repos similar to GitHub (except that Bitbucket offers private repos for free). See https://bitbucket.org/.
!blog (aliases: !answer, !blag, !blogs)
Blog or Answer posts(like StackOverflow), while helpful and informative, are quite often outdated, give bad advice, or are just plain wrong. Please don't rely solely upon them, or treat them as authoritative. We recommend reading the documentation and consulting multiple sources, such as the expert advice to be found on IRC
!book (aliases: !books, !progit)
There are several good books available about git; 'Pro Git' is probably the best: https://git-scm.com/book (free web version and downloads) but also look at !bottomup !cs !gcs !designers !gitt !vcbe and !parable
I can't answer that with a bot command, could you please rephrase the question?
!botsnack (aliases: !bacon, !cake, !nom)
Om nom nom
'Git from the bottom up' starts with explaining the building blocks of git and proceeds to tell you how they fit together. https://jwiegley.github.io/git-from-the-bottom-up/
A branch and a tag are just convenient ways of spelling the name of a particular commit. A commit represents a specific set of files and the history of all commits which came before it, and the SHA-1 hash tag official name provides cryptographic assurance of the lineage of a particular commit (and thus branch or tag). A branch's reference may change. A tag usually doesn't.
!branch_delete (aliases: !delete_branch)
Deleting a branch is easy. `git branch -d branchname` (or -D). However, this will NOT delete the branch upstream, that requires `git push --delete origin branchname`. However, this will NOT delete remote tracking branches. EACH USER must `git remote prune origin`, but if any users have local branches, they must likewise run `git branch -d branchname` (or -D)
Renaming a branch is easy. `git branch oldname newname`, but this only renames it locally. If you want to rename it globally, you need to `git push origin newname; git push --delete origin oldname` and then users need to `git remote prune origin` and then rename their local branches. Do NOT do this in an attempt to, say, fix a problem on oldname, that is !rewriting_public_history.
To replace one branch with the contents of another: git clean -dfx; git checkout $destination; git reset --hard $source; git reset --soft ORIG_HEAD; git add -Af .; git commit -m "Rewrite $destination with $source"; git merge -s ours $source
So you want to break some auto-magic that GitHub does (!gfm) to your comments (like @user, #issue, user/repo, :emoji:)? You can use a zero-width space to do that: insert ​ somewhere into the sequence. See also http://en.wikipedia.org/wiki/Zero-width_space
!brsgc (aliases: !brscg)
Please direct your bug reports to support@github.com or http://github.com/contact
the developers of git don't use a bug tracker. If you want to report a bug, send an e-mail to the mailing list at git@vger.kernel.org (no subscription required; everyone uses "reply to all" when responding); you can review past discussions at http://public-inbox.org/git
Bundles are packfiles containing commits and associated data that you can use to transfer Git history manually. For more information, see the 'git-bundle' manpage: https://gitirc.eu/git-bundle.html
https://bundler.caurea.org/ will create a bundle of a repository that you can download using resumable transfer mechanisms, and then clone. This helps with slow or broken networks.
"Highly efficient file backup system based on the git packfile format. Capable of doing *fast* incremental backups of virtual machine images." https://github.com/bup/bup
There are several causes preventing you to add file changes. 1. Line endings (see !crlf) 2. case insensitive file systems (see !case) 3. clean/smudge filters that cause files to be different in the index (check for .gitattribute files).
!cant_happen (aliases: !impossible)
The scenario you describe does not add up, and/or we feel it is unlikely that there is such a fundamental bug that it could have happened like this. Please provide more detail: what commands (literally!) did you run, what did they say, and what did you expect instead?
capistrano is an application deployment tool in ruby, which has support for git, see http://github.com/capistrano/capistrano for more information
Git tries its best if you are on a filesystem which does not understand the difference between upper case and lower case, but there are many circumstances, especially when there are two files which only differ by case, that git just cannot cope. Windows and Mac users are especially likely to have such problems. Solution, move to a real filesystem or OS and investigate git-config's core.ignorecase
http://git.zx2c4.com/cgit/about/ web interface (cgi) for git repositories, written in C
!cheat (aliases: !cheat_sheet)
A few Git cheat sheets: http://cheat.errtheblog.com/s/git [textual], http://jan-krueger.net/development/git-cheat-sheet-extended-edition [textual-visual], http://wall-skills.com/2013/git-cheat-sheet/ [textual-visual]
checkout does two different things! (1) no file/path argument: 'git checkout <ref>' = switches to a branch or commit. Uncommitted changes are carried over; if they don't apply cleanly the whole operation rolls back. (2) 'git checkout [<commit>] -- <path>' = overwrites the given files/paths with different versions, from <commit> or (if not given) from the index.
Having trouble keeping all of the various forms of "git checkout" and "git reset" apart? Here's an overview: https://gitirc.eu/help/checkout-reset.html
For a pointer on how to handle history in git see this e-mail from Linus: http://thread.gmane.org/gmane.comp.video.dri.devel/34744
!clean_message (aliases: !clean_commit)
It helps to write clean commit messages. http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html explains how.
Gerrit is a code review tool for git. See http://code.google.com/p/gerrit/ You may want to enforce certain workflow to prevent people bypassing review. gitolite (and a branching workflow) or a integrator repository (distributed workflow) would be good for this.
Drink Earl Grey Tea. It’s better.
Bring some color to your life! git config --global color.ui auto
!commit_hooks (aliases: !disthooks)
It would be a huge security risk if git allowed you to commit hooks. You have to manually add them to the server. Third-party Git hosting sites (github, bitbucket...) usually don't allow custom hooks, you can only have them send HTTP POST requests to a custom URL to get notified of events. For client-side hooks, we recommend including them in the repo along with a script users can run to set them up.
SHA-1s are the primary way to refer to commit objects, but there are ways to make it more convenient: branches, tags, HEAD, FETCH_HEAD, git-describe thingies, stashes or things in the reflog, or taking one or more steps backwards in history with HEAD^ or HEAD~5
!compatibility (aliases: !compatible)
If you want your repo to be cross-platform compatible(eg Windows+Mac), it is recommended that you do not use symlinks or case-differentiated filenames(Readme.txt and README.txt). Also take care with setting files as executable.
!concepts (aliases: !gcs)
"Git Concepts Simplified" presents all the important structures in Git, step by step, including selected internal details so it becomes much easier to understand what's going on whenever something's going on. https://gitolite.com/gcs.html
!configfiles (aliases: !config_files, !configs)
It is recommended to store local configuration data in a file which is not tracked by git, but certain deployment scenarios(such as Heroku) may require otherwise. See https://gist.github.com/1423106 for some ideas
Without giving us more context, it's impossible to tell what's going on. Please provide details about what your situation is. (!repro)
Want to improve git? Everything you need to know is in http://git.io/SubmittingPatches. See !list for more on the mailing list
Git does not support copying (or moving) *files* between branches *with history*. It only merges entire branches. You can, however, copy over the *contents* of a file from another branch/commit using: git checkout <commit> -- <file>
!credential-cache (aliases: !credentials)
Tired of entering your username and password every time you access an HTTP(S) remote and have good reasons not to use SSH? A summary of shortcuts and supported caching methods can be found here: http://stackoverflow.com/a/5343146
!crlf (aliases: !line-endings)
To fix problems with line ending on different platforms, check out http://line-endings.gitrecipes.de/. Line ending normalization can be the cause of changed files that appear to not go away.
Note: The above question was posted in both #git and #github
!cs (aliases: !DAG, !dag)
"Git for Computer Scientists" is a quick introduction to git internals for people who are not scared by phrases like Directed Acyclic Graph. http://eagain.net/articles/git-for-computer-scientists/ See also !concepts !bottomup
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2cde51fbd0f3 and https://marc.info/?l=linux-kernel&m=139033182525831
!cthulu (aliases: !cthulhu)
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2cde51fbd0f3 and https://marc.info/?l=linux-kernel&m=139033182525831
You can create custom git subcommands (e.g., `git foo`) in two ways: man git-config and see alias.*, or place a script/binary in $PATH or $GIT_EXEC_PATH (~/bin/ is a good candidate) named "git-foo". The `git` wrapper will find these and execute as-needed.
Dangling objects represent things added to git which are no longer needed based on the git commands you typed in. This can be normal workflow (rebase, reset, add, etc) or errors you made. Typing "!dangling_commit" "!dangling_blob" and "!dangling_tree" into a query to me will get you more information about each type.
A dangling blob is a file which was not attached to a commit. This is often caused by `git add`s which were superceded before commit or merge conflicts. Inspect these files with `git show SHA`
A dangling commit is a commit no longer reachable by any branch or tag. This can happen due to resets and rebases and are normal. `git show SHA` will let you inspect them. Also this (look for dots w/o children and w/o green label): gitk --all --date-order `git fsck --no-reflog | grep "dangling commit" | awk '{print $3;}'`
A dangling tree is a directory tree of files that was not attached to a commit. These are rarely interesting, and often caused by merge conflicts. Inspect these files with `git ls-tree -r SHA`
!dashes (aliases: !--)
Use a double-dash(--) to separate refs or arguments from file paths. This is especially useful when dealing with ambiguous names. Ex: `git checkout origin -- master` will check out the file "master" from branch "origin"
Changing database schemas is a very complicated topic. Some reading: http://thedailywtf.com/Articles/Database-Changes-Done-Right.aspx
!deploy (aliases: !deployment, !website)
Git is not a deployment tool, but you can build one around it (in simple environments) or use it as an object store(for complex ones). Here are some options/ideas to get you started: http://gitolite.com/deploy.html
'Git for Web Designers' is a quick "Who why what when how" on VCS and git: http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/
The operation/command sequence just mentioned will destroy uncommitted changes. Please apply caution.
!detached (aliases: !detached_head, !headless, !no_branch)
A detached HEAD (aka "no branch") occurs when your HEAD does not point at a branch. New commits will NOT be added to any branch, and can easily be !lost. This can happen if you a) check out a tag, remote tracking branch, or SHA; or b) if you are in a submodule; or you are in the middle of a c) am or d) rebase that is stuck/conflicted. See !reattach
this channel is for discussions about git development only. If you have questions about using git, please visit #git instead. Thanks!
"git diff": show unstaged changes. "git diff --cached": show staged changes. "git diff HEAD": show all uncommitted changes.
If you use to resolve merge conflicts by editor using <<< === >>> markers, you may want to set diff3 option to show merge base using additional ||| marker (git config --global merge.conflictstyle diff3). See http://psung.blogspot.com/2011/02/reducing-merge-headaches-git-meets.html
!directory (aliases: !dirs, !empty, !empty_dir)
Git does not track directories, only files in directories. Create a nonce file as a placeholder (eg .gitignore) to create the directory or create the directory as part of a post-checkout hook
!disclaimer (aliases: !unsafe)
This is a possibly unsafe operation that in some cases cannot be undone, use at your own risk. See also !backup
!doc (aliases: !docs)
A list of useful documentation of all kinds is here: http://git-scm.com/documentation -- or try the wiki at http://git.wiki.kernel.org/. Also try typing "!book" "!cs" "!bottomup" "!parable" "!best_practices" or "!vcbe" or "!designers" here in IRC. !book is probably the most helpful.
For complete git documentation, please consult http://git-man-page-generator.lokaltog.net/
!doesntwork (aliases: !broken, !doesnotwork, !doesnt_work, !work, !working, !worst_prob_desc)
Sorry to hear it doesn't work, but how about some details? At this point we don't even know whether it did nothing, spit out an error message, or abducted your pet unicorn in a flying saucer. That makes it hard to troubleshoot – unicorn abduction requires a completely different solution than an error message, for instance. So, please be specific...
!dont_summarize (aliases: !summarize, !summary)
Please do not summarize what you did; !pastebin _exactly_ what commands you ran, what the output was, and why you think that this is wrong. Otherwise you may hide the real issue. See also !obfuscate and !repro
A single dot(eg, git checkout $SHA .) refers to "the current directory" and all files/folders within
There are various issues associated with keeping dot-files in git (permissions, avoiding having a .git in ~/ or /). One attempt to manage this is http://dotfiles.github.io/ and there is a wiki about it here: http://vcs-home.branchable.com
!dots (aliases: !.., !..., !dotdot, !dotdotdot, !ranges)
A..B = stuff that happened between A and B (if A and B are related; otherwise refer to "man gitrevisions"), A...B = (a) in history viewers: stuff that isn't in both A and B yet; (b) in "git diff": stuff that happened in B since the two diverged; (c) in "git checkout": the merge base of A and B. "master.." is the same as "master..HEAD" and "..master" is the same as "HEAD..master", and so forth.
Use git-remote-dropbox instead of placing your repository directly in the "Dropbox folder", or you'll get sync errors (and eventually, a corrupted repo). https://github.com/anishathalye/git-remote-dropbox
git uses a lot of frequently-changed small files, which dropbox's synchronization algorithms barf on. Use of multiple dropbox clients compounds this, with hilarious results
you appear to be using the WebDAV-based HTTP transport mechanism for git. Please note that it's slow, inefficient and error-prone, and you should definitely consider using the SSH transport or the new CGI-based HTTP transport instead (man git-http-backend for details).
!eekaconflict (aliases: !conflict, !eekamerge, !panic)
Merge conflicts are a natural part of collaboration. When facing one, *don't panic*. Read "How to resolve conflicts" in man git-merge and http://git-scm.com/book/ch3-2.html#Basic-Merge-Conflicts then carefully go through the conflicts. Picking one side verbatim is not always the right choice! A nice video explaining merge conflicts: https://www.youtube.com/watch?v=zz7NuSCH6II
The enter key is not a punctuation mark. Please use fewer lines, with complete sentences on them.
!eol (aliases: !autocrlf)
The option/attribute to use when you need to care about different line-endings in your file: https://help.github.com/articles/dealing-with-line-endings/
etckeeper is a collection of tools to let /etc be stored in a git, mercurial, darcs, or bzr repository. It hooks into various package managers. http://etckeeper.branchable.com
What you describe _can_ be done, but results in an "evil merge": a commit that purports to be a merge, but does not actually take all changes from all sides. This violates the assumptions that tools and humans make about merges, and usually results in confusion and pain down the road.
We are what we repeatedly do. Excellence, then, is not an act, but a habit. (Aristotle)
!faulty_merge (aliases: !revert_merge)
If you have published a merge commit that turned out to be faulty and you'd like to get rid of it, you can use 'git revert' but there are gotchas to be aware of. Please read: https://raw.github.com/git/git/master/Documentation/howto/revert-a-faulty-merge.txt
Though I'm a bot, I have feelings too, you know.
When you work with remote repositories, Git stores copies of the remote's branches in !tracking_branches (basically mirrors). You can use 'git fetch' to update those. If you want to actually apply changes from the remote to your checked out branch, a second step is needed, usually 'git merge' or 'git rebase'. There's also 'git pull' which combines both steps.
[pre 1.8.4] The four-word version of git-fetch doesn't update remote-tracking branches and tags. It fetches into FETCH_HEAD only; you probably don't want to have to deal with that. Pull in four-word form automatically uses FETCH_HEAD, but your remote-tracking will still be outdated. Even updating them manually with 'git fetch origin master:remotes/origin/master' (clunky) still doesn't update tags.
The git protocol does not allow you to transfer objects by SHA; you must specify a ref to be pushed. Fetching arbitrary objects could lead to security issues(rewritten commits, private branches, etc) via a simple brute-force of "short SHAs".
!fetchfour (aliases: !fetch4, !pull4, !pullfour)
Before 1.8.4, 'git fetch/pull' with a remote AND branch argument tended to be confusing because they didn't update the remote-tracking branch (the thing shown by 'git branch -r'). If you're stuck with an old version, it's usually better to pass no arguments, or at least only a remote. Workaround example to fetch only the 'foo' branch: git fetch origin refs/heads/foo:refs/remotes/origin/foo
!ff (aliases: !fast_forward)
A fast-forward merge occurs when you merge a commit which is a descendant of !HEAD. No new commit is created, instead the branch is simply moved forward. See http://sandofsky.com/images/fast_forward.pdf
Cloning via a local filesystem path, including /home/user/foo, does not run most of the clone code, so won't detect many clone problems. You must try cloning via file:///home/user/foo. This behaves very differently from the local path. *Must*.
A third-party git add-on that can quickly rewrite git history. See https://github.com/newren/git-filter-repo.
You almost always want to use `--tag-name-filter cat -- --all` at the end of your `git filter-branch` command line to cause all normal refs to be rewritten.
You can use filter-branch to remove sensitive data from a repository's history. https://help.github.com/articles/remove-sensitive-data/
!filter_subdirectory (aliases: !split_repository)
You can use filter-branch's subdirectory filter to split a directory from an existing repository into a new repository, keeping all history. https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/
!filters (aliases: !smudge)
Filters can be very useful for automatically making changes to files at checkout(smudge) and checkin/add(clean). See 'man gitattributes' for more information
In the long run, it is much better to give pointers to answers than the answers themselves.
Got multiple system accounts writing to the same bare git repo? Use !gitolite OR: 1) Create common system group 2) chgrp recursively 3) find -type d -exec chmod 2775 '{}' +; find -type f -exec chmod 664 '{}' + 4) git config core.sharedRepository true
!fixup (aliases: !fixit, !oops, !undo)
So you lost or broke something or need to otherwise find, fix, or delete commits? Look at https://sukima.github.io/GitFixUm/ for full instructions, or !fixup_hints for the tl;dr. Warning: changing old commits will require you to !rewrite published history!
!fixup_hints (aliases: !fixit_hints)
Hints for fixing commits are: (1) NOT PUSHED/PUBLISHED: `git rebase -i $COMMIT^` or perhaps `git commit --amend` (or `git reset HEAD^`). (2) OTHERWISE, `git revert $COMMIT` to make a reverse commit. (3) If you have pushed and MUST remove it, use rebase or filter-branch and type !rewrite in IRC to learn about the implications.
!flexible (aliases: !layout)
git's status as a Distributed VCS really means that it is flexible - you can build any layout of repos you like to suit your !workflow. Here are some diagrams of common ones: http://git-scm.com/about/distributed
!float (aliases: !floated, !floating)
If you have made a change in your working directory and have NOT YET COMMITTED, you may "float" that change over to another (`git checkout existing_branch`) or new (`git checkout -b newbranch`) branch and commit it there. If the files you changed differ between branches, the checkout will fail. In that case, `git stash` then checkout, and `git stash apply` and go through normal conflict resolution.
Uncommitted changes and untracked files don't belong to any branch. This means that when you switch to a different branch, they are still there. (Don't worry, git won't let you switch branches if it would destroy uncommitted changes, unless you force it.) To keep something on one branch only, just commit it! You can always !fixup work-in-progress commits later.
!force_push (aliases: !push-f)
If you need to overwrite the history of a remote git repository (be carefull, see !rewrite), you can do so with `git push --force-with-lease`. Note that the remote server may reject this. See man git-config and search for receive.denyNonFastForwards. Best practice is for upstream servers to denyNonFastForwards.
I'm sorry that you are stupid, ugly, and not using git. Still, some misguided souls think that something other than git might be better for them. Who knows, it might even be true for you. In any case, we don't care. Good-bye.
Il y a un canal de discussion français sur #git-fr
Please direct all feature requests to support@github.com to make them heard (feel free to discuss them in here, but that's all off the record)
fugitive is a vim plugin that does magic with git, and can be downloaded from https://github.com/tpope/vim-fugitive
To secure funding for gitinfo development, we have partnered up with Quick Cash Grab Inc. who have lots of experience with maintaining and developing open source projects! Stay tuned for exciting new features!
Gerrit is a web-based code review system, built by Google. https://www.gerritcodereview.com/
GFM is short for GitHub Flavored Markdown, see https://help.github.com/articles/github-flavored-markdown and https://help.github.com/articles/writing-on-github
The GitHub compare view is at: https://github.com/$USER/$REPO/compare/$REV_A...$REV_B -- both $REV_{A,B} can be a branch, tag or SHA in $USER's repo or in the format $OWNER:$REF in the fork of $OWNER; replace slashes (/) in ref names with semicolon (;); append .diff or .patch to get plaintext. More info: http://git.io/j49x7A
Github has a few help articles on common operations for remotes (adding, changing URL, renaming, removing, etc): https://help.github.com/categories/18/articles
How to generate SSH keys and how to add them to your Github account: https://help.github.com/articles/generating-ssh-keys
If you're having trouble reaching Github (getting time-outs or error codes), please check http://status.github.com (and in case of time-outs also http://www.isup.me/github.com ); that will usually tell you more than asking here! (We would just have to look it up, too)
!gh-tarball (aliases: !gh-zipball, !gh_tarball)
To get the contents of a github repo, use https://github.com/USER/REPO/tarball/REF for a tarball or https://github.com/USER/REPO/zipball/REF for a ZIP file, where REF can be a branch, tag or commit hash
You can find some helpful GitHub-focused tutorial and demo videos at http://www.youtube.com/user/GitHubGuides/videos
!gh_protocols (aliases: !gh-protocols, !ghprotocols)
For a Github-specific comparison of Git transport protocols (git:// vs ssh:// vs https://), see https://gist.github.com/grawity/4392747
Welcome to #github, a place full of helpful gits. If you have a question, please just go ahead and ask -- and please give us some time to answer. For more info on this channel and #git, see https://gitirc.eu/. Take backups (type !backup to learn how) before taking advice.
Github's help SSH-related help articles can be found at: https://help.github.com/categories/56/articles
@/dev/null (The string '!git' often occurs in alias definitions discussed in the channel, so this trigger is reserved)
git-annex, git-media, and Git LFS are some solutions to the !binary problem. They work by keeping the blobs outside of the repo, storing a reference to the blob in the repo instead. http://git-annex.branchable.com https://github.com/alebedev/git-media http://git.io/git-lfs
https://github.com/seveas/git-spindle is a handy tool to use the features of GitHub (and GH Enterprise), GitLab, BitBucket and possibly more from the command line.
The git-stitch-repo tool allows for stitching several git repositories together as a unified history without merges, see https://metacpan.org/module/git-stitch-repo for more info.
!git-subtrac (aliases: !subtrac)
git-subtrac is a helper tool that makes it easier to keep track of your git submodule contents. It collects the entire contents of the entire history of all your submodules (recursively) into a separate git branch, which can be pushed, pulled, forked, and merged however you want. https://github.com/apenwarr/git-subtrac
git-subtree allows a subproject repository to be incorporated into a subdirectory of a main repository, and for the history of a subdirectory to be (re-)exported with reproducible results, making it possible to synchronise a repository with a subdirectory of another repo, see https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt for more info.
To see what the name git came from, look here: https://git.wiki.kernel.org/index.php/GitFaq#Why_the_.27Git.27_name.3F
A tool to find potential issues with repositories from github, See: https://blog.github.com/2018-03-05-measuring-the-many-sizes-of-a-git-repository/
Gitblit is an open-source, multiplatform Git server written in Java, available both as a standalone and as a WAR file to be ran in other Java web servers. Though it's very easy to set up, it offers many features such as a neat web UI, sophisticated authentication options including LDAP, Groovy script support, a GUI-based management tool and upcoming, WIP features such as "tickets" (similar to pull requests).
!gitbu.ch (aliases: !gitbuch)
Das deutsche Git-Buch: http://gitbu.ch -- anders als von Pro Git (http://git-scm.com/book) gibt es davon keine kostenlose Online-Ausgabe.
Development calendar in UTC: https://calendar.google.com/calendar/embed?src=jfgbl2mrlipp4pb6ieih0qr3so@group.calendar.google.com
Git Extensions is a GUI for git on Windows. It includes Explorer integration and a Visual Studio plugin. http://gitextensions.github.io/
The description of the gitflow branch workflow model is at http://nvie.com/posts/a-successful-git-branching-model/ while a tool to help implement this workflow is at https://github.com/petervanderdoes/gitflow See http://sethrobertson.github.io/GitBestPractices/#workflow for other workflow suggestions/references
GitHub is a !3rdparty commercial service offering freemium !hosting services for repositories & projects. https://github.com/features
!github_flow (aliases: !github-flow, !githubflow)
This is the workflow followed by github: http://scottchacon.com/2011/08/31/github-flow.html
Quick guide to Forking a repo on github: use the "Fork" button to copy the repo to your account; git clone $URL_OF_FORK; git remote rename origin myfork; git remote add upstream $URL_OF_ORIGINAL; git commit -m 'Some new stuff'; git pull --rebase upstream/master; git push myfork; click the "Create Pull Request" button on your fork. Done!
!github_pull (aliases: !github_pr, !pull_request)
To check out a GitHub pull request in your local repo, see this documentation: https://help.github.com/articles/checking-out-pull-requests-locally/
!github_vs_git (aliases: !git_vs_github)
github.com is not git; it's a hosting platform for git. There are alternative hosting offers (you can even host repositories yourself, or work on something on your own without any hosting whatsoever), and the range of features on the corresponding websites may differ. Git has little influence on what happens in github's web interface.
git treats ignored files as disposable, and might remove them if some operation requires it without warning. See https://public-inbox.org/git/7viq39avay.fsf@alter.siamese.dyndns.org/#t
Problems with creating "exceptions"(eg, !foolib.file) in your .gitignore? Just use `git add -f foolib.file` to override any wildcard matches. Future changes will be noticed, as ignore rules do not apply to tracked files.
!gitignore_template (aliases: !github_ignore)
Github has compiled a set of good .gitignore templates, and licensed them very liberally. https://github.com/github/gitignore
A global/directory .gitignore blacklist with a (potentially) subdirectory whitelist is not easy to specify in git. However, something like `printf '%s\n' '/*' '!/a/' '/a/*' '!/a/b/' '/a/b/*' '!/a/b/c/' > .gitignore` (ignore everything but a/b/c directory) or `printf '%s\n' '*' '!*/' '!*.txt' > .gitignore` (ignore everything but *.txt files) may do what you want.
A global/directory .gitignore blacklist with specific file whitelist is trivial to specify in git, since files tracked by git are ignored by .gitignore. So simply make a .gitignore of "*" and then `git add -f filename` Those specific files will be tracked by git and show up in git status and friends.
!gitinfo (aliases: !bot)
I am an IRC bot which responds to certain keywords to provide helpful(?) information to humans. Please see https://gitirc.eu/bot for more information about how to (ab)use me.
A tool to view commit history and the diffs they introduced, branching and merging, etc. It is shipped with git, run `gitk` from inside a repository.
GitLab is a !3rdparty commercial service offering freemium !hosting services for repositories & projects. It has an "Open Core" that you can run on your own server. https://about.gitlab.com/product/
Linking examples: git::master:Documentation/ (tree), git::master (shortlog), git::master^{commit} (commit), git::master/tree.h (file) -- also: git[notabug jast/gitinfo] master:http.pm (currently supported providers: github gitlab bitbucket kernel repo notabug)
!gitolite (aliases: !host)
Gitolite is a tool to host git repos on a server. It features fine-grained access control, custom hooks, and can be installed without root. Download: https://github.com/sitaramc/gitolite Docs: http://gitolite.com/gitolite/ Quick example: http://gitolite.com/gitolite/overview/#basic-use-case
!gitolite_emergencies (aliases: !emergencies)
Locked out of your gitolite-admin repo? No worries, help is on the way. http://gitolite.com/gitolite/emergencies/
!gitolite_ssh (aliases: !sts)
See http://gitolite.com/gitolite/sts/ for steps to troubleshoot ssh/gitolite. See http://gitolite.com/gitolite/glssh/ for how a single "real" userid can play host to multiple "virtual" users using ssh keys.
Gitorious was a free code-hosting website for open-source projects, but it shut down in May 2015. More details at https://about.gitlab.com/2015/03/03/gitlab-acquires-gitorious/ and http://blog.gitorious.org/2015/04/15/gitorious-org-is-dead-long-live-gitorious-org/
gitosis is no longer maintained and supported by the author; we usually recommend gitolite instead which has much better documentation and more features: http://github.com/sitaramc/gitolite -- there's even a migration guide for gitosis users... if you're stuck with gitosis for some reason we'll try to help, but no promises!
git pretty is a flowchart of how to get yourself out of trouble http://justinhileman.info/article/git-pretty/
gitslave ( http://gitslave.sf.net ) is useful to add subsidiary git repositories to a git superproject when you control and develop on the subprojects at more or less the same time as the superproject, and furthermore when you typically want to tag, branch, push, pull, etc. all repositories at the same time.
A book designed to teach people about Git in a real world usage model. The book follows a fictional company as they implement and learn about Git. Covers all 21 standard Git commands. Available for free at http://cbx33.github.io/gitt/
Here, have a cute and cuddly Gitten. Nyaa~
For a better way to view the reflog, try: gka() { gitk --all $(git log -g --format="%h" -50) "$@"; }; gka
gitolite documentation is available at http://gitolite.com/gitolite. If you're new to gitolite, and you can spend some time, read at least the main page and the overview, then look through the table of contents to decide what you need.
Gitolite v3 was out April 2012. V2 is now unsupported. PACKAGING: most distros call v3 "gitolite3", as it's very different and isn't auto-upgradable from v2. This is arguably my fault, but it happens (e.g., see sqlite3, gtk3, python3, etc). Please see http://gitolite.com/gitolite/migr/ for more.
Welcome to #gitolite. This is not as full as #git so there may be some delay in answering your question. Please be patient. If you're unable to stay logged in to IRC until someone answers, please ask on the mailing list; see http://gitolite.com/gitolite/index.html#contactsupport
New to git's litany of somewhat eclectic terms and phrases? Check out the glossary manpage and learn all about refspecs and evil merges: https://gitirc.eu/gitglossary.html
Gogs is a self-hosted platform similar to !gitlab, written in Go, aiming to be easier to deploy. http://gogs.io/
!google (aliases: !search)
You're looking for the .search function. Please be patient, it takes a lil bit to load results.
Grafts are an obscure feature allowing distinct histories to be joined together; see https://git.wiki.kernel.org/index.php/GraftPoint
!gui (aliases: !nogui)
Graphical user interfaces are not supported here. If you want to get support, it needs to be through the git CLI. Reasons: 1) Because very few people here use the graphical interface. 2) Because giving instructions for GUI's is difficult. 3) The command line gives you a history of what commands you have executed.
Popular GUIs for Git are listed on the website: http://git-scm.com/downloads/guis
What do you need help with? Something with git? Tell us what's going on, and please be specific. For information on how to abuse me (I'm a bot!), see https://gitirc.eu/bot . Please be gentle.
!helping (aliases: !polite)
We have a few guidelines for helping others in #git; please try to follow them. https://gitirc.eu/helping.html
!hook_pitfalls (aliases: !hooks)
Guidelines for writing hooks: 1. Consume all input (cat >/dev/null if you don't want it). 2. If you use any 'cd', also 'unset GIT_DIR'. 3. Don't git-pull in a hook (or any other script).
!host_gui (aliases: !github_cheap, !github_free, !host_guis, !hosted, !hosts)
There are several options for self-hosting git repositories with a web GUI: !gitblit !gitlab !rhode_code !gerrit and !gogs. Keep in mind that these all take far more work than a (non-GUI) !gitolite install. An overview of nearly all GUIs is available at: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools
There are many hosting options available for git repositories, including !github !gitlab !gitolite and many more: https://git.wiki.kernel.org/index.php/GitHosting
Hub is a wrapper around git which provides specific github features to the git cli. See https://github.com/github/hub for details.
Git doesn't track directories, so you can't ignore them. If you want them ignored, ignore the files in the directory. Matching a directory in .gitignore means you ignore all files in that directory
!ignore_tracked (aliases: !ignore_untracked, !ignoretracked)
Git only applies ignore patterns to untracked files. You can't use ignore patterns to ignore changes to files that are already tracked by git. To remove files only from git, but keeping them on disk, use git rm --cached <file>. Still, see https://gist.github.com/1423106 for ways people have worked around the problem.
https://github.com/mhagger/git-imerge -- a tool to split a large merge with many conflicts into many smaller merges, hopefully each with easier-to-understand small conflicts.
Importing lots of revisions from other VCSes(via git-svn in particular) can take a long time. If this will be a one-time switch you should consider "throwing out" all of your old history and making a simple initial commit from a tarball.
git v1.7.10 added support for including other config files via the include.path variable. See the "Includes" section of man git-config for more info
!index (aliases: !cache, !stage, !staging)
The index (or cache, or staging area) is one of git's most central concepts. Read http://git-scm.com/book/en/Getting-Started-Git-Basics "The Three States", and e.g. http://tomayko.com/writings/the-thing-about-git for some cool things it can help you do.
!interactive_rebase (aliases: !rebase-i, !rebase_interactive)
Interactive rebase sounds similar to rebase but has completely different abilities. It can do this to commits: change the order, squash some of them together, remove some, add random existing commits from other branches, split them, and more... it's very powerful. Documentation is in the section "Interactive Rebase" in 'man git-rebase'. https://gitirc.eu/git-rebase.html
!irclog (aliases: !ircstats, !log, !logs)
Public logs of #git are kept at: https://gitirc.eu/log
We think so, but if you don't, please go away and use $YourFavoriteSystem instead
A complete listing of the git-jokes used in the /topic can be found at https://madeitwor.se/git-jokes (patches welcome)
!just_ask (aliases: !anybody, !justask, !nobody)
You can just ask your question. If anybody knows the answer, they will answer soon (most of the time)
If you go to the trouble of asking questions, please go to the trouble of taking the advice offered, Take backups (type "!backup" as a reply to learn more) if necessary -- or in fact, it's a good idea anyway. You can almost always censor log messages if you have to. We are literally helpless unless you tell us what we need or do what we ask. Please, Just Do It™.
This channel is equipped with karma measuring devices. If you want to help someone to karmic nirvana, please mention their name when thanking them ("thank you", "thanks", "thx", etc.). Try ".karma <nick>" or ".topkarma" to show karma status of a person but don't expect immediate increase. Karma is not for those seeking instant gratification.
Looking for some enlightenment? Five koans about Master Git: http://stevelosh.com/blog/2013/04/git-koans/
!large_files (aliases: !big)
Git isn't yet great at large files(larger than RAM). Look at !annex for solutions. You can find them (after gc) with: git verify-pack -v .git/objects/pack/pack-*.idx | grep blob | sort -k3nr | head | while read s x b x; do git rev-list --all --objects | grep $s | awk '{print "'"$b"'",$0;}'; done
!large_repos (aliases: !big_repos, !bigrepo)
Git can be slow in the face of large repositories. There are git-config options which can help. pack.threads=1; pack.deltaCacheSize=1; pack.windowMemory=512m; core.packedGitWindowSize=16m; core.packedGitLimit=128m. Other likely ones exist.
git-last is a script which will give you a GitHub-like view of the current directory(showing the last commiter of each dir/file): https://madeitwor.se/scripts/blob/master/bash/git-last.sh
!learn_git_branching (aliases: !LearnGitBranching, !learn-git-branching)
A nice tutorial visualizing git branching: http://pcottle.github.io/learnGitBranching/ . See also !visualize_ops
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"
lol git gud(tm)
Want to release your code but don't want to read through a bunch of lawyerspeak? Then you should be aware that not including license terms defaults to Copyright, which makes it pretty useless to everyone. Take 5 minutes and use http://choosealicense.com/ :)
The following commands are all equivalent, assuming <branch> doesn't yet exist: 'git checkout -b <branch> <remote>/<branch>', 'git checkout -t <remote>/<branch>', 'git checkout <branch>'. The latter invokes some magic.
!lol (aliases: !graph)
git log --oneline --graph --all
As long as you have `git commit`ed your changes (or even `git add`ed them), your changes will not be lost for over two weeks unless you work really hard at it. There are two places where "lost" changes can be hiding. They might be in the reflog (`git log -g`) or they might be in lost&found (`git fsck --unreachable`). Type "!dangling" and "!reflog" into IRC for more info.
Made It Worse is a URL lengthener for Github. Example usage: https://torvalds.madeitwor.se/linux
!mailing_list (aliases: !ml)
The mailing list can be reached via git@vger.kernel.org. You don't need to subscribe to the list, you will always be put in cc on reply. Read archives at http://public-inbox.org/git
The git man pages are available online at https://gitirc.eu/git.html. Or were you looking for the "man git-foo" syntax (without the !)?
!master_branch (aliases: !default, !master)
'master' is the default name for the first branch created by git, and it is in no way special. You can just delete it, and use more meaningful names such as 'dev' 'stable' 'unstable' 'bug/001' etc. If this is a bare repo, you will want to change the default branch(`git symbolic-ref HEAD refs/heads/somebranch`) first.
!mercurial (aliases: !hg)
Mercurial is a competitor to Git: http://mercurial.selenic.com/ -- want to use Mercurial repositories in Git? http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
'git merge' takes two diverged lines of history (series of commits, e.g. on different branches), and recombines them with a "merge commit" on top. This creates an explicit record of you doing the merge, unless there were no local changes (which does a !fast_forward merge instead). If you don't need to keep a record like that, !rebase may produce easier-to-read history, but the two don't always mix well... see also !merge_vs_rebase
!merge_or_rebase (aliases: !merge_vs_rebase, !mergerebase, !pull_or_rebase, !pull_vs_rebase)
For a detailed discussion of the dis-/advantages of merge and rebase, and when to best use which, see: https://coderwall.com/p/ny1hia -- and here's how Linus explains which one to use: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
git does not support merging only certain files - it is all or nothing. To fake it, use 'git merge --no-commit', !unstage the files/dirs you don't want merged, then commit.
Git supports 'merge -s ours', but not 'merge -s theirs'. For a simple workaround, see https://gist.github.com/canton7/1268587
Unfortunately, we can't read your mind (despite our best efforts). Please establish a context and explain what exactly you mean or want to know.
a tool to manage Multiple Repositories, see http://joeyh.name/code/mr/
Git for Windows, formerly referred to as msysgit, is available at http://git-scm.com/downloads
!multiple_id (aliases: !multiple_ssh_keys)
git by itself does not allow you to specify which SSH key to use when speaking to a remote. You can use ssh_config+remote hostname tricks to achieve this goal: http://superuser.com/questions/272465/using-multiple-ssh-public-keys
!next (aliases: !NEXT)
Another satisfied customer. NEXT!
!nfs (aliases: !samba)
Git is a disk-intensive program. It's not recommended to use with network drives, it will be slower. Especially do not set up a "git server" that is shared over nfs, samba, etc.
!obfuscate (aliases: !censor, !snip)
Please do not elide, obfuscate, or otherwise hide information from !repro pastes. This invariably leads to pastes that hide the actual issue or (worse) are not consistent, sending the investigation down false paths. See !secret.
!office (aliases: !documents)
Microsoft Office documents(and related formats) are not stored well by git(see !binary). The Open/LibreOffice suites support saving as an uncompressed "Flat XML" file which helps alleviate this problem.
!official (aliases: !homepage, !source)
Some official resources for git. Homepage: http://git-scm.com/ | Source repo: https://www.kernel.org/pub/scm/git/git.git/ (Mirrrored: https://github.com/git/git/) | IRC channel: You're in it. | Mailing list: http://vger.kernel.org/vger-lists.html#git (git@vger.kernel.org, subscription optional)
Have you tried turning it off and on again?
From the #git website: it's okay to talk about anything (within general limits of reason), as long as you don't get in the way of people talking about on-topic things (mainly questions about git and using git). Accordingly, please consider pausing off-topic discussions to help people having trouble with git (if any).
@/dev/null (there's currently no information about ops in the bot but it automatically matches !oops which is an alias for !fixup. This placeholder avoids confusion.)
'origin' is the default name for a remote assigned by git clone. It is in no way special (similar to !master) and can be edited as you like through git remote rename
To create an orphaned branch(unrelated to existing history): `git checkout --orphan newbranchname`. This will leave your index/worktree as-is(use `rm .git/index; git clean -dfx` to delete EVERYTHING). If you get 'error: unknown option `orphan`' see !orphan_old. For an empty/null commit see !orphan_null.
!orphan_null (aliases: !orphan_empty)
To create an orphan branch with the null/empty commit, use: `git checkout -b orphan $(echo "empty" | git commit-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904)`
If your git is older than 1.7.2, use: `git symbolic-ref HEAD refs/heads/orphan; rm .git/index; git clean -fdx; touch foo; git add foo; git commit -m 'Initial commit on branch orphan'`
!packaged (aliases: !build, !compile)
Unless you have a specific technical need for the "latest and greatest" you should go with a packaged version. Compiling and installing your own is not something that we will walk you through or troubleshoot (though it *is* fairly easy for developers with GNU/Linux experience).
'The git parable' provides some good reasoning behind git. http://tom.preston-werner.com/2009/05/19/the-git-parable.html
The "Partial Clone" feature is a performance optimization for Git that allows Git to function without having a complete copy of the repository. (https://git-scm.com/docs/partial-clone https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout https://about.gitlab.com/blog/2020/03/13/partial-clone-for-massive-repositories/)
!paste (aliases: !gitpaste, !pastebin)
Please use a pastebin for snippets longer than one line. Persistent and can be used with a GitHub account: https://gist.github.com/ - one hour auto-delete: https://upaste.de/
Git does not store full UNIX permissions, even if it makes it look like it does. In fact, the only mode-related info Git stores is whether a given file is executable. Anything else is taken care of by your umask and the core.sharedRepository setting. See also !configfiles
Probably some filter is causing the files to keep being modified. See http://softec.lu/site/DevelopersCorner/GitSmudgeCleanCorrupted for details.
I only respond to !reply_time
If a pizza has a radius 'z' and a depth 'a' that pizza's volume can be defined Pi*z*z*a
!postproduction (aliases: !perfect)
So, you want to make your commit history look pretty before pushing? http://sethrobertson.github.io/GitPostProduction talks you through how to use 'rebase -i' to do this.
Want to get free hosting for non-public projects (you can control who gets access)? Some options: Bitbucket (https://bitbucket.org/ - 5 members max), Gitlab (https://gitlab.com/ - practically no limits)
!privmsg (aliases: !pm)
You can get gitinfo keyword expansion (e.g. !doc or this one) sent directly to you by sending a private message to me: /msg gitinfo !doc. This avoids spamming the channel. Also see https://gitirc.eu/bot/trigger.php
!profanity (aliases: !family, !fsck)
Hey! This is a family-safe channel, so keep it frakking clean you fierfekker!
!prompt (aliases: !ps1)
The bash completion script developed with git (https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh) and the one for zsh shipped with zsh (http://gitready.com/advanced/2009/01/28/zsh-git-status.html) both support showing the status of your repo in the prompt string, at a glance
Publishing git repos via git-daemon or gitweb is not for the faint of heart. Consider using Github as a free place to post your work, and let them worry about administration.
!pull (aliases: !fetch-vs-pull)
pull=fetch+merge (or with flags/config also fetch+rebase). It is thus *not* the opposite of push in any sense. A good article that explains the difference between fetch and pull: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
!pull_all (aliases: !pull-all)
'pull --all' is a nonsensical request. It will invoke 'fetch --all' (which you should use instead) but it will *not* merge (see !pull) all branches that have an upstream, or anything of the sort.
!pull_upstream (aliases: !fork_sync, !fork_update, !sync_fork, !upstream_pull)
To incorporate changes from an "upstream" or forked-from repository: git remote add upstream $URL; git fetch upstream; git merge upstream/$BRANCH. https://help.github.com/articles/syncing-a-fork/
!pusher (aliases: !shover)
I am the pusher robot. I shove around the code. http://youtu.be/7E0ot9iJm_k?t=34s
Hmm.... that doesn't make much sense. Its possible you're not showing us the full puzzle. Please provide more details, preferably including a !transcript including `git status` output so we can help you help yourself.
You know, you have not actually asked a question. Without asking a question, it is hard to get any responses. Please explain what you are trying to do, what you typed in, and exactly what came back. Use http://gist.github.com/ for exact command sessions.
We require users to have completed a NickServ registration, or to ask the bot for a +v(via the .voice command). This helps to combat most random spamming
!read (aliases: !spoon)
Don't expect everything to be spoon fed to you - the man pages and other documents do not bite, you need to spend some time and effort reading them.
Letters refer to !detached. (a) and (b): 'git checkout branchname' to continue working on another branch, or 'git checkout -b branchname' to start a new one here; (c) git am --continue; (d) git rebase --continue
'git rebase' takes away your local commits, updates your branch with new stuff from <upstream> (argument), then re-applies your local commits on top. This makes it look like your commits were created "after" the new stuff, and it can look cleaner than doing a !merge. Beware of !rewriting_public_history, though. Not to be confused with !interactive_rebase.
When you 'git checkout branch; git rebase master', git will sit on top of master and apply successive patches from branch. If patch #2 conflicts, then LOCAL points to the result of patch #1 having been applied, and REMOTE points to patch #2
see !recursive
see !recurse
see !recursion
The git reflog (`git log -g`) temporarily (90 days by default) snapshots your branch states at each operation that changes the branch, making it easy to undo e.g. merges and rebases. The usual warnings about !rewriting/undoing history apply. See https://sukima.github.io/GitFixUm/ for full details.
!refspecs (aliases: !fetchspec)
Refspecs are used by fetch/push to *spec*ify which *ref*s to transmit where. They have the form "source:destination". They can be prefixed with a "+" to force the update, possibly displacing existing history. More info: https://gitirc.eu/git-fetch.html or http://i.qkme.me/3tke7r.jpg
If you are not satisfied with git, or the support provided by the volunteers in #git, you are entitled to a full refund of the purchase price, and are invited to use another VCS. Elsewhere.
The only git porcelain commands which might interact with remote repos are: fetch, pull, push, remote, ls-remote, archive, submodule (plus plumbing, remote helpers, etc)
!remote_tracking_branch (aliases: !remote-tracking-branches, !remote-tracking_branch, !remote-tracking_branches, !remote_branches, !remote_tracking_brancher, !remote_tracking_branches, !rtb, !tracking_branches)
Remote-tracking branches (branches which start with e.g. 'origin/', listed by 'git branch -r') are read-only mirrors of the branches in another repository. They're updated by 'git fetch'. You can't edit them directly (trying to check them out results in a !detached HEAD), but you can create a local branch based on a remote-tracking branch using e.g. 'git checkout -b <branch> <remote>/<branch>'
You can use rebase to remove commits: git rebase --onto <commit>~1 <commit> <branch>. Note this will !rewrite history.
!rename (aliases: !move, !mv)
git does not support explicitly file renaming - the 'git mv' command is shorthand for 'git rm --cached; mv; git add'. All "rename" statistics are generated at runtime when examining history with git-log. See the -M option in the git-log manpage for more info. Also public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org and `diff.renames = true` in man git-config
I only respond to !ECHO-REQUEST
Repo is a tool produced by Google for the AOSP project(and others) which wraps git and provides its own set of commands. While it is possible to use git with repositories that are managed by repo, it is not always easy. https://source.android.com/source/using-repo.html
!reset (aliases: !reset_demistified, !reset_demystified)
reset does two things! (1) without file/path argument: 'git reset [flags] [<commit>]' = make the current branch point to <commit> (default: HEAD). --soft = don't do anything else. --mixed (default) = overwrite the index to match. --hard = overwrite the working files to match. (2) 'git reset [<commit>] -- <path>' = overwrite the index entries for <path> with the content from <commit> (default: HEAD)
You can go back to the last commit, or any other commit (effectively getting rid of commits which can cause issues, see !rewrite), using 'git reset --hard' with an optional commit/ref argument. This will irrevocably destroy all uncommitted changes, so please be careful!
tl;dr of man git-reset: --soft moves HEAD, --mixed moves HEAD+index, --hard moves HEAD+index+work-tree, -- foo.txt will !unstage
many terms are used in many different ways in version control; therefore, your question seems ambiguous to some of us. Please describe the outcome you had in mind so that we get a better understanding of which meaning you intended.
!resume (aliases: !parallel, !torrent)
Git does not yet support resuming, torrenting, or parallel fetching of clones or other network traffic. You can make a single file out of a repo using 'git bundle' then use normal resumable download methods to get that file. See https://bundler.caurea.org. Also !gitolite can be told to maintain and send bundles using rsync; see https://github.com/sitaramc/gitolite/blob/master/src/commands/rsync
!revert (aliases: !reverts)
That's a rather ambiguous question... options: a) make a commit that "undoes" the effects of an earlier commit [man git-revert]; b) discard uncommitted changes in the working tree [git reset --hard]; c) undo committing [git reset --soft HEAD^]; d) restore staged versions of files [git checkout -p]; e) move the current branch to a different point(possibly losing commits)[git reset --hard $COMMIT]?
Revision numbers are often requested, but no matter what algorithm you choose to generate them, they cannot simultaneously have all four desirable properties: (a) increasing (b) unique (c) immutable [for a given commit] (d) decentralized. Subversion obviously does not need (d). Git uses a hash function, and thus gets all but (a). See man gitrevisions for other ways to refer to commits.
!rewrite (aliases: !rewrites, !rewriting, !rewriting_public_history)
Rewriting public history is not recommended. Everyone who has pulled the old history will have to do work (and you'll have to tell them to), so it's infinitely better to just move on. If you must, you can use `git push --force-with-lease <remote> <branch>` to force (and the remote may reject that, anyway). See http://goo.gl/waqum
Hosting Web-GUI with Git, Mercurial and Subversion support: https://rhodecode.com/
R.I.P. Tree-Eating Monster! Shrine at: http://web.archive.org/web/20110720065754/http://git-scm.com/
Node.js may be Badass Rockstar Tech, but doing it correctly is a lot better than following a !blog post. http://www.youtube.com/watch?v=bzkRVzciAZg
We love being your rubber ducks! Just tell us what your problem is, and maybe you'll find the solution yourself! Our favorite questions are the ones we don't need to answer. (Don't forget to mention your solution for posterity's benefit!)
!sausage_making (aliases: !hamburger, !sausagemaking)
Some developers like to "hide the sausage making", transforming their commits before presenting them to the outside world. See http://sethrobertson.github.io/GitBestPractices/#sausage and !perfect
The Schwartzian Criterion of Git Usage: if you don't envision using branching and merging, then git probably isn't the right answer.
The Semantic Versioning standard is widely used for version numbering. You may find it useful when creating git tags: http://semver.org/
Couple of guides on how to use git send-email: https://git-send-email.io/ https://flusp.ime.usp.br/git/2019/02/15/sending-patches-by-email-with-git/
To tell git which remote branch to use in pull (and push if you set push.default to upstream) for a given branch foo, use something like: git branch --set-upstream-to origin/foo foo
!sgc (aliases: !ghs)
For bug reports, feature requests, suggestions for improvement, or specific problems with an individual repo (or gist, etc.), please contact support via support@github.com or https://github.com/support - support tries to answer all questions within 24 hours, including weekends and holidays.
!sha1 (aliases: !hash)
git uses a variant of the SHA1 cryptographic hash algorithm to ensure object integrity. Git v2.13.0 added hardening to the SHA-1 implementation to mitigate SHAttered; work towards a NewHash is underway: https://git.io/vpIMJ | Please note that purposeful SHA1 collisions are computationally expensive, and accidental encounters are more likely with wolves. https://en.wikipedia.org/wiki/Wolf_attacks Fear their howl!
A shallow clone will clone a repository to a certain "depth", which sounds like a good idea for only obtaining the latest revision of a given repo. However, they often don't work as-advertised(breaking on fetch and push operations). Instead you should consider git-archive's --remote feature, or perhaps you're really encountering a !binary problem
To get a listing of what your local branches have set as their "upstream", run: git branch -avv
A sign-off is a line in the commit message saying 'Signed-off-by: Your Name <your@email>'. It can be added using 'git commit -s'. A few open source projects require it for legal reasons. See http://stackoverflow.com/a/1962112/1086121 for a good explanation
!simple (aliases: !complex)
At its heart git is made up of many concepts that are individually simple. Getting the whole picture right is often tricky, and it is usually about breaking up the complex concept into its simple, individual parts and grokking those. Both !bottomup and !cs will help with that.
!simpleguide (aliases: !simplegit)
The Simple Git Guide by Roger Dudler: http://rogerdudler.github.io/git-guide/
Ohh, yeah, now we’re get*hick*ting somewhe*hick*re.
Please post the url returned by ' git log -n 20 --all --graph --format="%h %p %d %s" | curl -F text=@- https://upaste.de ' to give us an idea about what your situation is (increase the -n argument if your problem is more complex than 20 commits can explain)
You should read http://www.catb.org/esr/faqs/smart-questions.html on how to improve asking and recieving help from the open source community. It will greatly benefit you and you'll get results faster.
!smartgit (aliases: !SmartGit)
SmartGit is a (commercial) UI for git that is very user-friendly and feature-complete. http://syntevo.com/smartgithg
Yum! Oysters!
!snowflake (aliases: !unique)
You are not a beautiful and unique snowflake. In other words: somebody has undoubtedly tried what you are doing. Search a bit and maybe you'll find their work.
!soviet_git (aliases: !sovietgit)
In Soviet Git, commits are not on branches, branches point to a commit.
Sparse checkout can be used to restrict which files/folders are updated with all checkout and status operations. It cannot change the tree the checkout is rooted from. One common use case is locally keeping Git from updating some of the files tracked in your repository. See the "Sparse Checkout" section in man git-read-tree (https://gitirc.eu/git-read-tree.html).
To split an unpushed commit: git rebase -i <id>^; (change the corresponding line from 'pick' to 'edit'; save and quit); git reset --soft HEAD~; (stage and commit changes for first commit; stage and commit changes for second commit); git rebase --continue
Please use SSH to talk to remote repos. http:// and git:// are completely unsecured and http:// suffers from smart webservers trying to implement policy. You can try to do "smart" https://, but it can be troublesome to configure if you do not know how (see !web_repos for simple instructions) unless your company implements a MITM attack and prevents end-to-end crypto.
!ssh_github (aliases: !github_ssh)
If you are having problems accessing github repos over HTTPS you should switch to SSH (the default used by git, for many very good technical reasons): https://help.github.com/articles/generating-ssh-keys
To automatically stage all removed files (without also staging other changes), use the following command: git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
!starting_point (aliases: !starting_points)
Good starting points for getting to know Git are: official website http://git-scm.com/ (esp. "Documentation"), http://stackoverflow.com/tags/git/info, http://try.github.com, https://git.wiki.kernel.org/index.php/Main_Page, http://rogerdudler.github.io/git-guide/ and https://www.atlassian.com/git/tutorial/git-basics
!startover (aliases: !rmrf)
There’s usually no need to start over / rm -rf everything and reclone or so. Most situations can be fixed by other means.
SubGit is a two-way git<->svn bridge. It provides a (self-)hosted alternative to git-svn, with some advantages. See http://subgit.com/
!submodule (aliases: !submodules)
git-submodule is ideal to add subsidiary git repositories to a git superproject when you do not control the subprojects or more specifically wish to fix the subproject at a specific revision even as the subproject changes upstream. See http://www.git-scm.com/book/en/Git-Tools-Submodules
In order to change a submodule you must go into the submodule repository, check it out to the appropriate branch, make the needed change (possibly involving git pull), commit the change, cd .. (out of the submodule), git commit -m "Updated submodule" submodulepath
!submodules_mv (aliases: !submodule_mv)
Renaming git submodules is harder than it perhaps should be. All commands are in the superproject. Edit .gitmodules to reflect the new path. Then `git mv oldsubmodulepath newsubmodulepath; git commit -m "Moved submodule from old to new"` Inspect .git/config to see if anything looks likely for changing.
!submodules_rm (aliases: !submodule_rm)
To delete a submodule, do this in the superproject: Edit/delete .gitmodules to remove the submodule, and `git add .gitmodules`. Then `rm -rf submodulepath; git rm -f --cached submodulepath; git commit -am "Removed submodules!"` Inspect .git/config for "submodule" entries to remove. Inspect .git/modules for caches to remove. Possible alternatives to submodules: "!gitslave" or "!subtree"
!subprojects (aliases: !subrepos)
So, you want to add git repositories inside of other git repositories? Well, you have four main options. First is to just do it, add the repo to the outer project's .gitignore, and treat them entirely separately. Best if they are entirely separate. Otherwise your best options are "!submodule", "!gitslave", and "!subtree". Try those commands in this channel, or in a PM to avoid flooding.
The subtree merge method is great for incorporating a subsidiary git repo into your current one with "unified" history. Read http://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_merge for more info, see also !git-subtree and !git-stitch-repo.
!subtree_alt (aliases: !subtree_alternatives)
The git subtree merge method is hard to export changes from.. https://github.com/apenwarr/git-subtree provides another method which appears to be easier to export changes from. Also as a no-change-exported method, see https://metacpan.org/module/git-stitch-repo which claims to generate a unified history instead of merged branches.
I'm sorry, I cannot seem to locate your paid-up support contract in my records. You can either find someone to pay to support you professionally, or throw yourself on the mercy of the gits on #git who will help you as they see fit. Alternately, you can request a refund of the full purchase price of git and find another SCM system which will satisfy your support needs for the same or lower cost
For a one-time conversion of SVN to git, svn2git should be used instead of git-svn. There are many tools with this name. Probably the best is the KDE one at https://github.com/svn-all-fast-export/svn2git. To analyze the SVN repo history upfront for building up proper rules for svn2git, you might use svneverever from here: http://blog.hartwork.org/?p=763
git-svn determines the upstream branch to push to by finding the topmost commit in your current branch that has a "git-svn-id" line (i.e., 'git log --grep=^git-svn-id: --first-parent -1'), and using the branch mentioned in it.
!talks (aliases: !video, !videos)
Some good video talks about Git: [yt] http://goo.gl/z72s (Linus Torvalds: History&Concepts); [yt] http://goo.gl/R9H2q (Scott Chacon: Git basics, live examples); http://vimeo.com/35778382 (Randal Schwartz: Git basics, descriptional); http://vimeo.com/46010208 (Jessica Kerr: Git basics, descriptional)
@/dev/null (trigger blocked, '!text' is often used in gitattributes definitions)
You're very welcome!
The three great virtues of a programmer, according to Larry Wall: laziness (write code that saves work, document so you don't have to explain over and over), impatience (make software anticipate what you need), hubris (make things nobody could want to criticize)
!tias (aliases: !TIAS, !tryit)
Try it and see™. You learn much more by experimentation than by asking without having even tried. If in doubt, make backups before you experiment (see !backup). http://gitolite.com/tias.html may help with git-specific TIAS.
https://git.wiki.kernel.org/index.php/Tig - An ncurses (terminal) alternative to gitk.
See https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools for information about known interfaces, frontends, and tools.
TopGit is a patch queuing system, allowing you to manage a series of topic branches that apply on top of a main branch. https://mackyle.github.io/topgit/topgit.html
!topsecret (aliases: !secret, !top_secret)
If your situation is so secret that you can't tell us how to !reproduce it, there's really not much we can do. Perhaps you need to find or buy support you can trust? There are people with clearances even on #git but they may not want to identify themselves. However, you are protected by the biggest secret of all: We just don't care.
git does not track renames of files in history, git only records tree snapshots. It can try to guess whether a change was a rename, or just unrelated removal+addition, when asked. You can help this by making the rename in a different commit from a modification. See man git-log -C and -M
!transcript (aliases: !repro)
Please paste (using https://gist.github.com/ or similar) a transcript ( https://git.io/viMGr ) of your terminal session so we can see exactly what you see
!treeish (aliases: !refs)
A tree-ish is something that looks like a tree. Read 'man gitrevisions' and http://git-scm.com/book/en/Git-Tools-Revision-Selection
!triggers (aliases: !aliases, !fact, !factoids, !shortcuts)
Please don't spam me! I'm just a poor bot! Here's everything I know: https://gitirc.eu/bot/trigger.php -- that's a list of these nifty keywords like "!bot" that you can use in the channel, in case you were wondering.
A quick, interactive, in-browser introduction to git is available at http://try.github.io
UGT (Universal Greeting Time): it is always morning when someone joins a channel, and always late night when they leave. http://www.total-knowledge.com/~ilya/mips/ugt.html
You might wanna see http://devopsreactions.tumblr.com/post/104064772852/understanding-git
!unlearn (aliases: !notsvn, !unlearning)
Users of centralized VCSes will need to unlearn a number of habits in order to learn git. Many commands, such as "checkout" and "revert" bear little in common to those holding the same name in other systems.
Accidentally marked a conflicted file as resolved and want to get the conflict markers back? `git checkout --merge -- <path to file(s)>`
To unstage a file from the index(in other words, to undo an accidental `git add foo/bar.txt`), use: git reset -- foo/bar.txt
To remove a file from git's tracking, without deleting it from your working tree, `git rm --cached <file>`. Note that any repo which pulls this change will delete their local copy of that file. You can "bring it back" using `git checkout HEAD@{1} file` immediately after pulling / merging
Do you want to set the remote branch which is being tracked(!set_upstream), list what remote branches are being tracked(!show_upstream), or incorporate changes from another repo which is not your "origin"(!pull_upstream) ?
!use_lf (aliases: !lf)
To eliminate all issues with line-endings in a repo it is recommended to change all files to use LF, and then convince all contributors to use LF-aware editors (Notepad++ works well for Windows), by force if necessary. !crlf has some tips if this is not feasible.
The author and committer names are by convention some form of a personal name (that is, the name by which other humans refer to you). This name has no effect on authentication; for that, see the credential.username variable in git-config(1).
Please don't be a help vampire - we're here to point you in the right direction, not type out the commands verbatim for you. http://slash7.com/2006/12/22/vampires/
'Version Control By Example' gives a good overview of the different VCSes available. The author will even mail you a dead-tree copy for free. https://ericsink.com/vcbe/index.html
https://github.com/RichiH/vcsh - Version Control System for $HOME - multiple Git repositories in $HOME -- abusing fake bare Git repositories for fun and profit
The current version of git is listed in the /topic of #git (out of date? Say '.version' in the channel). Don't be scared if you're using a slightly older version -- they interoperate just fine, though you may be missing a few features. Unless you have a specific need for the newest version, it's best to stick with premade packages.
Visualize common operations: https://onlywei.github.io/explain-git-with-d3/
!visualize (aliases: !visualise)
You can visualize the whole repo graph with gitk (GUI, `gitk --all`), !lol (plain CLI, `git log --oneline --graph --decorate --all`) or tig (ncurses, http://jonas.nitro.dk/tig/)
!visualize_ops (aliases: !visops, !vizops)
Visualize common operations: https://onlywei.github.io/explain-git-with-d3/ . See also !learn_git_branching
The sound produced by the vocal organs of a vertebrate, especially a human. (American Heritage® Dictionary of the English Language, 4th Edition) – Or did you want to talk in #git? Try: .voice
!wat (aliases: !what)
Wat: https://www.destroyallsoftware.com/talks/wat
!weasels (aliases: !gremlins)
The consequences of this proposal are not well-defined. A band of furious weasels may infest your undergarments, or it might work just fine. You should !backup then !tryit and let us know what happens.
!web_repos (aliases: !http_repos, !https_repos, !web_repositories)
Sharing git repositories over http/https (gitweb or `git clone`) is easy with http://goo.gl/4EUTCX Auth includes none, authfile, pam, ldap, and ssl client certs.
!welcome (aliases: !hello, !hi)
Welcome to #git, a place full of helpful gits. If you have a question, feel free to just go ahead and ask—somebody should answer shortly. For more info on this channel, see https://gitirc.eu/ - Take backups (type !backup to learn how) before taking advice.
!wherearemybranches (aliases: !otherbranches)
Git clones all branches, but initially makes only the main branch (usually 'master') available as a normal local branch. To work on another branch, simply 'git checkout <branch>' (or, in versions older than 1.6.6, git checkout -b <branch> origin/<branch>). This works even if the branch doesn't show up in the normal list of branches. For technical details, see !rtb
!why (aliases: !because, !cuz, !reasons)
Why? Because screw you, that's why.
1. If it's not stored in git, it might as well be gone. 2. Git is not a backup.
!workflow (aliases: !workflows)
Finding the right workflow for you is critical for the success of any SCM project. Git is very flexible with respect to workflow. See http://sethrobertson.github.io/GitBestPractices/#workflow for a list of references about choosing branching and distributed workflows.
What did you do (which commands?), what happened as a result (any messages?), and what was the result you expected instead?
!xy (aliases: !doinitrong, !goal, !urdoinitrong, !wrong)
You are asking about a solution, but we can help you a lot better if you could describe the actual problem you are trying to solve.
git config alias.yolo '!git commit -fA -m "Yolo swag!"; git push -f'
!zombie (aliases: !zombies)
Brainzz! More brainzzzz! For information about detached heads, see !detached

Raw data

You can get the raw data as JSON or tab-separated values (TSV).