[System] You are a helpful assistant.

[User] git-rev-list - Lists commit objects in reverse chronological order  --first-parent

[Assistant]
When finding commits to include, follow only the first
parent commit upon seeing a merge commit.  This option
can give a better overview when viewing the evolution of
a particular topic branch, because merges into a topic
branch tend to be only about adjusting to updated upstream
from time to time, and this option allows you to ignore
the individual commits brought in to your history by such
a merge.


[System] You are a helpful assistant.

[User]
How can I git stash a specific file?
How can I stash a specific file leaving the others currently modified out of the stash I am about to save?
For example, if git status gives me this:
younker % gst
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   app/controllers/cart_controller.php
#   modified:   app/views/cart/welcome.thtml
#
no changes added to commit (use "git add" and/or "git commit -a")

and I only want to stash app/views/cart/welcome.thtml, how would I do that? Something like (but of course this does not work):
git stash save welcome_cart app/views/cart/welcome.thtml

[Assistant]
EDIT: Since git 2.13, there is a command to save a specific path to the stash: git stash push <path>. For example:
git stash push -m welcome_cart app/views/cart/welcome.thtml

OLD ANSWER:
You can do that using git stash --patch (or git stash -p) -- you'll enter interactive mode where you'll be presented with each hunk that was changed. Use n to skip the files that you don't want to stash, y when you encounter the one that you want to stash, and q to quit and leave the remaining hunks unstashed.  a will stash the shown hunk and the rest of the hunks in that file.
Not the most user-friendly approach, but it gets the work done if you really need it.


[System] You are a helpful assistant.

[User]
How to delete all remote git branches which have already been integrated?
At work we are using topic branches which are integrated into a few (3) master branches at some point.
Now I'd like to delete all topic branches from my remote repository which have been fully integrated into a master branch. If that's not possible, retrieving a list of local branches which have been integrated would be fine, too.

[Assistant]
Another answer edited in by someone who thought it's the best (and it looks good):
git branch -r --merged origin/master | grep -v master | grep "origin/" | cut -d "/" -f 2- | xargs -n 20 git push --delete origin

Explanation:

git branch -r --merged origin/master

-r/--remotes list the remote-tracking branches.
--merged origin/master only list branches whose tips are reachable from origin/master.

grep -v master remove any branch name containing master from list.1 -v means negative match.
grep "origin/" select only branches on origin remote.
cut -d "/" -f 2- drop the origin/ prefix
xargs -n 20 git push --delete origin do something similar to git push --delete origin branch-a branch-b branch-c …

-n 20/--max-args=20 use at most 20 arguments per command line.

As for -n, I choose 20 just as an example. Fewer arguments will make it slower, for example -n 1 makes it delete one at a time; you have more progress hints, because it will report each time it deletes a branch. More arguments like -n 200 will make it faster (less total time), but it only reports once every 200 branches, making you think that it is frozen at first (while it is not). Tune the number to your need. If you omit this option, the default number is really large (2048 in my machine).
1. Note that this also removes origin/HEAD -> origin/master, but you won't want to mess with origin/HEAD anyway.
Original answer:
git push --delete remote topicbranch

or
git push remote :topicbranch

Giving a list of branches, would be something with git branch --merged master


[System] You are a helpful assistant.

[User] git-push - Update remote refs along with associated objects  git push origin master:refs/heads/experimental

[Assistant]
Create the branch experimental in the origin repository
by copying the current master branch.  This form is only
needed to create a new branch or tag in the remote repository when
the local name and the remote name are different; otherwise,
the ref name on its own will work.


[System] You are a helpful assistant.

[User] git-submodule - Initialize, update or inspect submodules  add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]

[Assistant]
Add the given repository as a submodule at the given path
to the changeset to be committed next to the current
project: the current project is termed the "superproject". <repository> is the URL of the new submodule’s origin repository.
This may be either an absolute URL, or (if it begins with ./
or ../), the location relative to the superproject’s default remote
repository (Please note that to specify a repository foo.git which is located right next to a superproject bar.git , you’ll
have to use ../foo.git instead of ./foo.git - as one might expect
when following the rules for relative URLs - because the evaluation
of relative URLs in Git is identical to that of relative directories). The default remote is the remote of the remote-tracking branch
of the current branch. If no such remote-tracking branch exists or
the HEAD is detached, "origin" is assumed to be the default remote.
If the superproject doesn’t have a default remote configured
the superproject is its own authoritative upstream and the current
working directory is used instead. The optional argument <path> is the relative location for the cloned
submodule to exist in the superproject. If <path> is not given, the
canonical part of the source repository is used ("repo" for
"/path/to/repo.git" and "foo" for "host.xz:foo/.git"). If <path>
exists and is already a valid Git repository, then it is staged
for commit without cloning. The <path> is also used as the submodule’s
logical name in its configuration entries unless --name is used
to specify a logical name. The given URL is recorded into .gitmodules for use by subsequent users
cloning the superproject. If the URL is given relative to the
superproject’s repository, the presumption is the superproject and
submodule repositories will be kept together in the same relative
location, and only the superproject’s URL needs to be provided.
git-submodule will correctly locate the submodule using the relative
URL in .gitmodules .


[System] You are a helpful assistant.

[User] giteveryday - A useful minimum set of commands for Everyday Git

[Assistant] SYNOPSIS Everyday Git With 20 Commands Or So


[System] You are a helpful assistant.

[User] git - the stupid content tracker  git-column

[Assistant] Display data in columns


[System] You are a helpful assistant.

[User] git-config - Get and set repository or global options  gc.rerereResolved

[Assistant]
Records of conflicted merge you resolved earlier are
kept for this many days when git rerere gc is run.
You can also use more human-readable "1.month.ago", etc.
The default is 60 days.  See git-rerere .


[System] You are a helpful assistant.

[User] git-show - Show various types of objects  --diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]

[Assistant]
Select only files that are Added ( A ), Copied ( C ),
Deleted ( D ), Modified ( M ), Renamed ( R ), have their
type (i.e. regular file, symlink, submodule, …) changed ( T ),
are Unmerged ( U ), are
Unknown ( X ), or have had their pairing Broken ( B ).
Any combination of the filter characters (including none) can be used.
When * (All-or-none) is added to the combination, all
paths are selected if there is any file that matches
other criteria in the comparison; if there is no file
that matches other criteria, nothing is selected. Also, these upper-case letters can be downcased to exclude.  E.g. --diff-filter=ad excludes added and deleted paths. Note that not all diffs can feature all types. For instance, copied and
renamed entries cannot appear if detection for those types is disabled.


[System] You are a helpful assistant.

[User]
How to un-approve github review after new commits automatically

Once a pull request is approved, if there are further commits:
The Pull request should go to un-approved state automatically.
Can this be done?

[Assistant] The ability to Dismiss stale pull request approvals when new commits are pushed is a setting under Require pull request reviews before merging in the branch protection settings. This is disabled by default.


[System] You are a helpful assistant.

[User] git-format-patch - Prepare patches for e-mail submission  --cc=<email>

[Assistant]
Add a Cc: header to the email headers. This is in addition
to any configured headers, and may be used multiple times.
The negated form --no-cc discards all Cc: headers added so
far (from config or command line).


[System] You are a helpful assistant.

[User] git - the stupid content tracker  git-worktree

[Assistant] Manage multiple working trees


[System] You are a helpful assistant.

[User]
Problems with entering Git commit message with Vim
OS: Windows
I write
$ git commit

then

"# Please enter the commit message"

I write some text, like

"Form validation added"

Press Enter and not commited. Then i press Shift+Enter, Ctrl+Enter, Alt+Enter - still not commited.
I think its stupid trouble, but What i must to do?

[Assistant]
If it is VIM for Windows, you can do the following:

enter your message following the presented guidelines
press Esc to make sure you are out of the insert mode
then type :wqEnter or ZZ.

Note that in VIM there are often several ways to do one thing. Here there is a slight difference though. :wqEnter always writes the current file before closing it, while ZZ, :xEnter, :xiEnter, :xitEnter, :exiEnter and :exitEnter only write it if the document is modified.
All these synonyms just have different numbers of keypresses.


[System] You are a helpful assistant.

[User]
git: symlink/reference to a file in an external repository
Is it possible in git to have a "link" to a particular file in a git repo? Like what git submodules do for folders but my question is about a particular file, not a full directory:
my-project/
    class1.java
    class2.java
    logback.xml (link to a particular file, say https://github.com/theHilikus/JRoboCom/blob/master/jrobocom-core/src/main/resources/logback.xml)

So as can be seen, in this case it doesn't make sense to have a whole submodule folder, it is just one file.
I'm ok with the link being locked to a particular commit but it would be better if it's moving as it changes in its own project's lifecycle
As a note, this has nothing to do with file-system's symbolic links; I'm talking about a reference to a file in another project, repo, branch, or anything. it's ok if the content of the file is a duplicate and not a file-system symlink

[Assistant]
Git has features that you can use to achieve what you need. It supports file system symlinks and it supports submodules. Submodules is already a standard way to handle references to other repositories. You can use them in conjunction with a way to reference files locally. That can be handled directly using relative symbolic links or indirectly using a script that copies over files from the submodule to where you need them.
You should have one submodule per external git tree and you should treat the submodules with care, as they are not only links to external repositories but also to their specific commits. The following to solutions will show you how to use individual files from an external repostiory but still maintain all the advantages of submodules.
An alternative way is to fetch the files directly but then you will lose the advantage of submodules entirely or you will have to build the features yourself. As I already stated, submodules are the standard way to handle this sort of task and you should use it unless you have special needs like to avoid downloading other files at all cost.
Using a submodule and a symlink
Once you have a submodule ready, you can just add filesystem symlinks pointing into the submodule directory structure.
Run this in a shell in your project directory:
$ git submodule add https://github.com/theHilikus/JRoboCom
$ ln -s JRoboCom/jrobocom-core/src/main/resources/logback.xml
$ git add .gitmodules logback.xml
$ git commit -m "add a symbolic link to logback.xml with the respective submodule"

Now you have a symlink:
logback.xml -> JRoboCom/jrobocom-core/src/main/resources/logback.xml

Using a submodule and a script
As an alternative, you can use custom scripts that copy over ordinary files from your submodules. In very special cases you could handle the external repositories from the script without submodules but I would normally not recommend it.
Create a file bootstrap.sh containing:
#!/bin/sh
git submodule init
git submodule update

cp JRoboCom/jrobocom-core/src/main/resources/logback.xml .

Run this in a shell in your project directory:
$ git submodule add https://github.com/theHilikus/JRoboCom
$ git add .gitmodules bootstrap.sh
$ git commit -m "add a script to fetch logback.xml from the respective submodule"

Note that we are not adding the logback.xml file to Git, as it will be fetched from the submodule.
Instruct users of the repository to first run the script above. It will prepare their repositories for using submodules, will fetch the submodule data and will copy the file to its location. Sometimes there's already some sort of bootstrap script in the project.
Using a script to fetch a single file via git protocol
Found another solution for Git >= 1.7.9.5 using git archive.
Create a file bootstrap.sh containing:
#!/bin/sh
git archive --remote=https://github.com/theHilikus/JRoboCom master:JRoboCom/jrobocom-core/src/main/resources logback.xml | tar -x

Run this in a shell in your project directory:
$ git add bootstrap.sh
$ git commit -m "add a script to fetch logback.xml directly from the remote project"

Using a script to fetch a single file via HTTP
If the repository hosting service also serves the individual files via HTTP, you can simply use curl or wget to download them.
Create a file bootstrap.sh containing:
#!/bin/sh
curl -O https://raw.githubusercontent.com/theHilikus/JRoboCom/master/jrobocom-core/src/main/resources/logback.xml

Run this in a shell in your project directory:
$ git add bootstrap.sh
$ git commit -m "add a script to fetch logback.xml directly from github"

Notes on scripts fetching single files
You could also store the references in files with a specific extention (like *.url) or maintain the list of references in one file (like .references in your project directory) and build a more comprehensive script that goes through all the references and downloads the respective files.


[System] You are a helpful assistant.

[User] git-blame - Show what revision and author last modified each line of a file  --abbrev=<n>

[Assistant]
Instead of using the default 7+1 hexadecimal digits as the
abbreviated object name, use <m>+1 digits, where <m> is at
least <n> but ensures the commit object names are unique.
Note that 1 column
is used for a caret to mark the boundary commit.


[System] You are a helpful assistant.

[User]
'User is missing the Overall/Read permission' error with Jenkins GitHub OAuth Plugin

I'm using the github oauth plugin for our logins but for all of our users in the Organisation I get an error:
Access Denied

<user> is missing the Overall/Read permission

I have tried everything I can possibly think of to try to make this work and I'm probably going to fallback to making everyone an admin user, which i would prefer not to do.
Any advise would be appreciated.

[Assistant]
This is how I resolved the authentication problem:

Edit config.xml file, e.g.
sudo vi /var/lib/jenkins/config.xml

Change useSecurity element's value to false, e.g.
<useSecurity>false</useSecurity>

Remove authorizationStrategy block

Restart Jenkins: /etc/init.d/jenkins restart.
Access Jenkins through URL as usual and reconfigure security again.


[System] You are a helpful assistant.

[User]
How do I connect github to JIRA?
I've been trying to find a way to update JIRA when I commit to github.
It doesn't look like there are any service hooks to do it at github, but you never know, someone might have a ninja way, so I thought I'd ask.

[Assistant]
UPDATE
For integrating with Bitbucket, check out the following link:
Linking Bitbucket and GitHub accounts to JIRA
ORIGINAL POST
JIRA GitHub Connector is deprecated:

This plugin has been superseded by the JIRA DVCS Connector, which includes GitHub functionality.

So to connect Jira to github use JIRA DVCS Connector for Bitbucket and GitHub:

You can connect Bitbucket or GitHub accounts with JIRA using the free JIRA DVCS Connector plugin. This plugin comes with JIRA OnDemand.   For JIRA download users, this is a system plugin that you can install. Using the DVCS connector, you can:

Link all or a subset of your existing repositories (both public and private to JIRA).
Create new repositories and have them link automatically to JIRA.
Reference JIRA issues from DVCS commit message and have those commits appear in the issue's Commits tab in JIRA.
Transition issues through a JIRA OnDemand workflow (for example, Close, Reopen, and so forth)  using smart commit messages.

check out Using the JIRA DVCS Connector Plugin for more information.


[System] You are a helpful assistant.

[User]
Why can't I create an empty Pull Request for discussion prior to developing changes?

I want to branch from master and immediately create an empty Pull Request to discuss implementation details of a specific feature.
After selecting my branch and clicking "Pull Request", Github claims "Nothing to Compare" and doesn't offer any "Create Pull Request" button.
Github's own documentation on Flow states (click the right-arrow twice):

You can open a Pull Request at any point during the development process: when you have little or no code but want to share some screenshots or general ideas, when you're stuck and need help or advice, or when you're ready for someone to review your work.

But their own documentation on Pull Requests here states:

Pull requests can only be opened if there are differences between your branch and the upstream branch

I would like to utilise Github collaboration features with my team prior to committing changes to code.  As we understand it, Pull Requests are for code changes and discussion of implementation details (ie: the "solution"), while Issues are higher level, for discussing features/bugs (ie: the "problem").
Am I misunderstanding these things?
Edit:
Apparently I can circumvent the process by changing the branch with an empty commit:

git commit --allow-empty -m "make pull request"

but I am trying to better understand why my (default) decision to create an empty PR was wrong in the first place, and why their documentation appears contradictory.  Is there a strict "discuss code explicitly in PRs" policy or similar?  Is this a contentious issue?
Update
Github have released Draft Pull Requests, but (alas) they can't be created if the 2 branches are identical.

[Assistant]
The documentation talking about "no code" dates from... December 2013:

It is possible they changed their policy in the official documentation, which is up-to-date and apply to github.com as well as GitHub Enterprise.
So  you might want to contact GitHub support to mention this inaccuracy.


[System] You are a helpful assistant.

[User]
How to change the default target branch for merges in Gitlab

we are using Gitlab 8.10.1 with many groups and projects. Many of the projects happen to be forks of other projects.
Our problem is that whenever somebody opens a merge request for a project the default target branch is NOT the default branch of the project but from one very specific other project. Is there a way to override this setting somehow?
Just to make it clear, I know how to set the default branch of a project and those settings appear to be correct, however gitlab doesn't seem to use them when creating merge requests.
This issue is very annoying and has led to weird situations when people didn't pay attention and made merge requests with a completely different "master" as target.

[Assistant]
The default MR target depends on whether or not the repository is a GitLab fork.
Forks
If the repository is a GitLab fork, then the default MR target will be the default branch of the upstream repository. This relationship can be removed via the "Remove fork relationship" option on the Project settings page, after which the default MR target will be determined as normal for a non-fork repository (described below).
At time of writing, it is not possible to override the default MR target without removing the fork relationship, but that functionality has been requested in gitlab issue #14522.
Non-Forks
If the repository has no fork relationship, then the Default Branch setting on the Project settings page sets both (1) the default MR target, and (2) the HEAD reference of the repo on the GitLab server (which determines the branch that's checked out when the repo is cloned). Note that, due to a bug/quirk in git, problems can occur if a branch that was once the Default Branch is later deleted from GitLab.
At time of writing, it is not possible to change the default MR target independently of the Default Branch, but this functionality has been requested in gitlab issue #17909.


[System] You are a helpful assistant.

[User]
How can I visualize per-character differences in a unified diff file?
Say I get a patch created with git format-patch. The file is basically a unified diff with some metadata. If I open the file in Vim, I can see which lines have been modified, but I cannot see which characters in the changed lines differ. Does anyone know a way (in Vim, or some other free software that runs on Ubuntu) to visualize per-character differences?
A counter example where per-character diff is visualized is when executing vimdiff a b.
update Fri Nov 12 22:36:23 UTC 2010
diffpatch is helpful for the scenario where you're working with a single file.
update Thu Jun 16 17:56:10 UTC 2016
Check out diff-highlight in git 2.9. This script does exactly what I was originally seeking.

[Assistant]
In git, you can merge without committing. Merge your patch first, then do:
git diff --word-diff-regex=.

Note the dot after the equals sign.


[System] You are a helpful assistant.

[User] git-rebase - Reapply commits on top of another base tip  <upstream>

[Assistant]
Upstream branch to compare against.  May be any valid commit,
not just an existing branch name. Defaults to the configured
upstream for the current branch.


[System] You are a helpful assistant.

[User]
Table divider/bold row line in GitLab Flavored Markdown

I have made a long table in GitLab, but would like to divide the rows within the table to highlight different groups. I would wish for a bold table row line as a divider or different background colors for the different groups.
From what I have read, it does not seem to be possible by using only the GitLab Flavored Markdown syntax, and the closest I have come is to use an empty row as a divider, but I am not fully satisfied with that solution.
| ---- |Precision | Recall | F1 | Support |
| ---- | ---- | ---- | ---- |---- | ---- |
| Group 1 |0.5 | 0.6 | 0.55 | 5 |
| Group 1 |0.5 | 0.6 | 0.55 | 5 |
|      |    |     |      |   |
| Group 2 |0.5 | 0.6 | 0.55 | 5 |
| Group 2 |0.5 | 0.6 | 0.55 | 5 |

results in this:

Are there any other ways to do this more nicely? Perhaps with html/css?

[Assistant]
Have a Look at the gitlab markdown guide. A bold line separator isn't possible but the guide describes some options you can try to make your Groups differ:
mix html and markdown
you can add html elements in your markdown. You could use that to color your groups differently
styles
gitlab markdown allows you to define styles in your document:
<style>
  .purple {
    color:inherit;
  }
  .purple:hover {
    color:rgb(107,79,187);
  }
</style>

You can then apply this style like this:
Hey! Hover the cursor over me and guess what?! :)
{: .purple}

Maybe those options help you


[System] You are a helpful assistant.

[User] git - the stupid content tracker  gitformat-pack

[Assistant] Git pack format


[System] You are a helpful assistant.

[User]
.gitlab-ci stages execution order

I have this .gitlab-ci.yml file:
stepA:
  script:
    - echo "A"
deploy:
  script:
    - echo "1"
stepB:
  script:
    - echo "B"

How can I set which stage should be run in first ?
Some jobs can be run in parallel by multiple gitlab runners.
I just want to be sure step A to B are finished before running deploy stage

[Assistant]
This is exactly what stages is for. You are using the word "stage" here when actually describing a "job".
Jobs in the same stage may be run in parallel (if you have the runners to support it) but stages run in order.
First define your 2 stages at the top level of the .gitlab-ci.yml:
stages:
  - build
  - dist

Then on each job, specify the stage it belongs to:
stepA:
  stage: build
  script:
    - echo "A"
deploy:
  stage: dist
  script:
    - echo "1"
stepB:
  stage: build
  script:
    - echo "B"

Now stepA and stepB will run first (in any order or even in parallel) followed by deploy provided the first stage succeeds.


[System] You are a helpful assistant.

[User]
Can you have additional .gitignore per directory within a single repo?
Can you create a .gitignore file in a directory that only applies to files (and directories) within that directory?

[Assistant] Yes, you can.  Try it, it works fine.  Put a .gitignore in the root of your repo, and put another .gitignore with additional things to ignore in a subdirectory.


[System] You are a helpful assistant.

[User]
automatically stash save/pop changes on git rebase?
my git workflow uses rebase a lot. I always fetch upstream changes (the main repo i forked from) and then merge to my branches, and then rebase to remove useless (to me :D) merge commits and tree splits.
one thing on this workflow that annoys me is:
$ git rebase upstream/master
Cannot rebase: You have unstaged changes.
Please commit or stash them.

$ git stash
Saved working directory and index state WIP on cc: abc1234 Merge remote-tracking branch 'upstream/master' into local_branch
HEAD is now at abc1234 Merge remote-tracking branch 'upstream/master' into local_branch

$ git rebase upstream/master
First, rewinding head to replay your work on top of it...
Applying: awesome code change

$ git stash pop

so here we have 4 commands, 1=failed rebase, 2=stash, 3=rebase, 4=stash pop. anything but 3 is just mindless work.
So, the question is: What is the most recommended way of automating it? an alias to run git stash/rebase/pop everytime? some git config that forces rebase to stash or treat it as another commit to reapply afterwards? something else?

[Assistant]
Edit: As of Git version 1.8.4, but with an important side bug fixed in Git version 2.0.1, git rebase now has --autostash.  You can configure git rebase to use --autostash by default as well, with git config --global rebase.autoStash true.  Please note the following sentence from the documentation:

However, use with care: the final stash
   application after a successful rebase might result in non-trivial
   conflicts.

(I still prefer to just make commits.)
TL;DR answer: just make a commit (then unmake it later)
It may help you to realize that git stash is really just git commit (in a more complicated form, which commits the index first, then the work-tree—when you apply a stash, you can maintain the separation of index and work-tree, or combine them into just a work-tree change).
What makes a stash special is that the commits it makes—the two or, with -u or -a, even three commits—are made in an unusual form (as a merge commit that's not really a merge) and not placed on any branch (instead, the special refs/stash reference is used to retain and find them).
Since they're not on a branch, rebase does not touch them, and in your workflow, it's the git stash pop that brings the work-tree changes into your new work-tree.  However, if you make your own (normal) commit, on a branch, and rebase and include that commit, this normal commit will be rebased along with any others.  We'll get to one last problem in a moment; for now, let's draw this up, as a series of commits that do (or don't) get rebased:
... do some work ...
... make some commits ...
... more work ...
... do something that causes upstream/master to update, such as git fetch upstream
$ git stash

At this point, here's what you have:
... - o - * - A - B - C     <-- HEAD=master
           \          |\
            \         i-w   <-- stash
             \
              @-@-@         <-- upstream/master

Here, A, B, and C are your commits (I'll assume you've made 3), all on branch master.  The i-w hanging off commit C is your stash, which is not on the branch, but is still a two-commit "git stash bag" and is actually attached to your latest commit (C).  The @ commits (there might be just one) are the new upstream commits.
(If you have made no commits, your stash-bag hangs off commit *, and your current branch points to commit *, so that git rebase has no work to do other than move your current branch pointer forward.  Everything works out the same, in this case, but I'll assume there are some commits.)
Now you run git rebase upstream/master.  This copies your commits to new commits, with new IDs and new parent IDs, so that they sit atop the last @.  The stash-bag does not move, so the result looks like this:
... - o - * - A - B - C     [abandoned, except for the stash]
           \          |\
            \         i-w   <-- stash
             \
              @-@-@         <-- upstream/master
                   \
                    A'-B'-C'   <-- HEAD=master

You now use git stash pop, which restores the i/w stuff as work-tree changes, erasing the stash label (more precisely, popping it so that stash@{1}, if it exists, is now stash, and so on).  That releases the last references to the original A - B - C chain, and means we don't need the i-w bit either, which lets us redraw this as the much simpler:
... - @            <-- upstream/master
       \
        A'-B'-C'   <-- HEAD=master plus work tree changes

Now let's draw what happens if, instead of git stash save, you just do a git commit -a (or git add and git commit without -a) to create an actual commit D.  You start with:
... - o-*-A-B-C-D   <-- HEAD=master
         \
          @-@-@     <-- upstream/master

Now you git rebase upstream/master, which copies A through D to place them at the end of the last @, and you have this:
... - o-*-@-@-@     <-- upstream/master
               \
                A'-B'-C'-D'   <-- HEAD=master

The only problem is that you have this one unwanted extra commit D (well, D' now), instead of uncommitted work-tree changes.  But this is trivially undone with git reset to step back one commit.  We can use a --mixed reset—the default—to get the index (staging area) re-set too, so as to "un-add" all the files, or if you want them to stay git add-ed, a --soft reset.  (Neither affects the resulting commit graph, only the index state is different.)
git reset --mixed HEAD^   # or leave out `--mixed` since it's the default

Here's what that looks like:
... - o-*-@-@-@     <-- upstream/master
               \
                A'-B'-C'      <-- HEAD=master
                        \
                         D'   [abandoned]

You might think this is inefficient, but when you use git stash you're actually making at least two commits, which you then abandon later when you git stash pop them.  The real difference is that by making temporary, not-for-publication commits, you get those automatically rebased.
Don't be afraid of temporary commits
There's a general rule with git: make lots of temporary commits, to save your work as you go.  You can always rebase them away later.  That is, instead of this:
... - * - A - B - C   <-- mybranch

where A, B, and C are perfect and final commits atop commit * (from someone else or earlier published stuff), make this:
... - * - a1 - a2 - b1 - a3 - b2 - a4 - b3 - c1 - b4 - c2 - c3

where a1 is an initial stab at A, a2 fixes a bug in a1, b1 is an initial attempt to make b work, a3 is from realizing that b1 requires A to be different after all, b2 fixes a bug in b1, a4 fixes a bug in a3's change to a2, and b3 is what b1 should have done; then c1 is an initial attempt at C, b4 is another fix to b1, c2 is a refinement, and so on.
Let's say that after c3 you think it's mostly ready.  Now you run git rebase -i origin/master or whatever, shuffle the pick lines to get a1 through a4 into order, b1 through b4 into order, and c1 through c3 into order, and let the rebase run.  Then you fix any conflicts and make sure stuff is still right, then you run another git rebase -i to collapse all four a versions into A, and so on.
When you're all done, it looks like you created a perfect A the first time (or maybe with a4 or some other one depending on which commits you keep and which ones you drop and whether you re-set any time stamps in things).  Other people may not want or need to see your intermediate work—though you can retain it, not combining commits, if that's useful.  Meanwhile you never need to have uncommitted stuff that you have to rebase, because you just have commits of partial stuff.
It does help to give these commits names, in the one-line commit text, that will guide your later rebase work:
git commit -m 'temp commit: work to enable frabulator, incomplete'

and so on.


[System] You are a helpful assistant.

[User] git-diff - Show changes between commits, commit and working tree, etc  --name-only

[Assistant]
Show only names of changed files. The file names are often encoded in UTF-8.
For more information see the discussion about encoding in the git-log manual page.


[System] You are a helpful assistant.

[User] git-show - Show various types of objects  %gD

[Assistant]
reflog selector, e.g., refs/stash@{1} or refs/stash@{2
minutes ago} ; the format follows the rules described for the -g option. The portion before the @ is the refname as
given on the command line (so git log -g refs/heads/master would yield refs/heads/master@{0} ).


[System] You are a helpful assistant.

[User]
How to exclude certain directories/files from git grep search
Is there a way to exclude certain paths/directories/files when searching a git repository using git grep? Something similar to the --exclude option in the normal grep command?
I need to use git grep because using grep directly runs too slowly on large git repositories.

[Assistant]
In git 1.9.0 the "magic word" exclude was added to pathspecs. So if you want to search for foobar in every file except for those matching *.java you can do:
git grep foobar -- ':(exclude)*.java'

Or using the ! "short form" for exclude:
git grep foobar -- ':!*.java'

Note that in git versions up to v2.12, when using an exclude pathspec, you must have at least one "inclusive" pathspec. In the above examples you'd want to add ./* (recursively include everything under the current directory) somewhere after the -- as well. In git v2.13 this restriction was lifted and git grep foobar -- ':!*.java' works without the ./*.
There's a good reference for all the "magic words" allowed in a pathspec at git-scm.com (or just git help glossary).


[System] You are a helpful assistant.

[User]
Importing private repo to other private repo Git

I have a private repo on git that I would love to import in another private repo. When I try to import it, I log in with my account and then this message Your old project requires credentials for read-only access. We will only temporarily store them for importing.
continue to pop up and I cannot import the repo. Someone could help?

[Assistant] I had the same problem and was able to resolve it by using the Personal Access Token (token access to Private Repositories) instead of the password. Take a look at this from the github community which gives a bit more detail (the answer from hobojoe1848): https://github.community/t/import-repository-not-working/2044/4


[System] You are a helpful assistant.

[User] git-show - Show various types of objects  --show-notes-by-default

[Assistant]
Show the default notes unless options for displaying specific
notes are given.


[System] You are a helpful assistant.

[User]
Git removing upstream from local repository
I am working with a ruby on rails application and I am trying to sync a fork. It is worth mentioning that I am also on a Mac. I committed the following action:
$ git remote -v

to get a view of my local repository. I messed up when trying to go upstream:
$ git remote add upstream https://github.com/foo/repo.git

When I should have capitalized Foo:
$ git remote add upstream https://github.com/Foo/repos.git

The question is how do I remove the upstream because every time I try and change this it comes back with creating a fatal error?

[Assistant]
Using git version 1.7.9.5 there is no "remove" command for remote. Use "rm" instead.
$ git remote rm upstream
$ git remote add upstream https://github.com/Foo/repos.git

or, as noted in the previous answer, set-url works.
I don't know when the command changed, but Ubuntu 12.04 shipped with 1.7.9.5.
edit: a few people seem to have run into a situation where they do not have an "upstream" remote. execute cat .git/config and look at the name of the remote(s). (if on windows and not using powershell you can use type .git/config.)
the output will show the remotes configured for your git repo, e.g.,
[remote "origin"]

substitute the name of the remote you wish to remove as:
$ git remote rm origin

if you don't have the "upstream" remote, you can't remove it.


[System] You are a helpful assistant.

[User] git-am - Apply a series of patches from a mailbox  (<mbox>|<Maildir>)…

[Assistant]
The list of mailbox files to read patches from. If you do not
supply this argument, the command reads from the standard input.
If you supply directories, they will be treated as Maildirs.


[System] You are a helpful assistant.

[User]
Accidentally branched off of the wrong branch, and when I want to merge into the master I have to merge both branches
So I created a branch off of another branch I was already creating, and now when I try to merge the branches into master, I have run into the situation where I have to merge both branches.
Here is a diagram

Master->

 ->Branch 1  -> Branch 2

I want to be able to merge just the changes on branch 2 onto master without having to merge the changes on Branch 1 if that makes sense. I looked into reset and revert, but it seems like these things will delete all the changes I made with branch 2. Any ideas?
Thanks

[Assistant]
Try git rebase --onto with the following syntax:
To put branch2's changes on to the master without including branch1's
git rebase --onto master branch1 branch2

Relevant output from git help rebase:

Here is how you would transplant a topic branch based on one branch to another, to
  pretend that you forked the topic branch from the latter branch, using rebase --onto.
First let’s assume your topic is based on branch next. For example, a feature
  developed in topic depends on some functionality which is found in next.
              o---o---o---o---o  master
                   \
                    o---o---o---o---o  next
                                     \
                                      o---o---o  topic

We want to make topic forked from branch master; for example, because the functionality
  on which topic depends was merged into the more stable master branch.
  We want our tree to look like this:
              o---o---o---o---o  master
                  |            \
                  |             o'--o'--o'  topic
                   \
                    o---o---o---o---o  next

We can get this using the following command:
git rebase --onto master next topic

Keep in mind the risks and pitfalls of rebasing, mentioned here:
 http://git-scm.com/book/en/Git-Branching-Rebasing


[System] You are a helpful assistant.

[User]
Find files in git repo over x megabytes, that don't exist in HEAD
I have a Git repository I store random things in. Mostly random scripts, text files, websites I've designed and so on.
There are some large binary files I have deleted over time (generally 1-5MB), which are sitting around increasing the size of the repository, which I don't need in the revision history.
Basically I want to be able to do..
me@host:~$ [magic command or script]
aad29819a908cc1c05c3b1102862746ba29bafc0 : example/blah.psd : 3.8MB : 130 days old
6e73ca29c379b71b4ff8c6b6a5df9c7f0f1f5627 : another/big.file : 1.12MB : 214 days old

..then be able to go though each result, checking if it's no longer required then removing it (probably using filter-branch)

[Assistant]
This is an adaptation of the git-find-blob script I posted previously:
#!/usr/bin/perl
use 5.008;
use strict;
use Memoize;

sub usage { die "usage: git-large-blob <size[b|k|m]> [<git-log arguments ...>]\n" }

@ARGV or usage();
my ( $max_size, $unit ) = ( shift =~ /^(\d+)([bkm]?)\z/ ) ? ( $1, $2 ) : usage();

my $exp = 10 * ( $unit eq 'b' ? 0 : $unit eq 'k' ? 1 : 2 );
my $cutoff = $max_size * 2**$exp;

sub walk_tree {
    my ( $tree, @path ) = @_;
    my @subtree;
    my @r;

    {
        open my $ls_tree, '-|', git => 'ls-tree' => -l => $tree
            or die "Couldn't open pipe to git-ls-tree: $!\n";

        while ( <$ls_tree> ) {
            my ( $type, $sha1, $size, $name ) = /\A[0-7]{6} (\S+) (\S+) +(\S+)\t(.*)/;
            if ( $type eq 'tree' ) {
                push @subtree, [ $sha1, $name ];
            }
            elsif ( $type eq 'blob' and $size >= $cutoff ) {
                push @r, [ $size, @path, $name ];
            }
        }
    }

    push @r, walk_tree( $_->[0], @path, $_->[1] )
        for @subtree;

    return @r;
}

memoize 'walk_tree';

open my $log, '-|', git => log => @ARGV, '--pretty=format:%T %h %cr'
    or die "Couldn't open pipe to git-log: $!\n";

my %seen;
while ( <$log> ) {
    chomp;
    my ( $tree, $commit, $age ) = split " ", $_, 3;
    my $is_header_printed;
    for ( walk_tree( $tree ) ) {
        my ( $size, @path ) = @$_;
        my $path = join '/', @path;
        next if $seen{ $path }++;
        print "$commit $age\n" if not $is_header_printed++;
        print "\t$size\t$path\n";
    }
}


[System] You are a helpful assistant.

[User] git - the stupid content tracker  git-count-objects

[Assistant] Count unpacked number of objects and their disk consumption


[System] You are a helpful assistant.

[User] git-rev-list - Lists commit objects in reverse chronological order  --graph

[Assistant]
Draw a text-based graphical representation of the commit history
on the left hand side of the output.  This may cause extra lines
to be printed in between commits, in order for the graph history
to be drawn properly.
Cannot be combined with --no-walk . This enables parent rewriting, see History Simplification above. This implies the --topo-order option by default, but the --date-order option may also be specified.


[System] You are a helpful assistant.

[User] git-am - Apply a series of patches from a mailbox  --quoted-cr=<action>

[Assistant] This flag will be passed down to git mailinfo (see git-mailinfo ).


[System] You are a helpful assistant.

[User]
How to avoid merge commits from Git pull when pushing to remote
I have a repository and some local changes to commit.
Before committing, I pulled the changes onto my local using Egit in Eclipse.
It creates a merge commit and I submit my commit over it.
Now when I am trying to push to origin, it is showing that it will push my commit as well as merge commit.
But ideally, merge commit should not be a part of remote repository.
How to avoid this?

[Assistant]
Use rebase option whenever you pull from remote repository. Please follow the below steps,

Commit your changes - It will create a new commit in your local.
Now do git pull --rebase <remote-name> <branch-name>.
Basically the rebase take out your commits that you committed on the current branch HEAD as a patch. Then it will apply all the remote commits on top of HEAD and then applies your commits on top of it.
So best practice is to commit changes then pull remote commits by using rebase option.


[System] You are a helpful assistant.

[User]
Rebasing remote branches in Git
I am using an intermediate Git repository to mirror a remote SVN repository, from which people can clone and work on. The intermediate repository has its master branch rebased nightly from the upstream SVN, and we are working on feature branches. For example:
remote:
  master

local:
  master
  feature

I can successfully push my feature branch back to the remote, and end up with what I expect:
remote:
  master
  feature

local:
  master
  feature

I then re-setup the branch to track the remote:
remote:
  master
  feature

local:
  master
  feature -> origin/feature

And all is well. What I would like to do from here is to rebase the feature branch to the master branch on the remote, but I would like to do this from my local machine. I'd like to be able to do:
git checkout master
git pull
git checkout feature
git rebase master
git push origin feature

To keep the remote feature branch up-to-date with the remote master. However, this method causes Git to complain:
To <remote>
 ! [rejected]        feature -> feature (non-fast-forward)
error: failed to push some refs to '<remote>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

git pull does the trick but causes a merge commit that I'd like to avoid. I'm concerned that the message states feature -> feature rather than feature -> origin/feature but this may just be a presentation thing.
Am I missing something, or going about this in completely the wrong way? It's not critical to avoid doing the rebase on the remote server, but it makes fixing any merge conflicts from the rebase much harder.

[Assistant]
It comes down to whether the feature is used by one person or if others are working off of it.
You can force the push after the rebase if it's just you:
git push origin feature -f

However, if others are working on it, you should merge and not rebase off of master.
git merge master
git push origin feature

This will ensure that you have a common history with the people you are collaborating with.
On a different level, you should not be doing back-merges. What you are doing is polluting your feature branch's history with other commits that don't belong to the feature, making subsequent work with that branch more difficult - rebasing or not.
This is my article on the subject called branch per feature.


[System] You are a helpful assistant.

[User] git-revert - Revert some existing commits  -n  --no-commit

[Assistant]
Usually the command automatically creates some commits with
commit log messages stating which commits were
reverted.  This flag applies the changes necessary
to revert the named commits to your working tree
and the index, but does not make the commits.  In addition,
when this option is used, your index does not have to match
the HEAD commit.  The revert is done against the
beginning state of your index. This is useful when reverting more than one commits'
effect to your index in a row.


[System] You are a helpful assistant.

[User]
Using git, how do I ignore a file in one branch but have it committed in another branch?
I've got a project that I'm deploying to Heroku.  The source code tree includes a bunch of mp3 files (the website will be for a recording project I was heavily involved with).
I'd like to put the source code for it up on GitHub, but GitHub has a 300 MB limit on their free accounts.  I don't want to use 50 MB of my limit on a bunch of mp3 files.  Obviously, I could add them to the .gitignore file to keep them out of my repo.
However, I deploy to Heroku using git push heroku.  The mp3 files must be present in the branch I push to Heroku so that they get get deployed.
Ideally, I'd like to .gitignore the mp3 files in my local master branch so that when I push that to GitHub, the mp3s are not included.  Then I'd keep a local production branch that has the mp3s committed rather than ignored.  To deploy, I would merge master into production, and then push the production branch to Heroku.
I can't get this to work right.
Here's an example of what I'm trying to do...
$ git init git-ignore-test
$ cd git-ignore-test
$ echo "*.ignored" >> .gitignore
$ git add .gitignore && git commit -m "Ignore .ignored files"
$ touch Foo.ignored

At this point, Foo.ignored is ignored in my master branch, but it's still present, so my project can use it.
$ git checkout -b unignored
$ cat /dev/null > .gitignore
$ git add Foo.ignored .gitignore && git commit -m "Unignore .ignored files"

Now I've got a branch with these files committed, as I want.  However, when I switch back to my master branch, Foo.ignored is gone.
Anyone got any suggestions for a better way to set this up?
Edit: just to clarify, I want the mp3 files to be present in both branches so that when I run the site locally (using either branch) the site works.  I just want the files ignored in one branch so when I push to GitHub they are not pushed as well.  Usually .gitignore works well for this kind of thing (i.e. keeping a local copy of a file that does not get included in a push to a remote), but when I switch to the branch with the files checked in, and then back to the branch with the files ignored, the files vanish.

[Assistant]
This solution appears to work only for certain, patched versions of git. See a new answer pointing to workarounds and another answer and subsequent comments for a hint which versions may work.

I wrote a blog post on how to effectively use the excludesfile for different branches, like one for public github and one for heroku deployment.
Here's the quick and dirty:
$ git branch public_viewing
$ cd .git/
$ touch info/exclude_from_public_viewing
$ echo "path/to/secret/file" > info/exclude_from_public_viewing

then in the .git/config file add these lines:
[core]
excludesfile = +info/exclude

[branch "public_viewing"]
excludesfile = +info/exclude_from_public_viewing

Now all the global ignore stuff is in the info/exclude file and the branch specific is in the info/exclude_from_public_viewing
http://cogniton-mind.tumblr.com/post/1423976659/howto-gitignore-for-different-branches


[System] You are a helpful assistant.

[User] git-diff - Show changes between commits, commit and working tree, etc  -p  -u  --patch

[Assistant]
Generate patch (see Generating patch text with -p ).
This is the default.


[System] You are a helpful assistant.

[User]
Calculate RSA key fingerprint

I need to do the SSH key audit for GitHub, but I am not sure how do find my RSA key fingerprint. I originally followed a guide to generate an SSH key on Linux.
What is the command I need to enter to find my current RSA key fingerprint?

[Assistant]
Run the following command to retrieve the SHA256 fingerprint of your SSH key (-l means "list" instead of create a new key, -f means "filename"):
$ ssh-keygen -lf /path/to/ssh/key

So for example, on my machine the command I ran was (using RSA public key):
$ ssh-keygen -lf ~/.ssh/id_rsa.pub
2048 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff /Users/username/.ssh/id_rsa.pub (RSA)

To get the GitHub (MD5) fingerprint format with newer versions of ssh-keygen, run:
$ ssh-keygen -E md5 -lf <fileName>

Bonus information:
ssh-keygen -lf also works on known_hosts and authorized_keys files.
To find most public keys on Linux/Unix/OS X systems, run
$ find /etc/ssh /home/*/.ssh /Users/*/.ssh -name '*.pub' -o -name 'authorized_keys' -o -name 'known_hosts'

(If you want to see inside other users' homedirs, you'll have to be root or sudo.)
The ssh-add -l is very similar, but lists the fingerprints of keys added to your agent. (OS X users take note that magic passwordless SSH via Keychain is not the same as using ssh-agent.)


[System] You are a helpful assistant.

[User]
Git ignore local file changes
I've tried both
git update-index --assume-unchanged config/myconfig

and
editing .git/info/exclude and adding config/myconfig
however when I do git pull I always get:

Updating 0156abc..1cfd6a5
  error: Your local changes to the following files would be overwritten by merge:
      config/myconfig
  Please, commit your changes or stash them before you can merge.
  Aborting

What am I missing?

[Assistant]
git pull wants you to either remove or save your current work so that the merge it triggers doesn't cause conflicts with your uncommitted work. Note that you should only need to remove/save untracked files if the changes you're pulling create files in the same locations as your local uncommitted files.
Remove your uncommitted changes
Tracked files
git checkout -f

Untracked files
git clean -fd

Save your changes for later
Tracked files
git stash

Tracked files and untracked files
git stash -u

Reapply your latest stash after git pull:
git stash pop


[System] You are a helpful assistant.

[User]
GitLab CI get last artifact

I'm trying to get the latest build artifact using curl. Here's what I've tried.
First, get last pipeline id:
curl -v -H "Content-Type: application/json" -H "PRIVATE-TOKEN: <my-token-here>" https://<project>/api/v4/projects/<project>/pipelines?per_page=1&page=1

Next, get job id based on pipeline id just obtained before:
curl -sS --header "PRIVATE-TOKEN: <my-token-here>" "https://[redacted,host]/api/v4/projects/[redacted,project]/pipelines/<pipeline-id>/jobs" | jq '.[] | select(.name == "build-assets" and .status == "success" and .artifacts_file != null) | .id'

Finally, get the artifacts to build.zip based on job id:
curl -sS --header "PRIVATE-TOKEN: <my-token-here>" "https://[redacted,host]/api/v4/projects/[redacted, project]/jobs/<JOB_ID>/artifacts" > build.zip

These steps above do work, but I have to hit three endpoints (and process the JSON response for each step).
I also read in GitLab's documentation, that there's a single endpoint available for this. So I also tried this:
curl -sS --header "PRIVATE-TOKEN: <my-token-here>" "https://<url>/<namespace>/<project>/-/jobs/artifacts/<refs>/download?job=<job_name>"

but this always redirects me to the login page, saying this:
You are being <a href="https://<url>/users/sign_in">redirected.

Is there any simpler way to do this task? Or how to use the endpoint that is described on the documentation above propeprly?

[Assistant]
Scripting artifacts download
Two methods. The second one is the solution in your use case.
From a Public project
curl -sS "https://<url>/<namespace>/<project>/-/jobs/artifacts/<refs>/download?job=<job_name>"

Note : I gess you can't use your personal token here, it's reserved to API usage bellow.
Gitlab doc : downloading the latest artifacts
From a Private project
curl -L --header "PRIVATE-TOKEN: 123456abcdef" "https://gitlab.com/api/v4/projects/awesome-organization%2Fawesome-group%2Fowesome-project/jobs/artifacts/master/download?job=publish-release"

Note1 : the -l tells curl to follow the redirection since gitlab will move you to its google storage location.
Note2 : the %2F value is the url-encoded replacement for the slash if your project is part or a group or subgroup in gitlab.
Gitlab api doc : downloading the latest artifacts


[System] You are a helpful assistant.

[User]
Are Git's pack files deltas rather than snapshots?
One of the key differences between Git and most other version control systems is that the others tend to store commits as a series of deltas - changesets between one commit and the next. This seems logical, since it's the smallest possible amount of information to store about a commit. But the longer the commit history gets, the more calculation it takes to compare ranges of revisions.
By contrast, Git stores a complete snapshot of the whole project in each revision. The reason this doesn't make the repo size grow dramatically with each commit is each file in the project is stored as a file in the Git subdirectory, named for the hash of its contents. So if the contents haven't changed, the hash hasn't changed, and the commit just points to the same file. And there are other optimizations as well.
All this made sense to me until I stumbled on this information about pack files, into which Git puts data periodically to save space:

In order to save that space, Git
  utilizes the packfile. This is a
  format where Git will only save the
  part that has changed in the second
  file, with a pointer to the file it is
  similar to.

Isn't this basically going back to storing deltas? If not, how is it different? How does this avoid subjecting Git to the same problems other version controls systems have?
For example, Subversion uses deltas, and rolling back 50 versions means undoing 50 diffs, whereas with Git you can just grab the appropriate snapshot. Unless git also stores 50 diffs in the packfiles... is there some mechanism that says "after some small number of deltas, we'll store a whole new snapshot" so that we don't pile up too large a changeset? How else might Git avoid the disadvantages of deltas?

[Assistant]
Summary:
Git’s pack files are carefully constructed to effectively use disk caches and
provide “nice” access patterns for common commands and for reading recently referenced
objects.

Git’s pack file
format is quite flexible (see Documentation/technical/pack-format.txt,
or The Packfile in The Git Community Book).
The pack files store objects in two main
ways: “undeltified” (take the raw object data and deflate-compress
it), or “deltified” (form a delta against some other object then
deflate-compress the resulting delta data). The objects stored in
a pack can be in any order (they do not (necessarily) have to be
sorted by object type, object name, or any other attribute) and
deltified objects can be made against any other suitable object of the same type.
Git’s pack-objects command uses several heuristics to
provide excellent locality of reference for common
commands. These heuristics control both the selection of base
objects for deltified objects and the order of the objects. Each
mechanism is mostly independent, but they share some goals.
Git does form long chains of delta compressed objects, but the
heuristics try to make sure that only “old” objects are at the ends of
the long chains. The delta base cache (whose size is controlled by the
core.deltaBaseCacheLimit configuration variable) is automatically
used and can greatly reduce the number of “rebuilds” required for
commands that need to read a large number of objects (e.g. git log
-p).
Delta Compression Heuristic
A typical Git repository stores a very large number of objects, so
it can not reasonably compare them all to find the pairs (and
chains) that will yield the smallest delta representations.
The delta base selection heuristic is based on the idea that the
good delta bases will be found among objects with similar filenames
and sizes. Each type of object is processed separately (i.e. an
object of one type will never be used as the delta base for an
object of another type).
For the purposes of delta base selection, the objects are sorted (primarily) by
filename and then size. A window into this sorted list is used to limit
the number of objects that are considered as potential delta bases.
If a “good enough”1 delta representation is not found for an object
among the objects in its window, then the object will not be delta
compressed.
The size of the window is controlled by the --window= option of
git pack-objects, or the pack.window configuration variable. The
maximum depth of a delta chain is controlled by the --depth=
option of git pack-objects, or the pack.depth configuration
variable. The --aggressive option of git gc greatly enlarges
both the window size and the maximum depth to attempt to create
a smaller pack file.
The filename sort clumps together the objects for entries with with
identical names (or at least similar endings (e.g. .c)). The size
sort is from largest to smallest so that deltas that remove data are
preferred to deltas that add data (since removal deltas have shorter
representations) and so that the earlier, larger objects (usually
newer) tend to be represented with plain compression.
1
What qualifies as “good enough” depends on the size of the object in question and its potential delta base as well as how deep its resulting delta chain would be.
Object Ordering Heuristic
Objects are stored in the pack files in a “most recently referenced”
order. The objects needed to reconstruct the most recent history are
placed earlier in the pack and they will be close together. This
usually works well for OS disk caches.
All the commit objects are sorted by commit date (most recent first)
and stored together. This placement and ordering optimizes the disk
accesses needed to walk the history graph and extract basic commit
information (e.g. git log).
The tree and blob objects are stored starting with the tree from the
first stored (most recent) commit. Each tree is processed in a depth
first fashion, storing any objects that have not already been
stored. This puts all the trees and blobs required to reconstruct
the most recent commit together in one place. Any trees and blobs that
have not yet been saved but that are required for later commits are
stored next, in the sorted commit order.
The final object ordering is slightly affected by the delta base selection
in that if an object is selected for delta representation and its base object
has not been stored yet, then its base object is stored immediately before the
deltified object itself. This prevents likely disk cache misses due to the
non-linear access required to read a base object that would have “naturally” been
stored later in the pack file.


[System] You are a helpful assistant.

[User] git-log - Show commit logs  --skip=<number>

[Assistant] Skip number commits before starting to show the commit output.


[System] You are a helpful assistant.

[User]
Github Markdown Same Page Link

Let's say I have two points within the same git hub wiki page, which for this we'll call place 1 and place 2.
##Title

###Place 1

Hello, this is some text to fill in this, [here](place2), is a link to the second place.

###Place 2

Place one has the fun times of linking here, but I can also link back [here](place1).

An alternative is a ToC.
##Title
[ToC]
###Place 1
###Place 2

Is there any way to do this?  Note - seen this so I'll assume it's on topic.  Also, that deals with going between files, this one deals with going between the same file.

[Assistant]
This works on Github:
## Title

### Place 1

Hello, this is some text to fill in this, [here](#place-2), is a link to the second place.

### Place 2

Place one has the fun times of linking here, but I can also link back [here](#place-1).

### Place's 3: other example

Place one has the fun times of linking here, but I can also link back [here](#places-3-other-example).

Summary of the conversion rules:

punctuation marks will be dropped
leading white spaces will be dropped
upper case will be converted to lower
spaces between letters will be converted to -

A good example document with plenty of links and formatting is LivingSocial API Design Guide


[System] You are a helpful assistant.

[User]
git pull without remotely compressing objects
I have a repository full of zip files, re-compressing theses files will be a waste of time.
I've tried to set core.compression = 0 on the remote and the local copy without success
git config core.compression 0
git config core.loosecompression 0

git pull still do
remote: Counting objects: 23, done.
remote: Compressing objects: ...

[Assistant]
The time problem I had was caused by delta compression.
The solution for me was
echo '*.zip -delta' > .gitattributes
git gc

I will quote this excellent response
from Re: serious performance issues with images, audio files, and other "non-code" data:

Git does spend a fair bit of time in zlib for some workloads, but it
should not create problems on the order of minutes.
For pushing and pulling, you're probably seeing delta compression,
which can be slow for large files
 core.compression 0   # Didn't seem to work.

That should disable zlib compression of loose objects and objects
within packfiles. It can save a little time for objects which won't
compress, but you will lose the size benefits for any text files.
But it won't turn off delta compression, which is what the
"compressing..." phase during push and pull is doing. And which is
much more likely the cause of slowness.
 pack.window 0

It sets the number of other objects git will consider when doing delta
compression. Setting it low should improve your push/pull times. But
you will lose the substantial benefit of delta-compression of your
non-image files (and git's meta objects). So the "-delta" option above
for specific files is a much better solution.
 echo '*.jpg -delta' >> .gitattributes

Also, consider repacking your repository, which will generate a
packfile that will be re-used during push and pull.

Note that the settings have to be made on the repo you are fetching/pulling from, not the one you are fetching/pulling to.


[System] You are a helpful assistant.

[User] git-filter-branch - Rewrite branches

[Assistant]
EXAMPLES Suppose you want to remove a file (containing confidential information
or copyright violation) from all commits: git filter-branch --tree-filter 'rm filename' HEAD However, if the file is absent from the tree of some commit,
a simple rm filename will fail for that tree and commit.
Thus you may instead want to use rm -f filename as the script. Using --index-filter with git rm yields a significantly faster
version.  Like with using rm filename , git rm --cached filename will fail if the file is absent from the tree of a commit.  If you
want to "completely forget" a file, it does not matter when it entered
history, so we also add --ignore-unmatch : git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD Now, you will get the rewritten history saved in HEAD. To rewrite the repository to look as if foodir/ had been its project
root, and discard all other history: git filter-branch --subdirectory-filter foodir -- --all Thus you can, e.g., turn a library subdirectory into a repository of
its own.  Note the -- that separates filter-branch options from
revision options, and the --all to rewrite all branches and tags. To set a commit (which typically is at the tip of another
history) to be the parent of the current initial commit, in
order to paste the other history behind the current history: git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD (if the parent string is empty - which happens when we are dealing with
the initial commit - add graftcommit as a parent).  Note that this assumes
history with a single root (that is, no merge without common ancestors
happened).  If this is not the case, use: git filter-branch --parent-filter \
	'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD or even simpler: git replace --graft $commit-id $graft-id
git filter-branch $graft-id..HEAD To remove commits authored by "Darl McBribe" from the history: git filter-branch --commit-filter '
	if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
	then
		skip_commit "$@";
	else
		git commit-tree "$@";
	fi' HEAD The function skip_commit is defined as follows: skip_commit()
{
	shift;
	while [ -n "$1" ];
	do
		shift;
		map "$1";
		shift;
	done;
} The shift magic first throws away the tree id and then the -p
parameters.  Note that this handles merges properly! In case Darl
committed a merge between P1 and P2, it will be propagated properly
and all children of the merge will become merge commits with P1,P2
as their parents instead of the merge commit. NOTE the changes introduced by the commits, and which are not reverted
by subsequent commits, will still be in the rewritten branch. If you want
to throw out changes together with the commits, you should use the
interactive mode of git rebase . You can rewrite the commit log messages using --msg-filter .  For
example, git svn-id strings in a repository created by git svn can
be removed this way: git filter-branch --msg-filter '
	sed -e "/^git-svn-id:/d"
' If you need to add Acked-by lines to, say, the last 10 commits (none
of which is a merge), use this command: git filter-branch --msg-filter '
	cat &&
	echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
' HEAD~10..HEAD The --env-filter option can be used to modify committer and/or author
identity.  For example, if you found out that your commits have the wrong
identity due to a misconfigured user.email, you can make a correction,
before publishing the project, like this: git filter-branch --env-filter '
	if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
	then
		GIT_AUTHOR_EMAIL=john@example.com
	fi
	if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
	then
		GIT_COMMITTER_EMAIL=john@example.com
	fi
' -- --all To restrict rewriting to only part of the history, specify a revision
range in addition to the new branch name.  The new branch name will
point to the top-most revision that a git rev-list of this range
will print. Consider this history: D--E--F--G--H
    /     /
A--B-----C To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use: git filter-branch ... C..H To rewrite commits E,F,G,H, use one of these: git filter-branch ... C..H --not D
git filter-branch ... D..H --not C To move the whole tree into a subdirectory, or remove it from there: git filter-branch --index-filter \
	'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
		GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
			git update-index --index-info &&
	 mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD


[System] You are a helpful assistant.

[User] git-notes - Add or inspect object notes  append

[Assistant]
Append new message(s) given by -m or -F options to an
existing note, or add them as a new note if one does not
exist, for the object (defaults to HEAD).  When appending to
an existing note, a blank line is added before each new
message as an inter-paragraph separator.  The separator can
be customized with the --separator option.


[System] You are a helpful assistant.

[User] gitrevisions - Specifying revisions and ranges for Git  <refname> , e.g. master , heads/master , refs/heads/master

[Assistant]
A symbolic ref name.  E.g. master typically means the commit
object referenced by refs/heads/master .  If you
happen to have both heads/master and tags/master , you can
explicitly say heads/master to tell Git which one you mean.
When ambiguous, a <refname> is disambiguated by taking the
first match in the following rules: If $GIT_DIR/<refname> exists, that is what you mean (this is usually
useful only for HEAD , FETCH_HEAD , ORIG_HEAD , MERGE_HEAD , REBASE_HEAD , REVERT_HEAD , CHERRY_PICK_HEAD , BISECT_HEAD and AUTO_MERGE ); otherwise, refs/<refname> if it exists; otherwise, refs/tags/<refname> if it exists; otherwise, refs/heads/<refname> if it exists; otherwise, refs/remotes/<refname> if it exists; otherwise, refs/remotes/<refname>/HEAD if it exists. HEAD names the commit on which you based the changes in the working tree. FETCH_HEAD records the branch which you fetched from a remote repository with
your last git fetch invocation. ORIG_HEAD is created by commands that move your HEAD in a drastic way ( git
am , git merge , git rebase , git reset ), to record the position
of the HEAD before their operation, so that you can easily change
the tip of the branch back to the state before you ran them. MERGE_HEAD records the commit(s) which you are merging into your branch when you
run git merge . REBASE_HEAD during a rebase, records the commit at which the operation is
currently stopped, either because of conflicts or an edit command in
an interactive rebase. REVERT_HEAD records the commit which you are reverting when you run git revert . CHERRY_PICK_HEAD records the commit which you are cherry-picking when you run git
cherry-pick . BISECT_HEAD records the current commit to be tested when you run git bisect
--no-checkout . AUTO_MERGE records a tree object corresponding to the state the ort merge strategy wrote to the working tree when a merge operation
resulted in conflicts. Note that any of the refs/* cases above may come either from
the $GIT_DIR/refs directory or from the $GIT_DIR/packed-refs file.
While the ref name encoding is unspecified, UTF-8 is preferred as
some output processing may assume ref names in UTF-8.


[System] You are a helpful assistant.

[User] git-pull - Fetch from and integrate with another repository or a local branch  --signoff  --no-signoff

[Assistant]
Add a Signed-off-by trailer by the committer at the end of the commit
log message.  The meaning of a signoff depends on the project
to which you’re committing.  For example, it may certify that
the committer has the rights to submit the work under the
project’s license or agrees to some contributor representation,
such as a Developer Certificate of Origin.
(See https://developercertificate.org for the one used by the
Linux kernel and Git projects.)  Consult the documentation or
leadership of the project to which you’re contributing to
understand how the signoffs are used in that project. The --no-signoff option can be used to countermand an earlier --signoff
option on the command line.


[System] You are a helpful assistant.

[User] git-branch - List, create, or delete branches  Start development from a known tag

[Assistant]
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
$ cd my2.6
$ git branch my2.6.14 v2.6.14 (1) $ git switch my2.6.14 This step and the next one could be combined into a single step with
"checkout -b my2.6.14 v2.6.14".


[System] You are a helpful assistant.

[User]
Eclipse and EGit: How to easily review changes to ALL modified files before committing to *local* repository
I'm using Eclipse Indigo SR2 with the (built-in) EGit plugin v.1.3.0.201202151440-r and haven't been able to find any way to easily review all my changes before making a commit.
I used Eclipse with SVN for years, and this was always very easy to do. I would typically right-click on my project, select Team->Synchronize, double-click on the first changed file (in the Team Sync perspective), then hit Ctrl-. repeatedly to review all changes in one file, and then proceed to the next file, as I wrote a summary of my changes for the commit message.
But of course, git is very different from Subversion, and so my workflow must change. With EGit, "Team Sync" only appears to be useful for reviewing changes between my local files and the remote repository (i.e. before a push to the remote). I need a way to review changes since my last commit to my local repository. I generally don't even care to (re)review changes before a push to remote (and if I did, I'd prefer a simple equivalent of git log to see what commits I'm about to push).
If I right-click on my project and select Team->Commit, I am presented with a window that does almost everything I need to do (select files to stage, commit, write a commit message, amend a previous commit, etc.). What it doesn't allow me to do is quickly and easily review all my changes in a compare editor. I can't believe this capability doesn't exist! It seems I am required to double-click on each individual file, review the changes, close the compare editor, and double-click on the next file. That's ridiculous!
TL/DR - I am looking for a simple GUI equivalent (in Eclipse) to do what I am easily able to do from the command line using git vimdiff (where vimdiff is a git alias that uses vimdiff as the "difftool" to cycle through all modified files) followed by git commit (with perhaps a git add or two in between).
If no one has a good solution, I am curious about how others handle their commit workflow with EGit. I've been getting along fine committing from the command line (not that Eclipse is happy about that) but I can't believe that EGit is as near-useless as it seems to me. Perhaps my google-fu is not as strong as it once was?

[Assistant]
Says here that you can see the diffs between the working tree and any given reference. Perhaps you should try out the latest version (Juno) of Eclipse/EGit and see if it's gotten any better?
Update: I've tried this out in the latest Eclipse, and as far as I can see it works fine. Here's how:
In the moment of writing this, Eclipse Juno 4.2 is the version you should go for. On the download page, you can pick between several packages according to your needs. The 'Eclipse IDE for Java Developers' comes bundled with EGit, but you can also install EGit into any distribution using the Eclipse Marketplace (under the Help menu).

Once you've imported your project into Eclipse, make sure the project is "shared":

Right-click project -> Team -> Share Project.. -> Git
Now do the following:

Switch to the Team Synchronizing Perspective.
Click the little synchronize button in the Synchronize View.
Choose Git
Pick a suitable branch to sync against, like refs/remotes/origin/master
Make sure to check the "Include local uncommitted changes in comparison" box
Click Finish

Now, change some files and watch them appear in the Synchronize View. Double-click the changed files to see the diff (like in the screenshot below).


[System] You are a helpful assistant.

[User]
SSL certificate rejected trying to access GitHub over HTTPS behind firewall

I'm stuck behind a firewall, so I have to use HTTPS to access my GitHub repository. I'm using Cygwin 1.7.7 on Windows XP.
I've tried setting the remote to https://[email protected]/username/ExcelANT.git, but pushing prompts for a password, but it doesn't do anything once I've entered it.
https://username:<password>github.com/username/ExcelANT.git and cloning the empty repository from scratch, but each time it gives me the same error:

error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/username/ExcelANT.git/info/refs

Turning on GIT_CURL_VERBOSE=1 gives me

* About to connect() to github.com port 443 (#0)
*   Trying 207.97.227.239... * successfully set certificate verify locations:
*   CAfile: none
CApath: /usr/ssl/certs
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Expire cleared
* Closing connection #0
* About to connect() to github.com port 443 (#0)
*   Trying 207.97.227.239... * successfully set certificate verify locations:
*   CAfile: none
CApath: /usr/ssl/certs
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Expire cleared
* Closing connection #0
error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing https://github.com/username/ExcelANT.git/info/refs

fatal: HTTP request failed

Is this a problem with my firewall, Cygwin or what?
I hadn't set the HTTP proxy in the Git configuration. However, it's an ISA server that needs NTLM authentication, not basic, so unless anyone knows how to force Git to use NTLM, I'm scuppered.


[System] You are a helpful assistant.

[User] git-config - Get and set repository or global options  histogram

[Assistant]
This algorithm extends the patience algorithm to "support
low-occurrence common elements".


[System] You are a helpful assistant.

[User]
How to fix the error `found no layout file for "HTML" for "page"` in Hugo CMS?

I recently imported content from my WordPress page into Hugo. When I run hugo serve I get following error messages:
WARN 2020/02/17 20:51:06 found no layout file for "HTML" for "page": You should create a template file which matches Hugo Layouts Lookup Rules for this combination.

The page in question starts like this:
---
linktitle: "The Title of the Post"
title: "The Title of the Post"
author: "Franz Drollig"
type: post
date: 2020-01-09T14:41:55+00:00
url: /the-title-of-post/
categories:
  - Uncategorized
weight: 10

---

This is the content of the post. This is the second sentence of the post.

It is located in mysite/content/posts/YYYY-MM-DD-title.md.
The layouts directory is empty. However, the themes directory contains the book theme. This theme is also configured in the config.toml.
Another post, starting like shown below, is rendered correctly.
---
author: "Michael Henderson"
date: 2014-09-28
linktitle: Creating a New Theme
menu:
  main:
    parent: tutorials
next: /tutorials/github-pages-blog
prev: /tutorials/automated-deployments
title: Creating a New Theme
weight: 10
---

## Introduction

Why is my post not rendered properly? How can I fix it?

[Assistant]
Okay so here is what is likely happening:
You have a theme you added as a git submodule and you recently re-cloned your project. Guess what? Your submodule needs to be re-downloaded as well.
You can do this with:
git submodule init
git submodule update

Then your project will load without errors.


[System] You are a helpful assistant.

[User]
Self-hosted Gitlab registry: Connection refused for localhost:5000

I'm using traefik as a reverse proxy (and for management for the letsencrypt certificates) and I'm running a self hosted gitlab instance. GitLab image is a monolithic with all the services into it, both of the services (Registry and Git) need to be served in the same container.
With the configuration shown below gitlab is running well.
docker login registry.domain.com is also working.
But navigating to the registry in the gitlab frontend gives me a 500 error.
The gitlab logs:
Errno::EADDRNOTAVAIL (Failed to open TCP connection to localhost:5000 (Cannot assign requested address - connect(2) for "localhost" port 5000)):

In the docs I read, that the port 5000 is default for gitlab registry.
So I went into the gitlab container and tried to call for localhost:5000:
$ docker exec -it gitlab /bin/bash

root@gitlab:/# curl -v http://localhost:5000
* Rebuilt URL to: http://localhost:5000/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* connect to 127.0.0.1 port 5000 failed: Connection refused
*   Trying ::1...
* TCP_NODELAY set
* Immediate connect fail for ::1: Cannot assign requested address
*   Trying ::1...
* TCP_NODELAY set
* Immediate connect fail for ::1: Cannot assign requested address
* Failed to connect to localhost port 5000: Connection refused
* Closing connection 0
curl: (7) Failed to connect to localhost port 5000: Connection refused

Furthermore there is no 5000...
root@gitlab:/# netstat -tanpu | grep -i listen
tcp        0      0 127.0.0.1:9093          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.11:33383        0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:9100          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:9229          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:9168          0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      638/nginx
tcp        0      0 127.0.0.1:8082          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:9236          0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      21/sshd
tcp        0      0 0.0.0.0:8060            0.0.0.0:*               LISTEN      638/nginx
tcp        0      0 127.0.0.1:9121          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:9090          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:9187          0.0.0.0:*               LISTEN      -
tcp6       0      0 :::9094                 :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      21/sshd

So what am I missing in my configuration? How do I have to handle the 5000 port in traefik?
docker-compose.yml
version: '3.3'

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    container_name: gitlab
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url = 'https://gitlab.domain.com'
        registry_external_url = 'https://registry.domain.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 2222
        gitlab_rails['registry_enabled'] = true
    ports:
      - '2222:22'
    networks:
      - proxy
    labels:
      - traefik.enable=true
      - traefik.gitlab.frontend.rule=Host:gitlab.domain.com
      - traefik.gitlab.port=80
      - traefik.reg.frontend.rule=Host:registry.domain.com
      - traefik.reg.port=80
      - traefik.docker.network=proxy
  traefik:
    image: traefik:1.7.3-alpine
    restart: always
    ports:
      - 80:80
      - 443:443
    networks:
      - proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/traefik/traefik.toml:/traefik.toml
      - /opt/traefik/acme.json:/acme.json
    labels:
      - traefik.frontend.rule=Host:monitor.domain.com
      - traefik.port=8080
    container_name: traefik

networks:
  proxy:
    external: true

traefik.toml
defaultEntryPoints = ["https","http"]

[entryPoints]
  [entryPoints.dashboard]
  address = ":8080"
    [entryPoints.dashboard.auth]
      [entryPoints.dashboard.auth.basic]
        users = ["admin:password"]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
    entryPoint = "https"
  [entryPoints.https]
  address = ":443"
  [entryPoints.https.tls]

[api]
entrypoint="dashboard"

[docker]
domain = "domain.com"
watch = true
network = "proxy"

[acme]
email = "[email protected]"
storage = "acme.json"
entryPoint = "https"
OnHostRule = true
  [acme.httpChallenge]
  entryPoint = "http"

[Assistant]
First: reading "GitLab Container Registry administration ", make sure that:

gitlab registry is activated in your Omnibus image: your gitlab.rb, by default, does not declare a registry.
you are using https, not http as an URL.

The container registry works under HTTPS by default. Using HTTP is possible but not recommended and out of the scope of this document. Read Test an insecure registry.

Second, regarding traefik, you can see an example in docker-gitlab issue 1688, which does declare a traefik front to the registry part of GitLab.

- traefik.enable=true
- traefik.backend=registry.demo.com
- traefik.frontend.rule=Host:registry.demo.com
- traefik.docker.network=traefik-00
- traefik.port=5000

If you really need to expose your internal "https port 5000" registry through an external http URL with traefik, you have an example in this thread.


[System] You are a helpful assistant.

[User] git-switch - Switch branches

[Assistant]
DESCRIPTION Switch to a specified branch. The working tree and the index are
updated to match the branch. All new commits will be added to the tip
of this branch. Optionally a new branch could be created with either -c , -C ,
automatically from a remote branch of same name (see --guess ), or
detach the working tree from any branch with --detach , along with
switching. Switching branches does not require a clean index and working tree
(i.e. no differences compared to HEAD ). The operation is aborted
however if the operation leads to loss of local changes, unless told
otherwise with --discard-changes or --merge . THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.


[System] You are a helpful assistant.

[User]
git: How to ignore all present untracked files?
Is there a handy way to ignore all untracked files and folders in a git repository?
(I know about the .gitignore.)
So git status would provide a clean result again.

[Assistant]
As already been said, to exclude from status just use:
git status -uno  # must be "-uno" , not "-u no"

If you instead want to permanently ignore currently untracked files you can, from the root of your project, launch:
git status --porcelain | grep '^??' | cut -c4- >> .gitignore

Every subsequent call to git status will explicitly ignore those files.
UPDATE: the above command has a minor drawback: if you don't have a .gitignore file yet your gitignore will ignore itself! This happens because the file .gitignore gets created before the git status --porcelain is executed. So if you don't have a .gitignore file yet I recommend using:
echo "$(git status --porcelain | grep '^??' | cut -c4-)" > .gitignore

This creates a subshell which completes before the .gitignore file is created.
COMMAND EXPLANATION I'll explain the command:

git status --porcelain is used instead of git status --short because manual states "Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable across git versions and regardless of user configuration." So we have both the parseability and stability;
grep '^??' filters only the lines starting with ??, which, according to the git status manual, correspond to the untracked files;
cut -c4- removes the first 3 characters of every line, which gives us just the relative path to the untracked file;
the | symbols are pipes, which pass the output of the previous command to the input of the following command;
the >> and > symbols are redirect operators, which append the output of the previous command to a file or overwrites/creates a new file, respectively.

ANOTHER VARIANT for those who prefer using sed instead of grep and cut, here's another way:
git status --porcelain | sed -n -e 's/^?? //p' >> .gitignore


[System] You are a helpful assistant.

[User]
git: Why doesn't git diff show any differences?
If I run 'git status' on my repo it gives:
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified: myfile

However, if I do a 'git diff myfile' it shows no differences. Is this because I have made a change and removed it so it is back to the original?
Should I run 'git checkout myfile' to clear it?

[Assistant]
Your file is already staged to be committed. You can show it's diff using the --cached option of git.
git diff --cached myfile

To unstage it, just do what git status suggests in it's output ;)
You can check The Git Index For more info.


[System] You are a helpful assistant.

[User] git-for-each-ref - Output information on each ref  tags=<bool-value>

[Assistant]
Instead of only considering annotated tags, consider
lightweight tags as well; see the corresponding option in git-describe for details.


[System] You are a helpful assistant.

[User] git-fetch - Download objects and refs from another repository  --recurse-submodules[=(yes|on-demand|no)]

[Assistant]
This option controls if and under what conditions new commits of
submodules should be fetched too. When recursing through submodules, git fetch always attempts to fetch "changed" submodules, that is, a
submodule that has commits that are referenced by a newly fetched
superproject commit but are missing in the local submodule clone. A
changed submodule can be fetched as long as it is present locally e.g.
in $GIT_DIR/modules/ (see gitsubmodules ); if the upstream
adds a new submodule, that submodule cannot be fetched until it is
cloned e.g. by git submodule update . When set to on-demand , only changed submodules are fetched. When set
to yes , all populated submodules are fetched and submodules that are
both unpopulated and changed are fetched. When set to no , submodules
are never fetched. When unspecified, this uses the value of fetch.recurseSubmodules if it
is set (see git-config ), defaulting to on-demand if unset.
When this option is used without any value, it defaults to yes .


[System] You are a helpful assistant.

[User]
Proper Way To Use Git/GitHub - PHP System with Dev/Testing/Production servers

I apologize if this is obvious or easy, I have looked at a good number of git/github tutorials and read other articles, but I want to make sure what I'm doing is right.
I want to incorporate VC (for obvious reasons) into my development team and process.
Current development process (using Dreamweaver):
 * Receive a ticket (or work order)
 * Download file on Development server
 * Make changes to the file
 * Upload file back to development server
 * Changes tested/verified
 * Send to production server

I'm trying to figure out how to make our new development process with using Git.
I am switching over to PHPStorm (which is an actual PHP IDE with direct integration with Git).
Would it be something like

Receive a ticket (or work order)
Checkout/Update/Download file(s)
Change Files
Upload file (which I assume is also the current working directory...?)
At the end of the day, do a commit
Have build script send data to testing server (nightly build)

Or would it be better to do something like

Receive a ticket (or work order)
Checkout/Update/Download file(s)
Change Files
Upload file/commit
Have build script send data to testing server (nightly build)

Or is there another way? Having a bit of trouble understanding what would be the optimal flow?
Any help would be greatly appreciated.

Edit
I'm trying see if it is best to have a version of the server locally (every developer), and if so, how does that work if you have 7 or so branches?
If not, how do you deal with 7 or so branches with them on the web? Do you FTP files up or use Git Hooks to make them auto update?
Update 07/26/2012
After working successfully with Git for quite a while now I've been following this branching model with great success:
A Successful Git Branching Model
The answer to the above was yes -- should definitely have a local version of the server.

[Assistant]
Assuming you have a live server and a development server I would do something along these lines.
Before even starting with a development cycle I would at least have two branches:

Master - the development server runs on this branch
Stable - the live server runs on this branch.

So if a developer gets a ticket or a work order he/she will perform the following actions:

git pull origin master
git branch featureBranch (named as the ticket id or as a good description for the work order)
git checkout featureBranch
Make changes which will accomplish the desired change. Commit as often as is necessary. Do this because you will create valuable history. For instance you can try an approach to a problem and if it doesn't work, abandon it. If a day later you see the light and want to re-apply the solution, it is in your history!
When the feature is fully developed and tested locally, checkout master.
git merge featureBranch
git push origin master
Test the pushed changes on your development server. This is the moment to run every test you can think of.
If all is working out, merge the feature or fix into the stable branch. Now the change is live for your customers.

Getting the code on the server
The updating of servers shouldn't be a problem. Basically I would set them up as users just like you're developers are. At my company we've setup the servers as read-only users. Basically that means the servers can never push anything but can always pull. Setting this up isn't trivial though, so you could just as well build a simple webinterface which simply only allows a git pull. If you can keep your developers from doing stuff on live implementations you're safe :)
[EDIT]
In response to the last questions asked in the comments of this reaction:
I don't know if I understand your question correctly, but basically (simplified a bit) this is how I would do this, were I in you shoes.

The testing machine (or the webroot which acts as testing implementation) has it source code based in a git repository with the master branch checked out. While creating this repository you could even remove all other references to all other branches so you'll be sure no can checkout a wrong branch in this repository. So basically the testing machine has a Git repository with only a master branch which is checked out.
For the live servers I would do exactly the same, but this time with the stable branch checked out. Developer should have a local repository cloned in which all branches exist. And a local implementation of the software you guys build. This software gets its source from a the local git repository. In other words: from the currently checked out branch in this repository.
Actual coding
When a new feature is wanted, a local feature branch can be made based on the current master. When the branch is checked out the changes can be made and checked locally by the developer (since the software is now running on the source of the feature branch).
If everything seems to be in order, the changes get merged from feature branch to master and pushed to your "git machine". "your github" so to speak. Testing can now pull the changes in so every test necessary can be done by QA. If they decide everything is ok, the developer can merge the changes from master to stable and push again.
All thats left now is pulling form your live machines.


[System] You are a helpful assistant.

[User] git-format-patch - Prepare patches for e-mail submission  patience

[Assistant] Use "patience diff" algorithm when generating patches.


[System] You are a helpful assistant.

[User] git - the stupid content tracker  git-range-diff

[Assistant] Compare two commit ranges (e.g. two versions of a branch)


[System] You are a helpful assistant.

[User] git - the stupid content tracker  git-check-mailmap

[Assistant] Show canonical names and email addresses of contacts


[System] You are a helpful assistant.

[User]
(git) diff output relative path?
I need to get some diffs in my repo that are not relative to the base of the repo, but instead relative to a given base or given path.
By default I get:
git diff
diff --git a/path/to/file b/path/to/file
index 0cc125e..9bf911e 100644
--- a/path/to/file
+++ b/path/to/file

But what I want is something like:
git diff --prefix=/new/path/to
diff --git a/new/path/to/file b/new/path/to/file
index 0cc125e..9bf911e 100644
--- a/new/path/to/file
+++ b/new/path/to/file

I have looked over the --relative option (not what I am looking for), the --src/dst-prefix (these can only change the "a" or "b" parts. Am I missing something basic?

[Assistant]
git diff prints paths (of changed files) from the root of the repo - no matter where you are when executing the command.
git diff --relative will print paths from the dir you are in.
So if you need paths not starting from the repo-root move down (cd) to the directory (within your repo tree) where you with your paths to start from.


[System] You are a helpful assistant.

[User] git - the stupid content tracker  git-show-ref

[Assistant] List references in a local repository