~sircmpwn/public-inbox

git-rebase.io: mention upstream branch configuration and '--fork-point' v1 PROPOSED

Philippe Blain
This series proposes two small improvements to the 'git pull --rebase' section.
First, it generalizes the example by not assuming the current branch is `master`
and its configured upstream is `origin/master`.

Second, it adds a footnote mentioning that `git pull --rebase` uses the fork-point 
machinery to avoid replaying non local commits.

Philippe Blain (2):
  Add details for 'git pull'
  git pull --rebase: mention '--fork-point'

 index.html | 39 +++++++++++++++++++++++++++++----------
 1 file changed, 29 insertions(+), 10 deletions(-)

-- 
2.26.0
Export patchset (mbox)
How do I use this?

Copy & paste the following snippet into your terminal to import this patchset into git:

curl -s https://lists.sr.ht/~sircmpwn/public-inbox/patches/10138/mbox | git am -3
Learn more about email & git

[PATCH git-rebase.io 1/2] Add details for 'git pull' Export this patch

Philippe Blain
Mention that 'git pull' by itself fetches and merges the configured
remote-tracking branch, and show how this configuration can be checked.

Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
 index.html | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/index.html b/index.html
index 17a092d..18e3669 100644
--- a/index.html
+++ b/index.html
@@ -610,13 +610,21 @@ git commit -m"Add inquiry.txt"</pre>
        </p>
        <h2 id="pull">git pull --rebase</h2>
        <p>
          If you've been writing some commits on a branch which has been updated
          upstream, normally <code>git pull</code> will create a merge commit.
          If you've been writing some commits on a branch <code>&lt;branch&gt;</code> which has been updated
          upstream, say on remote <code>origin</code>, normally <code>git pull</code> will create a merge commit.
          In this respect, <code>git pull</code>'s behavior by default is
          equivalent to:
        </p>
        <pre>git fetch origin
git merge origin/master</pre>
        <pre>git fetch origin &lt;branch&gt;
git merge origin/&lt;branch&gt;</pre>
        <p>
          This assumes that the local branch <code>&lt;branch&gt;</code> is configured to track the <code>&lt;branch&gt</code> branch
          from the <code>origin</code> remote, i.e.:
        </p>
          <pre>$ git config branch.&lt;branch&gt;.remote
origin
$ git config branch.&lt;branch&gt;.merge
refs/heads/&lt;branch&gt;</pre>
        <p>
          There's another option, which is often more useful and leads to a much
          cleaner history: <code>git pull --rebase</code>. Unlike the merge
-- 
2.26.0

[PATCH git-rebase.io 2/2] git pull --rebase: mention '--fork-point' Export this patch

Philippe Blain
`git pull --rebase` uses the fork-point machinery to avoid rebasing
non-local commits. Add a footnote mentioning that, with links to the
relevant parts of the Git documentation.

Also renumber the last footnote to keep the ordering in the order the
footnotes appear in the text.

Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
 index.html | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/index.html b/index.html
index 18e3669..0393ef3 100644
--- a/index.html
+++ b/index.html
@@ -628,10 +628,10 @@ refs/heads/&lt;branch&gt;</pre>
        <p>
          There's another option, which is often more useful and leads to a much
          cleaner history: <code>git pull --rebase</code>. Unlike the merge
          approach, this is equivalent to the following:
          approach, this is mostly<a id="ref-4" href="#note-4"><sup>4</sup></a> equivalent to the following:
        </p>
        <pre>git fetch origin
git rebase origin/master</pre>
git rebase origin/&lt;branch&gt;</pre>
        <p>
          The merge approach is simpler and easier to understand, but the rebase
          approach is almost always what you want to do if you understand how to
@@ -661,8 +661,8 @@ git rebase origin/master</pre>
        <pre>git rebase --onto master feature-1 feature-2</pre>
        <p>
          The non-interactive rebase does the default operation for all
          implicated commits ("pick")<a id="ref-4"
            href="#note-4"><sup>4</sup></a>, which simply replays the
          implicated commits ("pick")<a id="ref-5"
            href="#note-5"><sup>5</sup></a>, which simply replays the
          commits in feature-2 that are not in feature-1 on top of
          master. Your history now looks like this:
        </p>
@@ -738,11 +738,22 @@ git rebase origin/master</pre>
        </div>
        <div>
          <sup id="note-4">
            4: Actually, it doesn't. The default non-interactive behavior
            4: Actually, it depends if the upstream branch was itself rebased
            or dropped/squashed some commits.
            <a href="https://git-scm.com/docs/git-pull#Documentation/git-pull.txt--r"><code>git pull --rebase</code></a>
            tries to recover from that situation by using the "fork-point" machinery in
            <a href="https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---fork-point"><code>git rebase</code></a>
            and <a href="https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode"><code>git merge-base</code></a>
            to avoid rebasing non-local commits. <a href="#ref-4">↩</a>
          </sup>
        </div>
        <div>
          <sup id="note-5">
            5: Actually, it doesn't. The default non-interactive behavior
            differs slightly from the interactive behavior at the time of
            writing, in a way which is generally not important. This may change
            in the future - the relevant discussions are underway on the git
            mailing list. <a href="#ref-4">↩</a>
            mailing list. <a href="#ref-5">↩</a>
          </sup>
        </div>
      </footer>
-- 
2.26.0
View this thread in the archives