requests
will be made is an EOF on standard input, but when that happens, the server may
not have yet processed the final request, so dropping the connection at that
point would interrupt that request.
+
An example configuration entry in `~/.ssh/config` with an HTTP proxy might look
like this:
+
----
Host git.example.org
    User git
    ProxyCommand socat -t 10 - PROXY:proxy.example.org:%h:%p,proxyport=8080
----
+
Note that in all cases, for Git to work properly, the proxy must be completely
transparent.  The proxy cannot modify, tamper with, or buffer the connection in
any way, or Git will almost certainly fail to work.  Note that many proxies,
including many TLS middleboxes, Windows antivirus and firewall programs other
than Windows Defender and Windows Firewall, and filtering proxies fail to meet
this standard, and as a result end up breaking Git.  Because of the many
reports of problems and their poor security history, we recommend against the
use of these classes of software and devices.

Merging and Rebasing
--------------------

[[long-running-squash-merge]]
What kinds of problems can occur when merging long-lived branches with squash merges?::
	In general, there are a variety of problems that can occur when using squash
	merges to merge two branches multiple times.  These can include seeing extra
	commits in `git log` output, with a GUI, or when using the `...` notation to
	express a range, as well as the possibility of needing to re-resolve conflicts
	again and again.
+
When Git does a normal merge between two branches, it considers exactly three
points: the two branches and a third commit, called the _merge base_, which is
usually the common ancestor of the commits.  The result of the merge is the sum
of the changes between the merge base and each head.  When you merge two
branches with a regular merge commit, this results in a new commit which will
end up as a merge base when they're merged again, because there is now a new
common ancestor.  Git doesn't have to consider changes that occurred before the
merge base, so you don't have to re-resolve any conflicts you resolved before.
+
When you perform a squash merge, a merge commit isn't created; instead, the
changes from one side are applied as a regular commit to the other side.  This
means that the merge base for these branches won't have changed, and so when Git
goes to perform its next merge, it considers all of the changes that it
considered the last time plus the new changes.  That means any conflicts may
need to be re-resolved.  Similarly, anything using the `...` notation in `git
diff`, `git log`, or a GUI will result in showing all of the changes since the
original merge base.
+
As a consequence, if you want to merge two long-lived branches repeatedly, it's
best to always use a regular merge commit.

[[merge-two-revert-one]]
If I make a change on two branches but revert it on one, why does the merge of those branches include the change?::
	By default, when Git does a merge, it uses a strategy called the `ort`
	strategy, which does a fancy three-way merge.  In such a case, when Git
	performs the merge, it considers exactly three points: the two heads and a
	third point, called the _merge base_, which is usually the common ancestor of
	those commits.  Git does not consider the history or the individual commits
	that have happened on those branches at all.
+
As a result, if both sides have a change and one side has reverted that change,
the result is to include the change.  This is because the code has changed on
one side and there is no net change on the other, and in this scenario, Git
adopts the change.
+
If this is a problem for you, you can do a rebase instead, rebasing the branch
with the revert onto the other branch.  A rebase in this scenario will revert
the change, because a rebase applies each individual commit, including the
revert.  Note that rebases rewrite history, so you should avoid rebasing
published branches unless you're sure you're comfortable