Autogenerated HTML docs for v2.28.0-651-g306ee

1 files changed, 96 insertions, 2 deletions

diff --git a/gitfaq.html b/gitfaq.html
index 1d1c7ba9b..90af7073a 100644
--- a/gitfaq.html
+++ b/gitfaq.html
@@ -1036,7 +1036,67 @@ How do I know if I want to do a fetch or a pull?
 </div>

 </div>

 <div class="sect1">

-<h2 id="fetching-and-pulling">Hooks</h2>

+<h2 id="fetching-and-pulling">Merging and Rebasing</h2>

+<div class="sectionbody">

+<div class="dlist" id="long-running-squash-merge"><dl>

+<dt class="hdlist1">

+What kinds of problems can occur when merging long-lived branches with squash merges?

+</dt>

+<dd>

+<p>

+        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 <code>git log</code> output, with a GUI, or when using the <code>...</code> notation to

+        express a range, as well as the possibility of needing to re-resolve conflicts

+        again and again.

+</p>

+<div class="paragraph"><p>When Git does a normal merge between two branches, it considers exactly three

+points: the two branches and a third commit, called the <em>merge base</em>, 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&#8217;re merged again, because there is now a new

+common ancestor.  Git doesn&#8217;t have to consider changes that occurred before the

+merge base, so you don&#8217;t have to re-resolve any conflicts you resolved before.</p></div>

+<div class="paragraph"><p>When you perform a squash merge, a merge commit isn&#8217;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&#8217;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 <code>...</code> notation in <code>git

+diff</code>, <code>git log</code>, or a GUI will result in showing all of the changes since the

+original merge base.</p></div>

+<div class="paragraph"><p>As a consequence, if you want to merge two long-lived branches repeatedly, it&#8217;s

+best to always use a regular merge commit.</p></div>

+</dd>

+<dt class="hdlist1">

+If I make a change on two branches but revert it on one, why does the merge of those branches include the change?

+</dt>

+<dd>

+<p>

+        By default, when Git does a merge, it uses a strategy called the recursive

+        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 <em>merge base</em>, 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.

+</p>

+<div class="paragraph" id="merge-two-revert-one"><p>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.</p></div>

+<div class="paragraph"><p>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&#8217;re sure you&#8217;re comfortable with that.  See the

+NOTES section in <a href="git-rebase.html">git-rebase(1)</a> for more details.</p></div>

+</dd>

+</dl></div>

+</div>

+</div>

+<div class="sect1">

+<h2 id="_hooks">Hooks</h2>

 <div class="sectionbody">

 <div class="dlist" id="restrict-with-hooks"><dl>

 <dt class="hdlist1">

@@ -1115,6 +1175,40 @@ information about how to configure files as text or binary.</p></div>
 don&#8217;t wish to remove the carriage returns from your line endings.</p></div>

 </dd>

 <dt class="hdlist1">

+Why do I have a file that&#8217;s always modified?

+</dt>

+<dd>

+<p>

+        Internally, Git always stores file names as sequences of bytes and doesn&#8217;t

+        perform any encoding or case folding.  However, Windows and macOS by default

+        both perform case folding on file names.  As a result, it&#8217;s possible to end up

+        with multiple files or directories whose names differ only in case.  Git can

+        handle this just fine, but the file system can store only one of these files,

+        so when Git reads the other file to see its contents, it looks modified.

+</p>

+<div class="paragraph" id="always-modified-files-case"><p>It&#8217;s best to remove one of the files such that you only have one file.  You can

+do this with commands like the following (assuming two files <code>AFile.txt</code> and

+<code>afile.txt</code>) on an otherwise clean working tree:</p></div>

+<div class="listingblock">

+<div class="content">

+<pre><code>$ git rm --cached AFile.txt

+$ git commit -m 'Remove files conflicting in case'

+$ git checkout .</code></pre>

+</div></div>

+<div class="paragraph"><p>This avoids touching the disk, but removes the additional file.  Your project

+may prefer to adopt a naming convention, such as all-lowercase names, to avoid

+this problem from occurring again; such a convention can be checked using a

+<code>pre-receive</code> hook or as part of a continuous integration (CI) system.</p></div>

+<div class="paragraph"><p>It is also possible for perpetually modified files to occur on any platform if a

+smudge or clean filter is in use on your system but a file was previously

+committed without running the smudge or clean filter.  To fix this, run the

+following on an otherwise clean working tree:</p></div>

+<div class="listingblock">

+<div class="content">

+<pre><code>$ git add --renormalize .</code></pre>

+</div></div>

+</dd>

+<dt class="hdlist1">

 What&#8217;s the recommended way to store files in Git?

 </dt>

 <dd>

@@ -1168,7 +1262,7 @@ platform.</p></div>
 <div id="footer">

 <div id="footer-text">

 Last updated

- 2020-05-26 11:29:03 PDT

+ 2020-09-29 14:47:55 PDT

 </div>

 </div>

 </body>