{"thread":{"id":"55978","subject":"[PATCH 0/2] pull: documentation improvements","startedAt":"2021-06-21T17:53:34Z","lastAt":"2021-06-27T04:21:20Z","messageCount":40,"participants":["Felipe Contreras","Alex Henrie","Bagas Sanjaya","Elijah Newren","Philip Oakley","Ævar Arnfjörð Bjarmason","Kerry, Richard"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"428078","messageId":"20210621175234.1079004-1-felipe.contreras@gmail.com","threadId":"55978","inReplyTo":null,"subject":"[PATCH 0/2] pull: documentation improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-21T17:52:32Z","receivedAt":"2021-06-21T17:53:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"These are the non-controversial changes from last-year series [1] which\nobjectively improve our documentation and don't have any reason not to\nbe merged.\n\nNot everyone knows what a rebase or a fast-forward is.\n\n[1] https://lore.kernel.org/git/20201218211026.1937168-1-felipe.contreras@gmail.com/\n\nFelipe Contreras (2):\n doc: pull: explain what is a fast-forward\n pull: improve default warning\n\n Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------\n builtin/pull.c | 22 ++++++++++----------\n 2 files changed, 47 insertions(+), 16 deletions(-)\n\n-- \n2.32.0\n\n"},{"id":"428079","messageId":"20210621175234.1079004-2-felipe.contreras@gmail.com","threadId":"55978","inReplyTo":"20210621175234.1079004-1-felipe.contreras@gmail.com","subject":"[PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-21T17:52:33Z","receivedAt":"2021-06-21T17:54:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"We want users to know what is a fast-forward in order to understand the\ndefault warning.\n\nLet's expand the explanation in order to cover both the simple, and the\ncomplex cases with as much detail as possible.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------\n 1 file changed, 35 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 5c3fb67c01..142df1c4a1 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n ------------\n \t A---B---C master on origin\n \t /\n- D---E---F---G master\n+ D---E master\n \t^\n \torigin/master in your repository\n ------------\n \n Then \"`git pull`\" will fetch and replay the changes from the remote\n `master` branch since it diverged from the local `master` (i.e., `E`)\n-until its current commit (`C`) on top of `master` and record the\n-result in a new commit along with the names of the two parent commits\n-and a log message from the user describing the changes.\n+until its current commit (`C`) on top of `master`.\n+\n+After the remote changes have been synchronized, the local `master` will\n+be fast-forwarded to the same commit as the remote one, therefore\n+creating a linear history.\n+\n+------------\n+ D---E---A---B---C master, origin/master\n+------------\n+\n+However, a non-fast-forward case looks very different:\n+\n+------------\n+\t A---B---C origin/master\n+\t /\n+ D---E---F---G master\n+------------\n+\n+If there are additional changes in the local `master`, it's\n+not possible to fast-forward, so a decision must be made how to\n+synchronize the local, and remote brances.\n+\n+In these situations `git pull` will warn you about your possible\n+options, which are either merge (`--no-rebase`), or rebase (`--rebase`).\n+However, by default it will continue doing a merge.\n+\n+A merge will create a new commit with two parent commits (`G` and `C`)\n+and a log message describing the changes, which you can edit.\n \n ------------\n \t A---B---C origin/master\n@@ -58,8 +83,11 @@ and a log message from the user describing the changes.\n D---E---F---G---H master\n ------------\n \n+Once the merge commit is created (`H`), your local `master` branch has\n+incorporated the changes of the remote `master` branch.\n+\n See linkgit:git-merge[1] for details, including how conflicts\n-are presented and handled.\n+are presented and handled, and also linkgit:git-rebase[1].\n \n In Git 1.7.0 or later, to cancel a conflicting merge, use\n `git reset --merge`. *Warning*: In older versions of Git, running 'git pull'\n@@ -248,7 +276,8 @@ version.\n \n SEE ALSO\n --------\n-linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1]\n+linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-rebase[1],\n+linkgit:git-config[1]\n \n GIT\n ---\n-- \n2.32.0\n\n"},{"id":"428080","messageId":"20210621175234.1079004-3-felipe.contreras@gmail.com","threadId":"55978","inReplyTo":"20210621175234.1079004-1-felipe.contreras@gmail.com","subject":"[PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-21T17:52:34Z","receivedAt":"2021-06-21T17:54:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"According to feedback from GitHub trainers [1], most newcomers don't\nunderstand what a rebase is. So in the default warning we want to\nprovide our users with a command that does the most sensible thing,\nfixes the divergence, gets rid of the warning, with the minimum mental\neffort, and happens to be the default:\n\n git pull --no-rebase (later --merge)\n\nIn addition, we don't want to start by recommending a permanent\nconfiguration, but a temporary solution so they start training their\nfingers and maybe learn how to do a rebase. So we start with the commands.\n\nAlso, we need to be clear about what we mean by \"specifying\"; merge, or\nrebase.\n\nMoreover, thanks to the previous patch now \"git pull --help\" explains\nwhat a fast-forward is, let's mention that reference.\n\nAnd finally, use --global in the configuration commands like we did with\npush.default.\n\n[1] https://lore.kernel.org/git/20130909201751.GA14437@sigill.intra.peff.net/\n\nSigned-off-by: Felipe Contreras \n---\n builtin/pull.c | 22 ++++++++++++----------\n 1 file changed, 12 insertions(+), 10 deletions(-)\n\ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex 3e13f81084..48e25a5061 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -927,18 +927,20 @@ static int get_can_ff(struct object_id *orig_head, struct object_id *orig_merge_\n \n static void show_advice_pull_non_ff(void)\n {\n-\tadvise(_(\"Pulling without specifying how to reconcile divergent branches is\\n\"\n-\t\t \"discouraged. You can squelch this message by running one of the following\\n\"\n-\t\t \"commands sometime before your next pull:\\n\"\n+\tadvise(_(\"Pulling without specifying how to reconcile divergent branches is discouraged;\\n\"\n+\t\t \"you need to specify if you want a merge, or a rebase.\\n\"\n \t\t \"\\n\"\n-\t\t \" git config pull.rebase false # merge (the default strategy)\\n\"\n-\t\t \" git config pull.rebase true # rebase\\n\"\n-\t\t \" git config pull.ff only # fast-forward only\\n\"\n+\t\t \" git pull --no-rebase # the default (merge)\\n\"\n+\t\t \" git pull --rebase\\n\"\n \t\t \"\\n\"\n-\t\t \"You can replace \\\"git config\\\" with \\\"git config --global\\\" to set a default\\n\"\n-\t\t \"preference for all repositories. You can also pass --rebase, --no-rebase,\\n\"\n-\t\t \"or --ff-only on the command line to override the configured default per\\n\"\n-\t\t \"invocation.\\n\"));\n+\t\t \"You can squelch this message by running one of the following commands:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git config --global pull.rebase false # merge\\n\"\n+\t\t \" git config --global pull.rebase true # rebase\\n\"\n+\t\t \" git config --global pull.ff only # fast-forward only\\n\"\n+\t\t \"\\n\"\n+\t\t \"If unsure, run \\\"git pull --no-rebase\\\".\\n\"\n+\t\t \"Read \\\"git pull --help\\\" for more information.\"));\n }\n \n int cmd_pull(int argc, const char **argv, const char *prefix)\n-- \n2.32.0\n\n"},{"id":"428081","messageId":"CAMMLpeR2Y_EGwqGJzghSQ1DzpYQyWr6ENmGCvPRdhhYFkTW4yw@mail.gmail.com","threadId":"55978","inReplyTo":"20210621175234.1079004-3-felipe.contreras@gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-06-21T18:05:41Z","receivedAt":"2021-06-21T18:19:40Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras\n wrote:\n>\n> + \"If unsure, run \\\"git pull --no-rebase\\\".\\n\"\n\nI don't think the message should recommend merging over rebasing;\nwhich strategy is the correct one depends entirely on the project's\nworkflow and the user's role within that workflow. The eventual goal\nis to get rid of the default here and make the user make an educated\nchoice, which does imply some work on the user's part, but it avoids\nthe massive headaches created by users merging without understanding\nwhat they're doing.\n\n-Alex\n"},{"id":"428088","messageId":"60d0df99d91e1_108e902085e@natae.notmuch","threadId":"55978","inReplyTo":"CAMMLpeR2Y_EGwqGJzghSQ1DzpYQyWr6ENmGCvPRdhhYFkTW4yw@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-21T18:51:05Z","receivedAt":"2021-06-21T18:51:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Alex Henrie wrote:\n> On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras\n> wrote:\n> >\n> > + \"If unsure, run \\\"git pull --no-rebase\\\".\\n\"\n> \n> I don't think the message should recommend merging over rebasing;\n\nThis is the default strategy.\n\nDoing `git pull` is the same as doing `git pull --no-rebase`, except\nwith the warning.\n\n> The eventual goal is to get rid of the default here and make the user\n> make an educated choice, which does imply some work on the user's\n> part, but it avoids the massive headaches created by users merging\n> without understanding what they're doing.\n\nIndeed, but any minute change in git's UI is a gargantuan task that\ntakes several years--or even decades--to accomplish, if it ever happens.\nI started this patch in 2013, and here we are.\n\nThis patch series is not attempting to do the impossible.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"428114","messageId":"CAMMLpeRnUC+nOek=Kz6bj0_R6EUaDr=7ObKF01V641_ByOmk6A@mail.gmail.com","threadId":"55978","inReplyTo":"60d0df99d91e1_108e902085e@natae.notmuch","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-06-21T21:47:49Z","receivedAt":"2021-06-21T21:48:04Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Jun 21, 2021 at 12:51 PM Felipe Contreras\n wrote:\n>\n> Alex Henrie wrote:\n> > On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras\n> > wrote:\n> > >\n> > > + \"If unsure, run \\\"git pull --no-rebase\\\".\\n\"\n> >\n> > I don't think the message should recommend merging over rebasing;\n>\n> This is the default strategy.\n\nYes, but it shouldn't be, and we shouldn't make the problem worse by\nencouraging people to default to merging without thinking.\n\n> > The eventual goal is to get rid of the default here and make the user\n> > make an educated choice, which does imply some work on the user's\n> > part, but it avoids the massive headaches created by users merging\n> > without understanding what they're doing.\n>\n> Indeed, but any minute change in git's UI is a gargantuan task that\n> takes several years--or even decades--to accomplish, if it ever happens.\n> I started this patch in 2013, and here we are.\n\nAlthough what needs to be done had been envisioned by some as early as\n2013, the warning has only been around since Git 2.27 (released in\nJune 2020), and it was only restricted to pulls where fast-forwarding\nis impossible in Git 2.31 (released in March 2021). The good news is\nthat (unless I'm mistaken) there are no more changes that need to be\nmade prior to changing the message from from \"advise\" to \"die\". All\nthat needs to be done is to set a date to make the switch. For\ncomparison, users were given from Git 1.8 to Git 2.0 (October 2012 to\nMay 2014, 1 year and 7 months) to acclimate when push.default changed\nfrom \"matching\" to \"simple\". So how about we plan to stop merging by\ndefault in Git 2.40 (due around the end of 2022 or beginning of 2023),\nand update the warning message to advise the users of the pending\nbehavioral change?\n\n-Alex\n"},{"id":"428117","messageId":"60d10ebd99d86_113139208cd@natae.notmuch","threadId":"55978","inReplyTo":"CAMMLpeRnUC+nOek=Kz6bj0_R6EUaDr=7ObKF01V641_ByOmk6A@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-21T22:12:13Z","receivedAt":"2021-06-21T22:12:17Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Alex Henrie wrote:\n> On Mon, Jun 21, 2021 at 12:51 PM Felipe Contreras\n> wrote:\n> >\n> > Alex Henrie wrote:\n> > > On Mon, Jun 21, 2021 at 11:52 AM Felipe Contreras\n> > > wrote:\n> > > >\n> > > > + \"If unsure, run \\\"git pull --no-rebase\\\".\\n\"\n> > >\n> > > I don't think the message should recommend merging over rebasing;\n> >\n> > This is the default strategy.\n> \n> Yes, but it shouldn't be,\n\nFeel free to propose a patch to change that, in the meantime this is the\ndefault.\n\n> and we shouldn't make the problem worse by encouraging people to\n> default to merging without thinking.\n\nWe are not.\n\n> > > The eventual goal is to get rid of the default here and make the user\n> > > make an educated choice, which does imply some work on the user's\n> > > part, but it avoids the massive headaches created by users merging\n> > > without understanding what they're doing.\n> >\n> > Indeed, but any minute change in git's UI is a gargantuan task that\n> > takes several years--or even decades--to accomplish, if it ever happens.\n> > I started this patch in 2013, and here we are.\n> \n> Although what needs to be done had been envisioned by some as early as\n> 2013, the warning has only been around since Git 2.27 (released in\n> June 2020), and it was only restricted to pulls where fast-forwarding\n> is impossible in Git 2.31 (released in March 2021). The good news is\n> that (unless I'm mistaken) there are no more changes that need to be\n> made prior to changing the message from from \"advise\" to \"die\".\n\nThere is *a lot* that needs to be done.\n\n 1. Update the documentation\n 2. Add a --merge option (instead of the ackward --no-rebase)\n 3. Fix all the wrong behavior with --ff, --no-ff, and -ff-only\n 4. Add a pull.mode configuration\n 5. Add a configuration for the mode in which we want to die\n 6. Fix inconsistencies in the UI\n\nOnly *then* can we even begin to throw a warning stating that the\ndefault behavior might change in the future, and how to try the new\nbehavior.\n\n> All that needs to be done is to set a date to make the switch.\n\nNo, there's a lot more.\n\n> For comparison, users were given from Git 1.8 to Git 2.0 (October 2012\n> to May 2014, 1 year and 7 months) to acclimate when push.default\n> changed from \"matching\" to \"simple\".\n\nWe haven't told the users the default mode is going to change for a\nsingle day. We don't have a configuration to tell them to turn on to\nenable the new mode, nor do we have a configuration to tell them to\nenable to stay in the old mode.\n\nThere's no configuration in git 2.32 that is equivalent to what I\nproposed with pull.mode=fast-forward?\n\n\nIn the meantime there's no reason to have subpar documentation.\n\n-- \nFelipe Contreras\n"},{"id":"428157","messageId":"CAMMLpeRa3atkZxEtV--YD6-JSf0Bp9xRw9kS5wSWerxpsGrvrw@mail.gmail.com","threadId":"55978","inReplyTo":"60d10ebd99d86_113139208cd@natae.notmuch","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-06-22T03:15:31Z","receivedAt":"2021-06-22T03:15:50Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Jun 21, 2021 at 4:12 PM Felipe Contreras\n wrote:\n>\n> Alex Henrie wrote:\n> > On Mon, Jun 21, 2021 at 12:51 PM Felipe Contreras\n> > wrote:\n> > >\n> > > Alex Henrie wrote:\n> > > > The eventual goal is to get rid of the default here and make the user\n> > > > make an educated choice, which does imply some work on the user's\n> > > > part, but it avoids the massive headaches created by users merging\n> > > > without understanding what they're doing.\n> > >\n> > > Indeed, but any minute change in git's UI is a gargantuan task that\n> > > takes several years--or even decades--to accomplish, if it ever happens.\n> > > I started this patch in 2013, and here we are.\n> >\n> > Although what needs to be done had been envisioned by some as early as\n> > 2013, the warning has only been around since Git 2.27 (released in\n> > June 2020), and it was only restricted to pulls where fast-forwarding\n> > is impossible in Git 2.31 (released in March 2021). The good news is\n> > that (unless I'm mistaken) there are no more changes that need to be\n> > made prior to changing the message from from \"advise\" to \"die\".\n>\n> There is *a lot* that needs to be done.\n>\n> 1. Update the documentation\n> 2. Add a --merge option (instead of the ackward --no-rebase)\n> 3. Fix all the wrong behavior with --ff, --no-ff, and -ff-only\n> 4. Add a pull.mode configuration\n> 5. Add a configuration for the mode in which we want to die\n> 6. Fix inconsistencies in the UI\n\nI agree with you that the documentation should be updated when the\nchange is made (#1), and maybe there should be a config option to go\nback to the behavior of warning but doing the merge anyway (#5). The\nrest I think are things that would be nice to have but don't preclude\nmaking the switch because aborting instead of merging would not\nintroduce any new UI limitations or inconsistencies. Of course, it's\nultimately up to Junio and the wider Git community, and I would love\nto hear their thoughts about it.\n\n> In the meantime there's no reason to have subpar documentation.\n\nMy only serious objection to this patch is the instruction to merge if\nyou don't know what to do instead of asking the repository maintainer\nwhat to do or reading the Git documentation. I don't have a strong\nopinion on the rest of the patch.\n\n-Alex\n"},{"id":"428174","messageId":"60d1667797fb1_1a4aad20825@natae.notmuch","threadId":"55978","inReplyTo":"CAMMLpeRa3atkZxEtV--YD6-JSf0Bp9xRw9kS5wSWerxpsGrvrw@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-22T04:26:31Z","receivedAt":"2021-06-22T04:26:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Alex Henrie wrote:\n> On Mon, Jun 21, 2021 at 4:12 PM Felipe Contreras\n> wrote:\n> >\n> > Alex Henrie wrote:\n\n> > > Although what needs to be done had been envisioned by some as early as\n> > > 2013, the warning has only been around since Git 2.27 (released in\n> > > June 2020), and it was only restricted to pulls where fast-forwarding\n> > > is impossible in Git 2.31 (released in March 2021). The good news is\n> > > that (unless I'm mistaken) there are no more changes that need to be\n> > > made prior to changing the message from from \"advise\" to \"die\".\n> >\n> > There is *a lot* that needs to be done.\n> >\n> > 1. Update the documentation\n> > 2. Add a --merge option (instead of the ackward --no-rebase)\n> > 3. Fix all the wrong behavior with --ff, --no-ff, and -ff-only\n> > 4. Add a pull.mode configuration\n> > 5. Add a configuration for the mode in which we want to die\n> > 6. Fix inconsistencies in the UI\n> \n> I agree with you that the documentation should be updated when the\n> change is made (#1),\n\nI'm saying the documentation needs to be updated _before_ the change is\nmade. There's no reason not to have the fast-forward example in the\ndocumentation.\n\n> and maybe there should be a config option to go back to the behavior\n> of warning but doing the merge anyway (#5).\n\nBefore that we need a configuration to turn the behavior on.\n\n> The rest I think are things that would be nice to have but don't\n> preclude making the switch because aborting instead of merging would\n> not introduce any new UI limitations or inconsistencies.\n\nThey don't preclude the switch, but the switch should be precluded by a\nwarning, and the warning would be something like:\n\n The pull was not fast-forward, in the future you will have to choose a\n merge, or a rebase.\n\n To quell this message you have two main options:\n\n 1. Adopt the new behavior:\n\n git config --global pull.mode ff-only\n\n 2. Maintain the current behavior:\n\n git config --global pull.mode merge\n\n For now we will fall back to the traditional behavior (merge).\n\n Read \"git pull --help\" for more information.\n\nWithout having the changes I listed this warning can't be as useful.\n\n> Of course, it's ultimately up to Junio and the wider Git community,\n> and I would love to hear their thoughts about it.\n\nI would not hold my breath.\n\n> > In the meantime there's no reason to have subpar documentation.\n> \n> My only serious objection to this patch is the instruction to merge if\n> you don't know what to do instead of asking the repository maintainer\n> what to do or reading the Git documentation. I don't have a strong\n> opinion on the rest of the patch.\n\nI would be fine if the patch is merged without that line, but I believe\nthe patch is better with that line.\n\nThe line doesn't say \"do this this if you don't know what to do\", it\nsays if you are *unsure*. That is not the same thing.\n\nAnd the user *already* did a merge, as that's what 'git pull' does by\ndefault. The advice throws a warning, but proceeds with the merge.\n\nThe only thing the line is telling the user is how to muffle the message\nif she is unsure of the previous muffling options.\n\nWould you be happier with this?\n\n The simplest way to maintain the current behavior is to just do\n \"git pull --no-rebase\".\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"428177","messageId":"0fd6f76d-a65c-6706-802e-c04d5091e83e@gmail.com","threadId":"55978","inReplyTo":"20210621175234.1079004-2-felipe.contreras@gmail.com","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-06-22T05:51:24Z","receivedAt":"2021-06-22T05:51:36Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 22/06/21 00.52, Felipe Contreras wrote:\n> We want users to know what is a fast-forward in order to understand the\n> default warning.\n> \n> Let's expand the explanation in order to cover both the simple, and the\n> complex cases with as much detail as possible.\n> \n> Signed-off-by: Felipe Contreras \n> ---\n> Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------\n> 1 file changed, 35 insertions(+), 6 deletions(-)\n> \n> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n> index 5c3fb67c01..142df1c4a1 100644\n> --- a/Documentation/git-pull.txt\n> +++ b/Documentation/git-pull.txt\n> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> ------------\n> \t A---B---C master on origin\n> \t /\n> - D---E---F---G master\n> + D---E master\n> \t^\n> \torigin/master in your repository\n> ------------\n> \n> Then \"`git pull`\" will fetch and replay the changes from the remote\n> `master` branch since it diverged from the local `master` (i.e., `E`)\n> -until its current commit (`C`) on top of `master` and record the\n> -result in a new commit along with the names of the two parent commits\n> -and a log message from the user describing the changes.\n> +until its current commit (`C`) on top of `master`.\n> +\n> +After the remote changes have been synchronized, the local `master` will\n> +be fast-forwarded to the same commit as the remote one, therefore\n> +creating a linear history.\n> +\n> +------------\n> + D---E---A---B---C master, origin/master\n> +------------\n> +\n\nIsn't fast-forward merge simply moving HEAD to point at newly incoming \ncommit from origin (in this case commit C) without creating merge commit?\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"428199","messageId":"CABPp-BF1noWhiJadHzjJmnGo8hdZj6Fk7XnZ=u6BVVSGfHE7og@mail.gmail.com","threadId":"55978","inReplyTo":"CAMMLpeRa3atkZxEtV--YD6-JSf0Bp9xRw9kS5wSWerxpsGrvrw@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-22T15:06:30Z","receivedAt":"2021-06-22T15:06:47Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie wrote:\n>\n> My only serious objection to this patch is the instruction to merge if\n> you don't know what to do instead of asking the repository maintainer\n> what to do or reading the Git documentation. I don't have a strong\n> opinion on the rest of the patch.\n\nYou're not alone, Alex; I objected to that part as well. (See e.g.\nhttps://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/\nand various other emails in that thread, ending with \"agree to\ndisagree\" later). I still object to it as I did then.\n\nI'm curious whether it'll just be resubmitted again multiple times,\neventually with a cover letter that repeats something along the lines\nof \"these are the non-controversial changes from last-year series\nwhich...don't have any reason not to be merged.\"\n"},{"id":"428233","messageId":"CAMMLpeTmYcJHf1t7VpOBakMZ_vtk+9bmLRTMA9ueghG6WwCRtA@mail.gmail.com","threadId":"55978","inReplyTo":"CABPp-BF1noWhiJadHzjJmnGo8hdZj6Fk7XnZ=u6BVVSGfHE7og@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-06-22T21:22:12Z","receivedAt":"2021-06-22T21:22:30Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Tue, Jun 22, 2021 at 9:06 AM Elijah Newren wrote:\n>\n> On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie wrote:\n> >\n> > My only serious objection to this patch is the instruction to merge if\n> > you don't know what to do instead of asking the repository maintainer\n> > what to do or reading the Git documentation. I don't have a strong\n> > opinion on the rest of the patch.\n>\n> You're not alone, Alex; I objected to that part as well. (See e.g.\n> https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/\n> and various other emails in that thread, ending with \"agree to\n> disagree\" later). I still object to it as I did then.\n\nThanks for the link, and sorry for not having followed this\nconversation closely enough to have seen your previous replies. While\nwe're on the subject, do you have any thoughts on what (if anything)\nmore should be done before making the switch to aborting instead of\nmerging with a warning in `git pull`?\n\n-Alex\n"},{"id":"428236","messageId":"20210623004815.1807-1-felipe.contreras@gmail.com","threadId":"55978","inReplyTo":"20210621175234.1079004-1-felipe.contreras@gmail.com","subject":"[PATCH v2 0/2] pull: documentation improvements","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T00:48:13Z","receivedAt":"2021-06-23T00:48:26Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"These are the non-controversial changes from last-year series [1] which\nobjectively improve our documentation and don't have any reason not to\nbe merged.\n\nNot everyone knows what a rebase or a fast-forward is.\n\nSince v1 I removed one line of advice because now a second person--Alex\nHenrie--objected to it. The line is still useful, but can be added\nlater.\n\n[1] https://lore.kernel.org/git/20201218211026.1937168-1-felipe.contreras@gmail.com/\n\nFelipe Contreras (2):\n doc: pull: explain what is a fast-forward\n pull: improve default warning\n\n Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------\n builtin/pull.c | 21 +++++++++----------\n 2 files changed, 46 insertions(+), 16 deletions(-)\n\nRange-diff against v1:\n1: 949e814b27 = 1: 949e814b27 doc: pull: explain what is a fast-forward\n2: 8a72fa35ef ! 2: cfb60a24d6 pull: improve default warning\n @@ builtin/pull.c: static int get_can_ff(struct object_id *orig_head, struct object\n +\t\t \" git config --global pull.rebase true # rebase\\n\"\n +\t\t \" git config --global pull.ff only # fast-forward only\\n\"\n +\t\t \"\\n\"\n -+\t\t \"If unsure, run \\\"git pull --no-rebase\\\".\\n\"\n +\t\t \"Read \\\"git pull --help\\\" for more information.\"));\n }\n \n-- \n2.32.0\n\n"},{"id":"428237","messageId":"20210623004815.1807-2-felipe.contreras@gmail.com","threadId":"55978","inReplyTo":"20210623004815.1807-1-felipe.contreras@gmail.com","subject":"[PATCH v2 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T00:48:14Z","receivedAt":"2021-06-23T00:48:27Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"We want users to know what is a fast-forward in order to understand the\ndefault warning.\n\nLet's expand the explanation in order to cover both the simple, and the\ncomplex cases with as much detail as possible.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------\n 1 file changed, 35 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 5c3fb67c01..142df1c4a1 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n ------------\n \t A---B---C master on origin\n \t /\n- D---E---F---G master\n+ D---E master\n \t^\n \torigin/master in your repository\n ------------\n \n Then \"`git pull`\" will fetch and replay the changes from the remote\n `master` branch since it diverged from the local `master` (i.e., `E`)\n-until its current commit (`C`) on top of `master` and record the\n-result in a new commit along with the names of the two parent commits\n-and a log message from the user describing the changes.\n+until its current commit (`C`) on top of `master`.\n+\n+After the remote changes have been synchronized, the local `master` will\n+be fast-forwarded to the same commit as the remote one, therefore\n+creating a linear history.\n+\n+------------\n+ D---E---A---B---C master, origin/master\n+------------\n+\n+However, a non-fast-forward case looks very different:\n+\n+------------\n+\t A---B---C origin/master\n+\t /\n+ D---E---F---G master\n+------------\n+\n+If there are additional changes in the local `master`, it's\n+not possible to fast-forward, so a decision must be made how to\n+synchronize the local, and remote brances.\n+\n+In these situations `git pull` will warn you about your possible\n+options, which are either merge (`--no-rebase`), or rebase (`--rebase`).\n+However, by default it will continue doing a merge.\n+\n+A merge will create a new commit with two parent commits (`G` and `C`)\n+and a log message describing the changes, which you can edit.\n \n ------------\n \t A---B---C origin/master\n@@ -58,8 +83,11 @@ and a log message from the user describing the changes.\n D---E---F---G---H master\n ------------\n \n+Once the merge commit is created (`H`), your local `master` branch has\n+incorporated the changes of the remote `master` branch.\n+\n See linkgit:git-merge[1] for details, including how conflicts\n-are presented and handled.\n+are presented and handled, and also linkgit:git-rebase[1].\n \n In Git 1.7.0 or later, to cancel a conflicting merge, use\n `git reset --merge`. *Warning*: In older versions of Git, running 'git pull'\n@@ -248,7 +276,8 @@ version.\n \n SEE ALSO\n --------\n-linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1]\n+linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-rebase[1],\n+linkgit:git-config[1]\n \n GIT\n ---\n-- \n2.32.0\n\n"},{"id":"428238","messageId":"20210623004815.1807-3-felipe.contreras@gmail.com","threadId":"55978","inReplyTo":"20210623004815.1807-1-felipe.contreras@gmail.com","subject":"[PATCH v2 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T00:48:15Z","receivedAt":"2021-06-23T00:48:30Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"According to feedback from GitHub trainers [1], most newcomers don't\nunderstand what a rebase is. So in the default warning we want to\nprovide our users with a command that does the most sensible thing,\nfixes the divergence, gets rid of the warning, with the minimum mental\neffort, and happens to be the default:\n\n git pull --no-rebase (later --merge)\n\nIn addition, we don't want to start by recommending a permanent\nconfiguration, but a temporary solution so they start training their\nfingers and maybe learn how to do a rebase. So we start with the commands.\n\nAlso, we need to be clear about what we mean by \"specifying\"; merge, or\nrebase.\n\nMoreover, thanks to the previous patch now \"git pull --help\" explains\nwhat a fast-forward is, let's mention that reference.\n\nAnd finally, use --global in the configuration commands like we did with\npush.default.\n\n[1] https://lore.kernel.org/git/20130909201751.GA14437@sigill.intra.peff.net/\n\nSigned-off-by: Felipe Contreras \n---\n builtin/pull.c | 21 +++++++++++----------\n 1 file changed, 11 insertions(+), 10 deletions(-)\n\ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex 3e13f81084..ede2895ecd 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -927,18 +927,19 @@ static int get_can_ff(struct object_id *orig_head, struct object_id *orig_merge_\n \n static void show_advice_pull_non_ff(void)\n {\n-\tadvise(_(\"Pulling without specifying how to reconcile divergent branches is\\n\"\n-\t\t \"discouraged. You can squelch this message by running one of the following\\n\"\n-\t\t \"commands sometime before your next pull:\\n\"\n+\tadvise(_(\"Pulling without specifying how to reconcile divergent branches is discouraged;\\n\"\n+\t\t \"you need to specify if you want a merge, or a rebase.\\n\"\n \t\t \"\\n\"\n-\t\t \" git config pull.rebase false # merge (the default strategy)\\n\"\n-\t\t \" git config pull.rebase true # rebase\\n\"\n-\t\t \" git config pull.ff only # fast-forward only\\n\"\n+\t\t \" git pull --no-rebase # the default (merge)\\n\"\n+\t\t \" git pull --rebase\\n\"\n \t\t \"\\n\"\n-\t\t \"You can replace \\\"git config\\\" with \\\"git config --global\\\" to set a default\\n\"\n-\t\t \"preference for all repositories. You can also pass --rebase, --no-rebase,\\n\"\n-\t\t \"or --ff-only on the command line to override the configured default per\\n\"\n-\t\t \"invocation.\\n\"));\n+\t\t \"You can squelch this message by running one of the following commands:\\n\"\n+\t\t \"\\n\"\n+\t\t \" git config --global pull.rebase false # merge\\n\"\n+\t\t \" git config --global pull.rebase true # rebase\\n\"\n+\t\t \" git config --global pull.ff only # fast-forward only\\n\"\n+\t\t \"\\n\"\n+\t\t \"Read \\\"git pull --help\\\" for more information.\"));\n }\n \n int cmd_pull(int argc, const char **argv, const char *prefix)\n-- \n2.32.0\n\n"},{"id":"428240","messageId":"60d289c84fadf_312208dc@natae.notmuch","threadId":"55978","inReplyTo":"CABPp-BF1noWhiJadHzjJmnGo8hdZj6Fk7XnZ=u6BVVSGfHE7og@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T01:09:28Z","receivedAt":"2021-06-23T01:09:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie wrote:\n> >\n> > My only serious objection to this patch is the instruction to merge if\n> > you don't know what to do instead of asking the repository maintainer\n> > what to do or reading the Git documentation. I don't have a strong\n> > opinion on the rest of the patch.\n> \n> You're not alone, Alex; I objected to that part as well. (See e.g.\n> https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/\n> and various other emails in that thread, ending with \"agree to\n> disagree\" later). I still object to it as I did then.\n\nYou made your disagreement known in [1], I responded to it with a\ndevastating argument in [2], and you immediately withtdrew from the\ndiscussion in [3] without engaging my argument at all.\n\nIn total you engaged with my arguments zero times.\n\nThis is all you replied:\n\n Yes, we can agree to disagree on this particular point.\n\nTo make the record straight, I'm restating the argument you avoided in full:\n\n But that is not the warning, this is the warning:\n\n Pulling without specifying how to reconcile divergent branches is discouraged;\n you need to specify if you want a merge, a rebase, or a fast-forward.\n You can squelch this message by running one of the following commands:\n\n git config pull.rebase false # merge (the default strategy)\n git config pull.rebase true # rebase\n git config pull.ff only # fast-forward only\n\n You can replace \"git config\" with \"git config --global\" to set a default\n preference for all repositories.\n If unsure, run \"git pull --merge\".\n Read \"git pull --help\" for more information.\n\n This warning says:\n\n 1. There's 3 options: merge, rebase, fast-forward\n 2. merge is the default strategy\n 3. If unsure, specify --merge (the default strategy)\n\n So taken altogether it does say what is the default strategy.\n\n > More\n > importantly, it makes a recommendation...and one that undercuts the\n > point of the message.\n\n So?\n\n When boarding a plane the flight attendants do a safety demonstration\n that passengers should pay attention to. If one passenger is not\n paying attention (listening to music on headphones, and reading a\n book) what should the crew do?\n\n 1. Remove the passenger's headphones and force him to pay attention to\n the safety demonstration\n 2. Let the passenger ignore the safety demonstration\n\n Human beings are independent agents responsible for their own actions.\n You as a separate human being--a crew member--can argue that it's not\n in the best interest of the passenger to ignore the safety\n demonstration, and you may be right, but the passenger decisions are\n still the passenger's decisions, even if they are bad.\n\n Do you think the crew should disregard the passenger's volition and\n force him to pay attention to the safety demonstration?\n\n > It makes it feel like the message shouldn't\n > exist at all in any circumstances. I even suspect that adding that\n > sentence may undercut any efforts towards changing the default to\n > ff-only-as-default. While I'm a big fan of most of what you've done\n > in this series, I will object to its merging for as long as this\n > stays. (I definitely don't have veto power or anything close to it,\n > just stating what my opinion is.)\n\n The current warning should not exist at all.\n\n The complaint from Vít Ondruch [1] that reignited this series is a\n valid one. A *permanent* warning is not good. We should have a\n *temporary* warning with the express purpose of notifying users of an\n upcoming change.\n\n If we have not yet decided on what should be the default (Junio seems\n to have casted some doubt on the consensus [2]), and we don't have a\n clear path forward to implement such change (we can't even tell users\n to use \"pull.ff=only\", since eventually it may be\n \"pull.mode=ff-only\"), then we must remove the warning.\n\n It was a mistake to put a *permanent* warning before deciding to\n change the default.\n\n So, there's two options:\n\n 1. We decide on a path forward and fix the warning so it *temporarily*\n explains what will happen in the future\n 2. We remove the *permanent* warning\n\n Since we are already here, we might as well take advantage of that\n warning and repurpose it. But in the meantime--while the git project\n decides what to do, and what configurations to suggest the users to\n change--we should at the very least waste as little as the user's time\n as possible, and give him/her a quick opt-out.\n\n Yes, a quick opt-out defeats the purpose of a warning, but we must\n respect the users' volition. The user may be on a deadline trying to\n push some changes to production before the weekend, and after a system\n update be annoyed with this warning on every pull. The user may not\n have time to look at the warning, decide he wants to read the warning\n in the future, maybe next Monday, and thus not configure anything to\n silence it.\n\n What's wrong with a user saying \"I don't have time for this now,\n please tell me what to do for now, I'll look at the warning later\"? If\n anything for those users the configuration is the wrong thing to do,\n because being in a hurry they just choose the first configuration and\n forget about the warning without actually looking at it (because they\n didn't have time), and it will not appear any more. By typing \"git\n pull --merge\" the user can get rid of the warning *for now*, but the\n next time he does \"git pull\" the warning will reappear, and at that\n time perhaps the user does have the time to read it, and look at the\n manpage.\n\n Nobody likes their workflow to be interrupted and be forced to do anything.\n\n I don't think my patches plus that suggestion for a quick opt-out are\n in any way worse than the current situation. If you think they are,\n then we'll just have to agree to disagree.\n\n I quote the voice of Vít Ondruch, which I think represents the typical\n user: \"please select any strategy considered more appropriate and stop\n warning me\".\n\n Cheers.\n\n [1] https://lore.kernel.org/git/742df4c2-2bc5-8a4b-8de1-cd5e48718398@redhat.com/\n [2] https://lore.kernel.org/git/xmqqh7p1fjml.fsf@gitster.c.googlers.com/\n\n> I'm curious whether it'll just be resubmitted again multiple times,\n> eventually with a cover letter that repeats something along the lines\n> of \"these are the non-controversial changes from last-year series\n> which...don't have any reason not to be merged.\"\n\nThe fact that **one** person was not 100% on board with a change doesn't\nmake it controversial.\n\nYou made the conscious choice to withdraw from the discussion\nimmediately, so just like a person who abandons an election cycle and\ndecides not to vote, you are leving the future of the matter in the\nhands of others.\n\nIf you want to rejoin the discussion, feel free to respond to my\nargument that you dodged last round [3].\n\nCheers.\n\n[1] https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwBF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_QrU5818CqhRt_Q@mail.gmail.com/\n[2] https://lore.kernel.org/git/CAMP44s2L24jhCG9ps72--ZiJkXUovR726jCf8JTLHAs0jV7Whg@mail.gmail.com/\n[3] https://lore.kernel.org/git/CABPp-BGdNt8TBMTE9zvaicF5AtvyTBhpiJXqkuZc7mBLGbw0Qw@mail.gmail.com/\n\n-- \nFelipe Contreras"},{"id":"428241","messageId":"60d28a58e18f9_312208d9@natae.notmuch","threadId":"55978","inReplyTo":"0fd6f76d-a65c-6706-802e-c04d5091e83e@gmail.com","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T01:11:52Z","receivedAt":"2021-06-23T01:11:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Bagas Sanjaya wrote:\n> On 22/06/21 00.52, Felipe Contreras wrote:\n> > We want users to know what is a fast-forward in order to understand the\n> > default warning.\n> > \n> > Let's expand the explanation in order to cover both the simple, and the\n> > complex cases with as much detail as possible.\n> > \n> > Signed-off-by: Felipe Contreras \n> > ---\n> > Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------\n> > 1 file changed, 35 insertions(+), 6 deletions(-)\n> > \n> > diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n> > index 5c3fb67c01..142df1c4a1 100644\n> > --- a/Documentation/git-pull.txt\n> > +++ b/Documentation/git-pull.txt\n> > @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> > ------------\n> > \t A---B---C master on origin\n> > \t /\n> > - D---E---F---G master\n> > + D---E master\n> > \t^\n> > \torigin/master in your repository\n> > ------------\n> > \n> > Then \"`git pull`\" will fetch and replay the changes from the remote\n> > `master` branch since it diverged from the local `master` (i.e., `E`)\n> > -until its current commit (`C`) on top of `master` and record the\n> > -result in a new commit along with the names of the two parent commits\n> > -and a log message from the user describing the changes.\n> > +until its current commit (`C`) on top of `master`.\n> > +\n> > +After the remote changes have been synchronized, the local `master` will\n> > +be fast-forwarded to the same commit as the remote one, therefore\n> > +creating a linear history.\n> > +\n> > +------------\n> > + D---E---A---B---C master, origin/master\n> > +------------\n> > +\n> \n> Isn't fast-forward merge simply moving HEAD to point at newly incoming \n> commit from origin (in this case commit C) without creating merge commit?\n\nYes, but that's not always possible. The changed documentation is trying\nto shine a light into when it is possible, when it isn't, and why.\n\n-- \nFelipe Contreras\n"},{"id":"428247","messageId":"CABPp-BEnPrg_tsqLtmj7Ag6JnR6ku_K3Uv65rdRu-j9_qMYhmA@mail.gmail.com","threadId":"55978","inReplyTo":"CAMMLpeTmYcJHf1t7VpOBakMZ_vtk+9bmLRTMA9ueghG6WwCRtA@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-23T02:20:00Z","receivedAt":"2021-06-23T02:20:13Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie wrote:\n>\n> On Tue, Jun 22, 2021 at 9:06 AM Elijah Newren wrote:\n> >\n> > On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie wrote:\n> > >\n> > > My only serious objection to this patch is the instruction to merge if\n> > > you don't know what to do instead of asking the repository maintainer\n> > > what to do or reading the Git documentation. I don't have a strong\n> > > opinion on the rest of the patch.\n> >\n> > You're not alone, Alex; I objected to that part as well. (See e.g.\n> > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/\n> > and various other emails in that thread, ending with \"agree to\n> > disagree\" later). I still object to it as I did then.\n>\n> Thanks for the link, and sorry for not having followed this\n> conversation closely enough to have seen your previous replies. While\n\nNo worries, you were trying to be a good citizen by reviewing patches,\nand the patches didn't come with links to the old threads (even if you\nrecursively followed links provided in each email as far as I can\ntell), so I wouldn't expect you to know. But I saw you expressing\nsimilar sentiments as I had previously so I dug out my old email and\nlinked it.\n\n> we're on the subject, do you have any thoughts on what (if anything)\n> more should be done before making the switch to aborting instead of\n> merging with a warning in `git pull`?\n\nI think Junio already answered that over here:\nhttps://lore.kernel.org/git/xmqq360h8286.fsf@gitster.c.googlers.com/\n(he discussed it multiple times in that thread, but hopefully that's a\ngood enough example).\n"},{"id":"428254","messageId":"60d2b5ffc23af_1b53208aa@natae.notmuch","threadId":"55978","inReplyTo":"CABPp-BEnPrg_tsqLtmj7Ag6JnR6ku_K3Uv65rdRu-j9_qMYhmA@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T04:18:07Z","receivedAt":"2021-06-23T04:18:11Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie wrote:\n> >\n> > On Tue, Jun 22, 2021 at 9:06 AM Elijah Newren wrote:\n> > >\n> > > On Mon, Jun 21, 2021 at 8:15 PM Alex Henrie wrote:\n> > > >\n> > > > My only serious objection to this patch is the instruction to merge if\n> > > > you don't know what to do instead of asking the repository maintainer\n> > > > what to do or reading the Git documentation. I don't have a strong\n> > > > opinion on the rest of the patch.\n> > >\n> > > You're not alone, Alex; I objected to that part as well. (See e.g.\n> > > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/\n> > > and various other emails in that thread, ending with \"agree to\n> > > disagree\" later). I still object to it as I did then.\n> >\n> > Thanks for the link, and sorry for not having followed this\n> > conversation closely enough to have seen your previous replies. While\n> \n> No worries, you were trying to be a good citizen by reviewing patches,\n> and the patches didn't come with links to the old threads\n\nThat's not true. This patch series [1] came with a link to the previous\npatch series [2].\n\nI didn't, cannot, and shouldn't contain hundreds of links to the hundres\nof responses to this topic over the past 10 years.\n\n[1] https://lore.kernel.org/git/20210621175234.1079004-1-felipe.contreras@gmail.com/\n[2] https://lore.kernel.org/git/20201218211026.1937168-1-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"428257","messageId":"CABPp-BEPgUAe-efyk-Y5AVXRe64uUtz0XUJ-fPzKi8eSfnEquA@mail.gmail.com","threadId":"55978","inReplyTo":"60d2b5ffc23af_1b53208aa@natae.notmuch","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-23T06:47:45Z","receivedAt":"2021-06-23T06:47:59Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jun 22, 2021 at 9:18 PM Felipe Contreras\n wrote:\n>\n> Elijah Newren wrote:\n> > On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie wrote:\n> > >\n....\n> > > Thanks for the link, and sorry for not having followed this\n> > > conversation closely enough to have seen your previous replies. While\n> >\n> > No worries, you were trying to be a good citizen by reviewing patches,\n> > and the patches didn't come with links to the old threads\n>\n> That's not true. This patch series [1] came with a link to the previous\n> patch series [2].\n>\n> I didn't, cannot, and shouldn't contain hundreds of links to the hundres\n> of responses to this topic over the past 10 years.\n\nSorry for being unclear; by links I meant either direct or indirect\nones. Your series came with a link to the previous series. The\nprevious series, however, only contained a link to a series you were\nbasing upon rather than to a series which contained the changes you\nwere resubmitting. Thus, following the links in each submission would\nnot get you back to the old discussions (I double checked).\n\nAlso, this particular point was not meant as a critique of your\ncurrent submission. I don't even think it's all that big a deal for\nthe previous submission either (it's an easy oversight to make given\nthat Junio submitted a portion of one of your old series). My point\nwas simply that Alex didn't need to feel bad for not having been aware\nof all the old discussions; even if he had tried to dive deep by\nrecursively following all the links, he wouldn't find it.\n"},{"id":"428259","messageId":"CABPp-BHSxNT0rG3LMrDVH64mBwTgeF197oZFnbHvvKk=SB--WA@mail.gmail.com","threadId":"55978","inReplyTo":"60d289c84fadf_312208dc@natae.notmuch","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-23T07:54:22Z","receivedAt":"2021-06-23T07:54:40Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jun 22, 2021 at 6:09 PM Felipe Contreras\n wrote:\n>\n> Elijah Newren wrote:\n...\n> > You're not alone, Alex; I objected to that part as well. (See e.g.\n> > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/\n> > and various other emails in that thread, ending with \"agree to\n> > disagree\" later). I still object to it as I did then.\n>\n> You made your disagreement known in [1], I responded to it with a\n> devastating argument in [2], and you immediately withtdrew from the\n> discussion in [3] without engaging my argument at all.\n\nI didn't find anything new or persuasive in your rehashing of your\narguments. I had stated my disagreement twice already, and having us\nboth repeat our arguments does no one any good, so I just stated we\ncan agree to disagree.\n\n> > I'm curious whether it'll just be resubmitted again multiple times,\n> > eventually with a cover letter that repeats something along the lines\n> > of \"these are the non-controversial changes from last-year series\n> > which...don't have any reason not to be merged.\"\n>\n> The fact that **one** person was not 100% on board with a change doesn't\n> make it controversial.\n\nThis is a disconcerting response. I would have thought perhaps you\nmight say \"Whoops, forgot about that part of the thread\", or \"Sorry,\ndidn't mean to include that line\". Perhaps I shouldn't be surprised\nthat you instead decided to try to redefine goal posts, but it's still\ndiscouraging.\n\nI also find your characterization of the old thread disappointing; I\nclearly cared enough to state my objection in three separate emails,\nso it's more than just \"not 100% on board\". And Junio referred to the\nanalogy in your \"devastating argument\" as \"irrelevant\", so it's not\nclear you convinced others either.\n\n> You made the conscious choice to withdraw from the discussion\n> immediately, so just like a person who abandons an election cycle and\n> decides not to vote, you are leving the future of the matter in the\n> hands of others.\n\nThis is quite a disappointing argument. If this position were to be\naccepted broadly within the project, it would suggest scorched-earth\nlast-man standing tactics -- just arguing until the other side runs\nout of energy. If that was used to determine our forward strategy,\nit'd result in a massive waste of energy, people feeling drained and\nlosing motivation to contribute, some people just deciding to leave\nthe project, and a myriad of other negative outcomes. In fact,\noccurrences of such behavior has already had such outcomes.\n\nRehashing the same arguments repeatedly damages the discourse within\nthe project as well as the project itself. There's no point in doing\nso.\n"},{"id":"428279","messageId":"60d36e5268fce_3787208fa@natae.notmuch","threadId":"55978","inReplyTo":"CABPp-BEPgUAe-efyk-Y5AVXRe64uUtz0XUJ-fPzKi8eSfnEquA@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T17:24:34Z","receivedAt":"2021-06-23T17:24:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> On Tue, Jun 22, 2021 at 9:18 PM Felipe Contreras\n> wrote:\n> >\n> > Elijah Newren wrote:\n> > > On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie wrote:\n> > > >\n> ....\n> > > > Thanks for the link, and sorry for not having followed this\n> > > > conversation closely enough to have seen your previous replies. While\n> > >\n> > > No worries, you were trying to be a good citizen by reviewing patches,\n> > > and the patches didn't come with links to the old threads\n> >\n> > That's not true. This patch series [1] came with a link to the previous\n> > patch series [2].\n> >\n> > I didn't, cannot, and shouldn't contain hundreds of links to the hundres\n> > of responses to this topic over the past 10 years.\n> \n> Sorry for being unclear; by links I meant either direct or indirect\n> ones. Your series came with a link to the previous series. The\n> previous series, however, only contained a link to a series you were\n> basing upon rather than to a series which contained the changes you\n> were resubmitting. Thus, following the links in each submission would\n> not get you back to the old discussions (I double checked).\n\nThat's true, but there's no combination of links that would get you all\nthe discussions.\n\nThere were 4 different approaches attempted, each one with their own\nthread. Also, since other people didn't follow the threads correctly I\nhad to send different versions of those threads.\n\n> Also, this particular point was not meant as a critique of your\n> current submission. I don't even think it's all that big a deal for\n> the previous submission either (it's an easy oversight to make given\n> that Junio submitted a portion of one of your old series). My point\n> was simply that Alex didn't need to feel bad for not having been aware\n> of all the old discussions; even if he had tried to dive deep by\n> recursively following all the links, he wouldn't find it.\n\nHe was aware of the old discussions, as he was part of them, but he\nchose to disengage from them [1].\n\nEither way I don't see why would anyone should feel bad about not being\naware of all the hundreds of responses over dozens of threads over\nseveral years.\n\nAll we can ask from contributors giving their feedback for free is their\nattempt to do their best, nothing more.\n\nCheers.\n\n[1] http://lore.kernel.org/git/CAMMLpeQA7VW_C4yw_8n6j_SCoGr8k4VUOUaEp98UxUAMR6-MVw@mail.gmail.com\n\n-- \nFelipe Contreras\n"},{"id":"428308","messageId":"60d37b3b77aeb_378720834@natae.notmuch","threadId":"55978","inReplyTo":"CABPp-BHSxNT0rG3LMrDVH64mBwTgeF197oZFnbHvvKk=SB--WA@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-23T18:19:39Z","receivedAt":"2021-06-23T18:19:43Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> On Tue, Jun 22, 2021 at 6:09 PM Felipe Contreras\n> wrote:\n> >\n> > Elijah Newren wrote:\n> ...\n> > > You're not alone, Alex; I objected to that part as well. (See e.g.\n> > > https://lore.kernel.org/git/CABPp-BF4rXBOKsn8bG6y3QUEtNVV9K2Pk5NmwrU5818CqhRt_Q@mail.gmail.com/\n> > > and various other emails in that thread, ending with \"agree to\n> > > disagree\" later). I still object to it as I did then.\n> >\n> > You made your disagreement known in [1], I responded to it with a\n> > devastating argument in [2], and you immediately withtdrew from the\n> > discussion in [3] without engaging my argument at all.\n> \n> I didn't find anything new or persuasive in your rehashing of your\n> arguments.\n\nThe fact that you don't find something persuasive doesn't mean there\nwasn't anything persuasive.\n\nMoreover, the argument was completely new.\n\n> I had stated my disagreement twice already, and having us both repeat\n> our arguments does no one any good, so I just stated we can agree to\n> disagree.\n\nI did not repeat my argument, I made a completely new argument.\n\n> > > I'm curious whether it'll just be resubmitted again multiple times,\n> > > eventually with a cover letter that repeats something along the lines\n> > > of \"these are the non-controversial changes from last-year series\n> > > which...don't have any reason not to be merged.\"\n> >\n> > The fact that **one** person was not 100% on board with a change doesn't\n> > make it controversial.\n> \n> This is a disconcerting response.\n\nWhy? That's the definition of the word \"controversial\". In order for X\nto be controversial a substantive amount of people need to have opposing\nviews.\n\nThe fact that a few people deny the roundness of the Earth doesn't make\nthat idea \"controversial\".\n\nSimilarly, the fact that one person disagrees with X doesn't make X\ncontroversial.\n\n> I also find your characterization of the old thread disappointing; I\n> clearly cared enough to state my objection in three separate emails,\n> so it's more than just \"not 100% on board\".\n\nI said \"change\", not \"thread\".\n\nAnd, you were on board with 23 out of 24 lines of the patch. So you were\n96% on board. That's just a mathematical fact.\n\n> And Junio referred to the analogy in your \"devastating argument\" as\n> \"irrelevant\", so it's not clear you convinced others either.\n\nJunio is not infallible. The fact that Junio said X was irrelevant\ndoesn't mean X was irrelevant.\n\nAnd in this particular case he was wrong, as I explained in [1], because\nhe equated apples (regulations) to oranges (policy).\n\nTo be specific: this is a false equivalence fallacy.\n\nWhen I pointed out that fallacy he didn't bother to reply [2].\n\n> > You made the conscious choice to withdraw from the discussion\n> > immediately, so just like a person who abandons an election cycle and\n> > decides not to vote, you are leving the future of the matter in the\n> > hands of others.\n> \n> This is quite a disappointing argument. If this position were to be\n> accepted broadly within the project, it would suggest scorched-earth\n> last-man standing tactics -- just arguing until the other side runs\n> out of energy. If that was used to determine our forward strategy,\n> it'd result in a massive waste of energy, people feeling drained and\n> losing motivation to contribute, some people just deciding to leave\n> the project, and a myriad of other negative outcomes.\n\nThis is how progress is achieved in all areas of society, from public\ndebates, to trials, to elections.\n\nYou can't just stand up and leave when the debate is only 25% complete,\nand then expect to win it.\n\nEither you care enough see it through, or you don't.\n\nEven in sports, and in video games, completing the match is the bare\nminimum to win.\n\nUnlike in a video game, the fact that you left the debate doesn't\nnecessarily mean you lost, but you definitely did not win it.\n\n> In fact, occurrences of such behavior has already had such outcomes.\n\nThat's your opinion, my opinion is the exact opposite.\n\nThe reason people have left the project is because even though they\ncare, and they stay for 100% of the race, if some bigwig who only said\n\"I disagree\" and left having only participated in 10% of the debate, the\ndebate is over, always in favor of the incumbents.\n\nThis is not a fair marketplace of ideas where the best ideas win, it's\nnot a meritocracy, and discourages anyone who is not already part of the\nbig club.\n\n> Rehashing the same arguments repeatedly damages the discourse within\n> the project as well as the project itself. There's no point in doing\n> so.\n\nAll philosophers would disagree with you.\n\nThere are some debates that have lasted for millennia and still continue\ntoday. Many arguments for free will are repeated exactly the same, but\nsome are slightly different, and merit a new look. As long as we don't\nsolve this debate, it will continue, and everyone that cares sees value\nin it.\n\nSimilarly, until \"git pull\" does something sensible by default (which\nisn't the case now), these debates will continue, and there's value in\nthem.\n\nPerhaps if other people didn't stand up and left in the middle of the\ndebate in 2013 we would have solved the issue back then and we wouldn't\nbe here.\n\nBut here we are yet again, and if people continue ignoring arguments and\nleaving the debate before it's even 10% done, we will be here again in\n2022, 2024, and probably more.\n\nEspecially if they straight-up reject patches that according to\nthemselves are 96% perfectly fine.\n\nCheers.\n\n[1] https://lore.kernel.org/git/CAMP44s2XFQoda_PMULWha-rj9HhNfEddO5fikmswk9=AWN4RCw@mail.gmail.com/\n[2] https://lore.kernel.org/git/xmqqpn3lbhxn.fsf@gitster.c.googlers.com/\n\n-- \nFelipe Contreras\n"},{"id":"428355","messageId":"CAMMLpeTQjw0W8ZTegPru_9muRBGj7RDfk3WgEEN34vm-PG9Jfg@mail.gmail.com","threadId":"55978","inReplyTo":"60d37b3b77aeb_378720834@natae.notmuch","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-06-24T03:38:05Z","receivedAt":"2021-06-24T03:38:21Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Tue, Jun 22, 2021 at 8:20 PM Elijah Newren wrote:\n>\n> On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie wrote:\n> >\n> > While\n> > we're on the subject, do you have any thoughts on what (if anything)\n> > more should be done before making the switch to aborting instead of\n> > merging with a warning in `git pull`?\n>\n> I think Junio already answered that over here:\n> https://lore.kernel.org/git/xmqq360h8286.fsf@gitster.c.googlers.com/\n> (he discussed it multiple times in that thread, but hopefully that's a\n> good enough example).\n\nWow, if I understand correctly from that message, Junio wouldn't mind\nmaking the switch right away. That's very encouraging.\n\nOn Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras\n wrote:\n>\n> Similarly, until \"git pull\" does something sensible by default (which\n> isn't the case now), these debates will continue, and there's value in\n> them.\n\nAt this point, I'm inclined to push for s/advise/die/ in pull.c in the\nnext release, without a transitional period, just to end the argument\nover how to best explain the current awkward situation. (I'm sure\nthere will be more arguments after that, but hopefully they won't be\nas tiresome.)\n\n-Alex\n"},{"id":"428363","messageId":"60d41e6464a6c_3d32208a7@natae.notmuch","threadId":"55978","inReplyTo":"CAMMLpeTQjw0W8ZTegPru_9muRBGj7RDfk3WgEEN34vm-PG9Jfg@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-24T05:55:48Z","receivedAt":"2021-06-24T05:55:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Alex Henrie wrote:\n> On Tue, Jun 22, 2021 at 8:20 PM Elijah Newren wrote:\n> >\n> > On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie wrote:\n> > >\n> > > While\n> > > we're on the subject, do you have any thoughts on what (if anything)\n> > > more should be done before making the switch to aborting instead of\n> > > merging with a warning in `git pull`?\n> >\n> > I think Junio already answered that over here:\n> > https://lore.kernel.org/git/xmqq360h8286.fsf@gitster.c.googlers.com/\n> > (he discussed it multiple times in that thread, but hopefully that's a\n> > good enough example).\n> \n> Wow, if I understand correctly from that message, Junio wouldn't mind\n> making the switch right away. That's very encouraging.\n\nJunio has not paid enough attention to this topic. He is not aware of\nall the problems, and once he does he will very likely change his mind.\n\n> On Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras\n> wrote:\n> >\n> > Similarly, until \"git pull\" does something sensible by default (which\n> > isn't the case now), these debates will continue, and there's value in\n> > them.\n> \n> At this point, I'm inclined to push for s/advise/die/ in pull.c in the\n> next release, without a transitional period, just to end the argument\n> over how to best explain the current awkward situation. (I'm sure\n> there will be more arguments after that, but hopefully they won't be\n> as tiresome.)\n\nGive it a try. You will inevitably stumble upon all the problems I\nalready fixed.\n\nIn the meantime what's the problem with v2?\n\nCheers.\n\n[1] https://lore.kernel.org/git/20210623004815.1807-1-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"428375","messageId":"b4e612ba-21c7-3bef-d113-0f070449cd87@iee.email","threadId":"55978","inReplyTo":"20210621175234.1079004-2-felipe.contreras@gmail.com","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-06-24T14:21:53Z","receivedAt":"2021-06-24T14:21:59Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 21/06/2021 18:52, Felipe Contreras wrote:\n> We want users to know what is a fast-forward in order to understand the\n> default warning.\n>\n> Let's expand the explanation in order to cover both the simple, and the\n> complex cases with as much detail as possible.\n>\n> Signed-off-by: Felipe Contreras \n> ---\n> Documentation/git-pull.txt | 41 ++++++++++++++++++++++++++++++++------\n> 1 file changed, 35 insertions(+), 6 deletions(-)\n>\n> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n> index 5c3fb67c01..142df1c4a1 100644\n> --- a/Documentation/git-pull.txt\n> +++ b/Documentation/git-pull.txt\n> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> ------------\n> \t A---B---C master on origin\n> \t /\n> - D---E---F---G master\n> + D---E master\n> \t^\n> \torigin/master in your repository\n> ------------\n> \n> Then \"`git pull`\" will fetch and replay the changes from the remote\n> `master` branch since it diverged from the local `master` (i.e., `E`)\n> -until its current commit (`C`) on top of `master` and record the\n> -result in a new commit along with the names of the two parent commits\n> -and a log message from the user describing the changes.\n> +until its current commit (`C`) on top of `master`.\n> +\n> +After the remote changes have been synchronized, the local `master` will\n> +be fast-forwarded to the same commit as the remote one, therefore\n\nPerhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\nI.E. we highlight the term \"fast-forward\" (the purpose of the patch) and\nwe hint at the underlying mechanism of simply moving the branch pointer.\n\n> +creating a linear history.\n> +\n> +------------\n> + D---E---A---B---C master, origin/master\n> +------------\n> +\n> +However, a non-fast-forward case looks very different:\n> +\n> +------------\n> +\t A---B---C origin/master\n> +\t /\n> + D---E---F---G master\n> +------------\n> +\n> +If there are additional changes in the local `master`, it's\n> +not possible to fast-forward, so a decision must be made how to\n> +synchronize the local, and remote brances.\n> +\n> +In these situations `git pull` will warn you about your possible\n> +options, which are either merge (`--no-rebase`), or rebase (`--rebase`).\n> +However, by default it will continue doing a merge.\n> +\n> +A merge will create a new commit with two parent commits (`G` and `C`)\n> +and a log message describing the changes, which you can edit.\n> \n> ------------\n> \t A---B---C origin/master\n> @@ -58,8 +83,11 @@ and a log message from the user describing the changes.\n> D---E---F---G---H master\n> ------------\n> \n> +Once the merge commit is created (`H`), your local `master` branch has\n> +incorporated the changes of the remote `master` branch.\n> +\n> See linkgit:git-merge[1] for details, including how conflicts\n> -are presented and handled.\n> +are presented and handled, and also linkgit:git-rebase[1].\n> \n> In Git 1.7.0 or later, to cancel a conflicting merge, use\n> `git reset --merge`. *Warning*: In older versions of Git, running 'git pull'\n> @@ -248,7 +276,8 @@ version.\n> \n> SEE ALSO\n> --------\n> -linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1]\n> +linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-rebase[1],\n> +linkgit:git-config[1]\n> \n> GIT\n> ---\n\n"},{"id":"428376","messageId":"60d49748b8538_2fb2082c@natae.notmuch","threadId":"55978","inReplyTo":"b4e612ba-21c7-3bef-d113-0f070449cd87@iee.email","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-24T14:31:36Z","receivedAt":"2021-06-24T14:31:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> On 21/06/2021 18:52, Felipe Contreras wrote:\n\n> > --- a/Documentation/git-pull.txt\n> > +++ b/Documentation/git-pull.txt\n> > @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> > ------------\n> > \t A---B---C master on origin\n> > \t /\n> > - D---E---F---G master\n> > + D---E master\n> > \t^\n> > \torigin/master in your repository\n> > ------------\n> > \n> > Then \"`git pull`\" will fetch and replay the changes from the remote\n> > `master` branch since it diverged from the local `master` (i.e., `E`)\n> > -until its current commit (`C`) on top of `master` and record the\n> > -result in a new commit along with the names of the two parent commits\n> > -and a log message from the user describing the changes.\n> > +until its current commit (`C`) on top of `master`.\n> > +\n> > +After the remote changes have been synchronized, the local `master` will\n> > +be fast-forwarded to the same commit as the remote one, therefore\n> \n> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n\nNo, there's multiple steps:\n\n 1. origin/master is synchronizd with master on origin\n 2. master is fast-forwarded to origin/master\n\nSo, after 1 is done, 2 will happen.\n\n-- \nFelipe Contreras\n"},{"id":"428388","messageId":"c2170f74-b93b-599b-1fb4-45b013c7bff1@iee.email","threadId":"55978","inReplyTo":"60d49748b8538_2fb2082c@natae.notmuch","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-06-24T16:59:08Z","receivedAt":"2021-06-24T16:59:12Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Felipe,\nOn 24/06/2021 15:31, Felipe Contreras wrote:\n> Philip Oakley wrote:\n>> On 21/06/2021 18:52, Felipe Contreras wrote:\n>>> --- a/Documentation/git-pull.txt\n>>> +++ b/Documentation/git-pull.txt\n>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n>>> ------------\n>>> \t A---B---C master on origin\n>>> \t /\n>>> - D---E---F---G master\n>>> + D---E master\n>>> \t^\n>>> \torigin/master in your repository\n>>> ------------\n>>> \n>>> Then \"`git pull`\" will fetch and replay the changes from the remote\n>>> `master` branch since it diverged from the local `master` (i.e., `E`)\n>>> -until its current commit (`C`) on top of `master` and record the\n>>> -result in a new commit along with the names of the two parent commits\n>>> -and a log message from the user describing the changes.\n>>> +until its current commit (`C`) on top of `master`.\n>>> +\n>>> +After the remote changes have been synchronized, the local `master` will\n>>> +be fast-forwarded to the same commit as the remote one, therefore\n>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n> No, there's multiple steps:\nMy key point was to 'quote' the fast-forward term.\nAnd then (if suitable, with appropriate grammar corrections) indicate\nsubtly that 'nothing actually moved', we just moved the post-it note\nshowing the branch-name on the DAG [hence the confusion about timing] ;-)\n>\n> 1. origin/master is synchronizd with master on origin\n> 2. master is fast-forwarded to origin/master\n>\n> So, after 1 is done, 2 will happen.\n>\n--\nPhilip\n"},{"id":"428397","messageId":"60d4d75e7622c_242620854@natae.notmuch","threadId":"55978","inReplyTo":"c2170f74-b93b-599b-1fb4-45b013c7bff1@iee.email","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-24T19:05:02Z","receivedAt":"2021-06-24T19:05:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> Hi Felipe,\n> On 24/06/2021 15:31, Felipe Contreras wrote:\n> > Philip Oakley wrote:\n> >> On 21/06/2021 18:52, Felipe Contreras wrote:\n> >>> --- a/Documentation/git-pull.txt\n> >>> +++ b/Documentation/git-pull.txt\n> >>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> >>> ------------\n> >>> \t A---B---C master on origin\n> >>> \t /\n> >>> - D---E---F---G master\n> >>> + D---E master\n> >>> \t^\n> >>> \torigin/master in your repository\n> >>> ------------\n> >>> \n> >>> Then \"`git pull`\" will fetch and replay the changes from the remote\n> >>> `master` branch since it diverged from the local `master` (i.e., `E`)\n> >>> -until its current commit (`C`) on top of `master` and record the\n> >>> -result in a new commit along with the names of the two parent commits\n> >>> -and a log message from the user describing the changes.\n> >>> +until its current commit (`C`) on top of `master`.\n> >>> +\n> >>> +After the remote changes have been synchronized, the local `master` will\n> >>> +be fast-forwarded to the same commit as the remote one, therefore\n> >> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n> > No, there's multiple steps:\n\n> My key point was to 'quote' the fast-forward term.\n\nfast-forward is an English word [1], there's no need to quote it as if\nit weren't.\n\n> And then (if suitable, with appropriate grammar corrections) indicate\n> subtly that 'nothing actually moved', we just moved the post-it note\n> showing the branch-name on the DAG [hence the confusion about timing] ;-)\n\nA branch is a \"post-it note\", moving the post-it note is the same thing\nas moving the branch.\n\nBoth the \"origin/master\" branch, and the \"master\" branch moved. So I\ndon't know how exactly \"nothing actually moved\".\n\nPerhaps you meant no commit was created, and therefore the DAG didn't\nchange.\n\nMaybe instead of saying \"creating a linear history\", \"representing a\nlinear history\"?\n\n[1] https://www.merriam-webster.com/dictionary/fast-forward\n\n-- \nFelipe Contreras\n"},{"id":"428434","messageId":"93084036-804d-4c52-2836-42efd5deba1c@iee.email","threadId":"55978","inReplyTo":"60d4d75e7622c_242620854@natae.notmuch","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-06-24T22:07:21Z","receivedAt":"2021-06-24T22:07:24Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 24/06/2021 20:05, Felipe Contreras wrote:\n> Philip Oakley wrote:\n>> Hi Felipe,\n>> On 24/06/2021 15:31, Felipe Contreras wrote:\n>>> Philip Oakley wrote:\n>>>> On 21/06/2021 18:52, Felipe Contreras wrote:\n>>>>> --- a/Documentation/git-pull.txt\n>>>>> +++ b/Documentation/git-pull.txt\n>>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n>>>>> ------------\n>>>>> \t A---B---C master on origin\n>>>>> \t /\n>>>>> - D---E---F---G master\n>>>>> + D---E master\n>>>>> \t^\n>>>>> \torigin/master in your repository\n>>>>> ------------\n>>>>> \n>>>>> Then \"`git pull`\" will fetch and replay the changes from the remote\n>>>>> `master` branch since it diverged from the local `master` (i.e., `E`)\n>>>>> -until its current commit (`C`) on top of `master` and record the\n>>>>> -result in a new commit along with the names of the two parent commits\n>>>>> -and a log message from the user describing the changes.\n>>>>> +until its current commit (`C`) on top of `master`.\n>>>>> +\n>>>>> +After the remote changes have been synchronized, the local `master` will\n>>>>> +be fast-forwarded to the same commit as the remote one, therefore\n>>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n>>> No, there's multiple steps:\n>> My key point was to 'quote' the fast-forward term.\n> fast-forward is an English word [1], there's no need to quote it as if\n> it weren't.\n\nYou appear to be arguing that your \"explain what is a fast-forward\"\n(subject line of the patch) doesn't need, within the patch, to explain\nthat it is about the term \"fast-forward\", being used in a Git specific\nway...\n\n>\n>> And then (if suitable, with appropriate grammar corrections) indicate\n>> subtly that 'nothing actually moved', we just moved the post-it note\n>> showing the branch-name on the DAG [hence the confusion about timing] ;-)\n> A branch is a \"post-it note\", moving the post-it note is the same thing\n> as moving the branch.\n>\n> Both the \"origin/master\" branch, and the \"master\" branch moved. So I\n> don't know how exactly \"nothing actually moved\".\n>\n> Perhaps you meant no commit was created, and therefore the DAG didn't\n> change.\n>\n> Maybe instead of saying \"creating a linear history\", \"representing a\n> linear history\"?\n>\n> [1] https://www.merriam-webster.com/dictionary/fast-forward\n>\nP.\n"},{"id":"428444","messageId":"60d5183a9e34d_3a20208b@natae.notmuch","threadId":"55978","inReplyTo":"93084036-804d-4c52-2836-42efd5deba1c@iee.email","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-24T23:41:46Z","receivedAt":"2021-06-24T23:41:52Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> On 24/06/2021 20:05, Felipe Contreras wrote:\n> > Philip Oakley wrote:\n> >> Hi Felipe,\n> >> On 24/06/2021 15:31, Felipe Contreras wrote:\n> >>> Philip Oakley wrote:\n> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:\n> >>>>> --- a/Documentation/git-pull.txt\n> >>>>> +++ b/Documentation/git-pull.txt\n> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> >>>>> ------------\n> >>>>> \t A---B---C master on origin\n> >>>>> \t /\n> >>>>> - D---E---F---G master\n> >>>>> + D---E master\n> >>>>> \t^\n> >>>>> \torigin/master in your repository\n> >>>>> ------------\n> >>>>> \n> >>>>> Then \"`git pull`\" will fetch and replay the changes from the remote\n> >>>>> `master` branch since it diverged from the local `master` (i.e., `E`)\n> >>>>> -until its current commit (`C`) on top of `master` and record the\n> >>>>> -result in a new commit along with the names of the two parent commits\n> >>>>> -and a log message from the user describing the changes.\n> >>>>> +until its current commit (`C`) on top of `master`.\n> >>>>> +\n> >>>>> +After the remote changes have been synchronized, the local `master` will\n> >>>>> +be fast-forwarded to the same commit as the remote one, therefore\n> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n> >>> No, there's multiple steps:\n> >> My key point was to 'quote' the fast-forward term.\n> > fast-forward is an English word [1], there's no need to quote it as if\n> > it weren't.\n> \n> You appear to be arguing that your \"explain what is a fast-forward\"\n> (subject line of the patch) doesn't need, within the patch, to explain\n> that it is about the term \"fast-forward\", being used in a Git specific\n> way...\n\nWhen you are trying to explain the meaning of a word it's generally\nbetter to not use that word in the explanation. For example if you are\ntrying to explain \"recursion\", but you use \"recursion\" in the\nexplanation, that kinds of defeats the purpose.\n\nSo yes, in the sentence \"the local `master` will be fast-forwarded to\nthe same commit as the remote one\", the verb \"fast-forwarded\" can easily\nbe replaced with \"advanced\" and no meaning would be lost.\n\nThe meaning of this \"fast-forward\" verb is the same as when you\nfast-forward a tape, and is not git-specific.\n\n-- \nFelipe Contreras\n"},{"id":"428461","messageId":"87im22xpp4.fsf@evledraar.gmail.com","threadId":"55978","inReplyTo":"60d5183a9e34d_3a20208b@natae.notmuch","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-25T09:12:35Z","receivedAt":"2021-06-25T09:23:57Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jun 24 2021, Felipe Contreras wrote:\n\n> Philip Oakley wrote:\n>> On 24/06/2021 20:05, Felipe Contreras wrote:\n>> > Philip Oakley wrote:\n>> >> Hi Felipe,\n>> >> On 24/06/2021 15:31, Felipe Contreras wrote:\n>> >>> Philip Oakley wrote:\n>> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:\n>> >>>>> --- a/Documentation/git-pull.txt\n>> >>>>> +++ b/Documentation/git-pull.txt\n>> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n>> >>>>> ------------\n>> >>>>> \t A---B---C master on origin\n>> >>>>> \t /\n>> >>>>> - D---E---F---G master\n>> >>>>> + D---E master\n>> >>>>> \t^\n>> >>>>> \torigin/master in your repository\n>> >>>>> ------------\n>> >>>>> \n>> >>>>> Then \"`git pull`\" will fetch and replay the changes from the remote\n>> >>>>> `master` branch since it diverged from the local `master` (i.e., `E`)\n>> >>>>> -until its current commit (`C`) on top of `master` and record the\n>> >>>>> -result in a new commit along with the names of the two parent commits\n>> >>>>> -and a log message from the user describing the changes.\n>> >>>>> +until its current commit (`C`) on top of `master`.\n>> >>>>> +\n>> >>>>> +After the remote changes have been synchronized, the local `master` will\n>> >>>>> +be fast-forwarded to the same commit as the remote one, therefore\n>> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n>> >>> No, there's multiple steps:\n>> >> My key point was to 'quote' the fast-forward term.\n>> > fast-forward is an English word [1], there's no need to quote it as if\n>> > it weren't.\n>> \n>> You appear to be arguing that your \"explain what is a fast-forward\"\n>> (subject line of the patch) doesn't need, within the patch, to explain\n>> that it is about the term \"fast-forward\", being used in a Git specific\n>> way...\n>\n> When you are trying to explain the meaning of a word it's generally\n> better to not use that word in the explanation. For example if you are\n> trying to explain \"recursion\", but you use \"recursion\" in the\n> explanation, that kinds of defeats the purpose.\n>\n> So yes, in the sentence \"the local `master` will be fast-forwarded to\n> the same commit as the remote one\", the verb \"fast-forwarded\" can easily\n> be replaced with \"advanced\" and no meaning would be lost.\n>\n> The meaning of this \"fast-forward\" verb is the same as when you\n> fast-forward a tape, and is not git-specific.\n\nUsing quotes for a term like 'fast-forward' or some made up word like\n'qibbix' doesn't just serve the purpose of clarifying which ones are in\nthe dictionary, but also to establish that the quoted word is jargon\nwithin the context of the documentation.\n\nIf I invent a new and exciting way to cut grass I might say my new\nmachine 'shaves' the grass. The word \"shave\" is something I assume\neveryone knows, but I'm making it clear that I'm referring to the\nexciting mode of operation of my new death machine.\n\nSo I think it Philip's suggestion makes sense. We're not talking about\nhow to fast-forward a tape, but what happens in git when we use that\nterm.\n\nAs an aside after however many years of using git this is the first time\nI made the connection to that usage of the term, I thought it was jargon\ngit invented. That's also something to consider,\n\nI've also actually seen an interacted with a tape record and VHS tape in\nmy lifetime, but I suspect many readers of this documentation have not.\n\nThis isn't something for your patch, but I wonder more generally if we\nshouldn't consider moving away from the term entirely, and just say a\nbranch was one of:\n\n * advanced (or some other such term, forwarded?)\n * rebased\n * merged\n\nThe existence (and it being the default) of \"merge --ff\" makes that\nsomewhat difficult, but in those cases we could and probably should just\nalso say \"advanced\" (or whatever), since that's what happened, ditto a\nnoop rebase.\n\n\n\n"},{"id":"428463","messageId":"60d5b430f2f13_ba7520890@natae.notmuch","threadId":"55978","inReplyTo":"87im22xpp4.fsf@evledraar.gmail.com","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-25T10:47:12Z","receivedAt":"2021-06-25T10:47:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Jun 24 2021, Felipe Contreras wrote:\n> \n> > Philip Oakley wrote:\n> >> On 24/06/2021 20:05, Felipe Contreras wrote:\n> >> > Philip Oakley wrote:\n> >> >> Hi Felipe,\n> >> >> On 24/06/2021 15:31, Felipe Contreras wrote:\n> >> >>> Philip Oakley wrote:\n> >> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:\n> >> >>>>> --- a/Documentation/git-pull.txt\n> >> >>>>> +++ b/Documentation/git-pull.txt\n> >> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> >> >>>>> ------------\n> >> >>>>> \t A---B---C master on origin\n> >> >>>>> \t /\n> >> >>>>> - D---E---F---G master\n> >> >>>>> + D---E master\n> >> >>>>> \t^\n> >> >>>>> \torigin/master in your repository\n> >> >>>>> ------------\n> >> >>>>> \n> >> >>>>> Then \"`git pull`\" will fetch and replay the changes from the remote\n> >> >>>>> `master` branch since it diverged from the local `master` (i.e., `E`)\n> >> >>>>> -until its current commit (`C`) on top of `master` and record the\n> >> >>>>> -result in a new commit along with the names of the two parent commits\n> >> >>>>> -and a log message from the user describing the changes.\n> >> >>>>> +until its current commit (`C`) on top of `master`.\n> >> >>>>> +\n> >> >>>>> +After the remote changes have been synchronized, the local `master` will\n> >> >>>>> +be fast-forwarded to the same commit as the remote one, therefore\n> >> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n> >> >>> No, there's multiple steps:\n> >> >> My key point was to 'quote' the fast-forward term.\n> >> > fast-forward is an English word [1], there's no need to quote it as if\n> >> > it weren't.\n> >> \n> >> You appear to be arguing that your \"explain what is a fast-forward\"\n> >> (subject line of the patch) doesn't need, within the patch, to explain\n> >> that it is about the term \"fast-forward\", being used in a Git specific\n> >> way...\n> >\n> > When you are trying to explain the meaning of a word it's generally\n> > better to not use that word in the explanation. For example if you are\n> > trying to explain \"recursion\", but you use \"recursion\" in the\n> > explanation, that kinds of defeats the purpose.\n> >\n> > So yes, in the sentence \"the local `master` will be fast-forwarded to\n> > the same commit as the remote one\", the verb \"fast-forwarded\" can easily\n> > be replaced with \"advanced\" and no meaning would be lost.\n> >\n> > The meaning of this \"fast-forward\" verb is the same as when you\n> > fast-forward a tape, and is not git-specific.\n> \n> Using quotes for a term like 'fast-forward' or some made up word like\n> 'qibbix' doesn't just serve the purpose of clarifying which ones are in\n> the dictionary, but also to establish that the quoted word is jargon\n> within the context of the documentation.\n> \n> If I invent a new and exciting way to cut grass I might say my new\n> machine 'shaves' the grass. The word \"shave\" is something I assume\n> everyone knows, but I'm making it clear that I'm referring to the\n> exciting mode of operation of my new death machine.\n> \n> So I think it Philip's suggestion makes sense. We're not talking about\n> how to fast-forward a tape, but what happens in git when we use that\n> term.\n\nNo. In this particular sentence we are using fast-forward *precisely* in\nthe same way as a tape. We haven't even talked about what constitutes a\n\"fast-forward\" in git jargon.\n\nSubstitute the word \"fast-forward\", and the meaning remains intact:\n\n After the remote changes have been synchronized, the local `master`\n will be advanced to the same commit as the remote one, therefore\n creating a linear history.\n\nAs I already explained.\n\n> As an aside after however many years of using git this is the first time\n> I made the connection to that usage of the term, I thought it was jargon\n> git invented. That's also something to consider,\n\nI was in your camp, but after thinking deeply about what would be a\nbetter term than \"fast-forward\" (advance, forward, boost), I realized\nthat in fact \"fast-forward\" is perfectly fine because it already exists\nin English and conveys precisely the meaning we want: quickly advance to\na desired position.\n\n> I've also actually seen an interacted with a tape record and VHS tape in\n> my lifetime, but I suspect many readers of this documentation have not.\n\nBut they have pressed fast-forward on their Roku control, or whatever.\n\nNot only is it part of modern technology, but it's even used inside\nfilms, TV shows, and video games. See TV Tropes for dozens of examples\nwhere inside the film they fast-forward [1].\n\n> This isn't something for your patch, but I wonder more generally if we\n> shouldn't consider moving away from the term entirely, and just say a\n> branch was one of:\n> \n> * advanced (or some other such term, forwarded?)\n> * rebased\n> * merged\n> \n> The existence (and it being the default) of \"merge --ff\" makes that\n> somewhat difficult, but in those cases we could and probably should just\n> also say \"advanced\" (or whatever), since that's what happened, ditto a\n> noop rebase.\n\nI already thought about it and I don't think so. The word \"advanced\"\ndoesn't hint where, how much, or how quickly, could very well be just\none commit forward.\n\nThis is one of those rare occasions where I think the git project chose\nthe perfect word.\n\nCheers.\n\n[1] https://tvtropes.org/pmwiki/pmwiki.php/Main/FastForwardGag\n\n-- \nFelipe Contreras"},{"id":"428464","messageId":"87czsaxksc.fsf@evledraar.gmail.com","threadId":"55978","inReplyTo":"60d5b430f2f13_ba7520890@natae.notmuch","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-25T10:59:11Z","receivedAt":"2021-06-25T11:10:00Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jun 25 2021, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> \n>> On Thu, Jun 24 2021, Felipe Contreras wrote:\n>> \n>> > Philip Oakley wrote:\n>> >> On 24/06/2021 20:05, Felipe Contreras wrote:\n>> >> > Philip Oakley wrote:\n>> >> >> Hi Felipe,\n>> >> >> On 24/06/2021 15:31, Felipe Contreras wrote:\n>> >> >>> Philip Oakley wrote:\n>> >> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:\n>> >> >>>>> --- a/Documentation/git-pull.txt\n>> >> >>>>> +++ b/Documentation/git-pull.txt\n>> >> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n>> >> >>>>> ------------\n>> >> >>>>> \t A---B---C master on origin\n>> >> >>>>> \t /\n>> >> >>>>> - D---E---F---G master\n>> >> >>>>> + D---E master\n>> >> >>>>> \t^\n>> >> >>>>> \torigin/master in your repository\n>> >> >>>>> ------------\n>> >> >>>>> \n>> >> >>>>> Then \"`git pull`\" will fetch and replay the changes from the remote\n>> >> >>>>> `master` branch since it diverged from the local `master` (i.e., `E`)\n>> >> >>>>> -until its current commit (`C`) on top of `master` and record the\n>> >> >>>>> -result in a new commit along with the names of the two parent commits\n>> >> >>>>> -and a log message from the user describing the changes.\n>> >> >>>>> +until its current commit (`C`) on top of `master`.\n>> >> >>>>> +\n>> >> >>>>> +After the remote changes have been synchronized, the local `master` will\n>> >> >>>>> +be fast-forwarded to the same commit as the remote one, therefore\n>> >> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n>> >> >>> No, there's multiple steps:\n>> >> >> My key point was to 'quote' the fast-forward term.\n>> >> > fast-forward is an English word [1], there's no need to quote it as if\n>> >> > it weren't.\n>> >> \n>> >> You appear to be arguing that your \"explain what is a fast-forward\"\n>> >> (subject line of the patch) doesn't need, within the patch, to explain\n>> >> that it is about the term \"fast-forward\", being used in a Git specific\n>> >> way...\n>> >\n>> > When you are trying to explain the meaning of a word it's generally\n>> > better to not use that word in the explanation. For example if you are\n>> > trying to explain \"recursion\", but you use \"recursion\" in the\n>> > explanation, that kinds of defeats the purpose.\n>> >\n>> > So yes, in the sentence \"the local `master` will be fast-forwarded to\n>> > the same commit as the remote one\", the verb \"fast-forwarded\" can easily\n>> > be replaced with \"advanced\" and no meaning would be lost.\n>> >\n>> > The meaning of this \"fast-forward\" verb is the same as when you\n>> > fast-forward a tape, and is not git-specific.\n>> \n>> Using quotes for a term like 'fast-forward' or some made up word like\n>> 'qibbix' doesn't just serve the purpose of clarifying which ones are in\n>> the dictionary, but also to establish that the quoted word is jargon\n>> within the context of the documentation.\n>> \n>> If I invent a new and exciting way to cut grass I might say my new\n>> machine 'shaves' the grass. The word \"shave\" is something I assume\n>> everyone knows, but I'm making it clear that I'm referring to the\n>> exciting mode of operation of my new death machine.\n>> \n>> So I think it Philip's suggestion makes sense. We're not talking about\n>> how to fast-forward a tape, but what happens in git when we use that\n>> term.\n>\n> No. In this particular sentence we are using fast-forward *precisely* in\n> the same way as a tape. We haven't even talked about what constitutes a\n> \"fast-forward\" in git jargon.\n>\n> Substitute the word \"fast-forward\", and the meaning remains intact:\n>\n> After the remote changes have been synchronized, the local `master`\n> will be advanced to the same commit as the remote one, therefore\n> creating a linear history.\n>\n> As I already explained.\n\nI think even if you can accurately substitute the jargon it's worth\nquoting the jargon, to call out that it's jargon we're using quoted that\nplace and others.\n\nAnyway, that doesn't have much to do with your isolated change, just a\ngeneral comment on quoting v.s. not quoting invented\nv.s. borrowed/reused words.\n\n>> As an aside after however many years of using git this is the first time\n>> I made the connection to that usage of the term, I thought it was jargon\n>> git invented. That's also something to consider,\n>\n> I was in your camp, but after thinking deeply about what would be a\n> better term than \"fast-forward\" (advance, forward, boost), I realized\n> that in fact \"fast-forward\" is perfectly fine because it already exists\n> in English and conveys precisely the meaning we want: quickly advance to\n> a desired position.\n\nI think whatever term we're introducing will need git-specific\nexplanation. E.g. because a \"tree\" is an everyday object our use of it\nneeds explaining.\n\n>> I've also actually seen an interacted with a tape record and VHS tape in\n>> my lifetime, but I suspect many readers of this documentation have not.\n>\n> But they have pressed fast-forward on their Roku control, or whatever.\n>\n> Not only is it part of modern technology, but it's even used inside\n> films, TV shows, and video games. See TV Tropes for dozens of examples\n> where inside the film they fast-forward [1].\n\nUnfortunately I haven't been able to non-fast-forward say the Game of\nThrones TV show in such a way that the latest seasons makes any sense,\nsince no amount of button mashing will merge their version with mine :)\n\nSo I think in the context of us using this jargon to describe\ngit-specific concepts the connection to reality is tenuous at best\n\n>> This isn't something for your patch, but I wonder more generally if we\n>> shouldn't consider moving away from the term entirely, and just say a\n>> branch was one of:\n>> \n>> * advanced (or some other such term, forwarded?)\n>> * rebased\n>> * merged\n>> \n>> The existence (and it being the default) of \"merge --ff\" makes that\n>> somewhat difficult, but in those cases we could and probably should just\n>> also say \"advanced\" (or whatever), since that's what happened, ditto a\n>> noop rebase.\n>\n> I already thought about it and I don't think so. The word \"advanced\"\n> doesn't hint where, how much, or how quickly, could very well be just\n> one commit forward.\n\nHrm, we use fast-forward for N commits advanced, including N=1, or\nperhaps I'm misunderstanding you.\n\n> This is one of those rare occasions where I think the git project chose\n> the perfect word.\n\nPerhaps, it's not like I've got much in the way of a holistic world view\nwith which to replace it.\n\nI do think \"perfect\" would do a few things it doesn't though, imagine\nreading about it for the first time and not making the connection to\ntapes. Is it an optimization? Is there a slow-forward? What if upstream\nrewound there branch and I merge, is that a merge-backwards?\n\nIt's not immediately obvious how rebase/merge/fast-forward relate or\nif/when (e.g. merge sometimes being a merge-ff) they're incompatible\nconcepts.\n"},{"id":"428467","messageId":"60d5fb23c06a6_c2372086f@natae.notmuch","threadId":"55978","inReplyTo":"87czsaxksc.fsf@evledraar.gmail.com","subject":"Re: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-25T15:49:55Z","receivedAt":"2021-06-25T15:49:59Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Fri, Jun 25 2021, Felipe Contreras wrote:\n> \n> > Ævar Arnfjörð Bjarmason wrote:\n> >> \n> >> On Thu, Jun 24 2021, Felipe Contreras wrote:\n> >> \n> >> > Philip Oakley wrote:\n> >> >> On 24/06/2021 20:05, Felipe Contreras wrote:\n> >> >> > Philip Oakley wrote:\n> >> >> >> Hi Felipe,\n> >> >> >> On 24/06/2021 15:31, Felipe Contreras wrote:\n> >> >> >>> Philip Oakley wrote:\n> >> >> >>>> On 21/06/2021 18:52, Felipe Contreras wrote:\n> >> >> >>>>> --- a/Documentation/git-pull.txt\n> >> >> >>>>> +++ b/Documentation/git-pull.txt\n> >> >> >>>>> @@ -41,16 +41,41 @@ Assume the following history exists and the current branch is\n> >> >> >>>>> ------------\n> >> >> >>>>> \t A---B---C master on origin\n> >> >> >>>>> \t /\n> >> >> >>>>> - D---E---F---G master\n> >> >> >>>>> + D---E master\n> >> >> >>>>> \t^\n> >> >> >>>>> \torigin/master in your repository\n> >> >> >>>>> ------------\n> >> >> >>>>> \n> >> >> >>>>> Then \"`git pull`\" will fetch and replay the changes from the remote\n> >> >> >>>>> `master` branch since it diverged from the local `master` (i.e., `E`)\n> >> >> >>>>> -until its current commit (`C`) on top of `master` and record the\n> >> >> >>>>> -result in a new commit along with the names of the two parent commits\n> >> >> >>>>> -and a log message from the user describing the changes.\n> >> >> >>>>> +until its current commit (`C`) on top of `master`.\n> >> >> >>>>> +\n> >> >> >>>>> +After the remote changes have been synchronized, the local `master` will\n> >> >> >>>>> +be fast-forwarded to the same commit as the remote one, therefore\n> >> >> >>>> Perhaps s/be fast-forwarded/have been 'fast-forward'ed/ ?\n> >> >> >>> No, there's multiple steps:\n> >> >> >> My key point was to 'quote' the fast-forward term.\n> >> >> > fast-forward is an English word [1], there's no need to quote it as if\n> >> >> > it weren't.\n> >> >> \n> >> >> You appear to be arguing that your \"explain what is a fast-forward\"\n> >> >> (subject line of the patch) doesn't need, within the patch, to explain\n> >> >> that it is about the term \"fast-forward\", being used in a Git specific\n> >> >> way...\n> >> >\n> >> > When you are trying to explain the meaning of a word it's generally\n> >> > better to not use that word in the explanation. For example if you are\n> >> > trying to explain \"recursion\", but you use \"recursion\" in the\n> >> > explanation, that kinds of defeats the purpose.\n> >> >\n> >> > So yes, in the sentence \"the local `master` will be fast-forwarded to\n> >> > the same commit as the remote one\", the verb \"fast-forwarded\" can easily\n> >> > be replaced with \"advanced\" and no meaning would be lost.\n> >> >\n> >> > The meaning of this \"fast-forward\" verb is the same as when you\n> >> > fast-forward a tape, and is not git-specific.\n> >> \n> >> Using quotes for a term like 'fast-forward' or some made up word like\n> >> 'qibbix' doesn't just serve the purpose of clarifying which ones are in\n> >> the dictionary, but also to establish that the quoted word is jargon\n> >> within the context of the documentation.\n> >> \n> >> If I invent a new and exciting way to cut grass I might say my new\n> >> machine 'shaves' the grass. The word \"shave\" is something I assume\n> >> everyone knows, but I'm making it clear that I'm referring to the\n> >> exciting mode of operation of my new death machine.\n> >> \n> >> So I think it Philip's suggestion makes sense. We're not talking about\n> >> how to fast-forward a tape, but what happens in git when we use that\n> >> term.\n> >\n> > No. In this particular sentence we are using fast-forward *precisely* in\n> > the same way as a tape. We haven't even talked about what constitutes a\n> > \"fast-forward\" in git jargon.\n> >\n> > Substitute the word \"fast-forward\", and the meaning remains intact:\n> >\n> > After the remote changes have been synchronized, the local `master`\n> > will be advanced to the same commit as the remote one, therefore\n> > creating a linear history.\n> >\n> > As I already explained.\n> \n> I think even if you can accurately substitute the jargon it's worth\n> quoting the jargon, to call out that it's jargon we're using quoted that\n> place and others.\n\nBut in this sentence it is not jargon. Do you want me to send another\npatch using \"advance\" instead of \"fast-forward\"?\n\n> >> As an aside after however many years of using git this is the first time\n> >> I made the connection to that usage of the term, I thought it was jargon\n> >> git invented. That's also something to consider,\n> >\n> > I was in your camp, but after thinking deeply about what would be a\n> > better term than \"fast-forward\" (advance, forward, boost), I realized\n> > that in fact \"fast-forward\" is perfectly fine because it already exists\n> > in English and conveys precisely the meaning we want: quickly advance to\n> > a desired position.\n> \n> I think whatever term we're introducing will need git-specific\n> explanation. E.g. because a \"tree\" is an everyday object our use of it\n> needs explaining.\n\nBut in this specific sentence it's not a git-specific explanation. It's\nusing as few git-specific concepts, and as many non-git-specific\nconcepts, to explain a git-specific concept.\n\n> >> I've also actually seen an interacted with a tape record and VHS tape in\n> >> my lifetime, but I suspect many readers of this documentation have not.\n> >\n> > But they have pressed fast-forward on their Roku control, or whatever.\n> >\n> > Not only is it part of modern technology, but it's even used inside\n> > films, TV shows, and video games. See TV Tropes for dozens of examples\n> > where inside the film they fast-forward [1].\n> \n> Unfortunately I haven't been able to non-fast-forward say the Game of\n> Thrones TV show in such a way that the latest seasons makes any sense,\n> since no amount of button mashing will merge their version with mine :)\n\nBut they used the fast-forward gag in Deadpool. Why? Because Hollywood\nwriters know their audience, and they know virtually everyone is aware\nof what fast-forwarding is.\n\nEven the simplest remote controllers have a fast-forward button.\n\n> So I think in the context of us using this jargon to describe\n> git-specific concepts the connection to reality is tenuous at best\n\nWhy do you think it was named \"fast-forward\" in the first place? And not\nsay \"look-announce\"?\n\nI still haven't seen an argument as to why Deadpool writers (and many\nothers) would have used this concept if it weren't mainstream.\n\n> >> This isn't something for your patch, but I wonder more generally if we\n> >> shouldn't consider moving away from the term entirely, and just say a\n> >> branch was one of:\n> >> \n> >> * advanced (or some other such term, forwarded?)\n> >> * rebased\n> >> * merged\n> >> \n> >> The existence (and it being the default) of \"merge --ff\" makes that\n> >> somewhat difficult, but in those cases we could and probably should just\n> >> also say \"advanced\" (or whatever), since that's what happened, ditto a\n> >> noop rebase.\n> >\n> > I already thought about it and I don't think so. The word \"advanced\"\n> > doesn't hint where, how much, or how quickly, could very well be just\n> > one commit forward.\n> \n> Hrm, we use fast-forward for N commits advanced, including N=1, or\n> perhaps I'm misunderstanding you.\n\nFor example in the context of a film, \"advance\" could easily mean move\none second ahead, or even unpause.\n\nFast-forward on the other hand can't be used that way, it implies moving\nquickly many seconds.\n\n> > This is one of those rare occasions where I think the git project chose\n> > the perfect word.\n> \n> Perhaps, it's not like I've got much in the way of a holistic world view\n> with which to replace it.\n> \n> I do think \"perfect\" would do a few things it doesn't though, imagine\n> reading about it for the first time and not making the connection to\n> tapes. Is it an optimization? Is there a slow-forward? What if upstream\n> rewound there branch and I merge, is that a merge-backwards?\n> \n> It's not immediately obvious how rebase/merge/fast-forward relate or\n> if/when (e.g. merge sometimes being a merge-ff) they're incompatible\n> concepts.\n\nI don't think there's any word in the English language that would\nmagically place the fully-formed concept of the git's fast-forward in\nthe reader's mind.\n\nThat applies for all concepts though. A git \"branch\" needs to be\nexplained, just knowing what a branch is in English isn't enough, and if\nnobody has used a SCM, the same for a \"commit\".\n\n\nIn psychology of learning there's a concept called chunking [1]. In\norder to understand what the word \"economy\" means, you need to learn\nmany other concepts before, including the concept of \"market\", and for\nthat you need many others, including \"money\", and so on. Very complex\nconcepts are constituted by multiple big sub-chunks.\n\nTo explain the git-specific concept of a fast-forward, it's in our best\ninterest to reuse chunks that are already in the zeitgeist of the\nculture, including the non-git-specific concept of fast-forwarding.\n\nThis patch is not simply saying a \"fast-forward\" is a fast-forward. It's\nexplaining the git-specific fast-forward by capitalizing from the\ngeneral knowledge fast-forward, which is so mainstream it's even used in\nHollywood.\n\nCheers.\n\n[1] https://en.wikipedia.org/wiki/Chunking_(psychology)\n\n-- \nFelipe Contreras"},{"id":"428488","messageId":"AS8PR02MB730230DADF38B6C572CE8DC39C069@AS8PR02MB7302.eurprd02.prod.outlook.com","threadId":"55978","inReplyTo":"87czsaxksc.fsf@evledraar.gmail.com","subject":"RE: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2021-06-25T16:53:08Z","receivedAt":"2021-06-25T16:53:15Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"\n> From: Ævar Arnfjörð Bjarmason \n> Sent: 25 June 2021 11:59\n\n> >> So I think it Philip's suggestion makes sense. We're not talking\n> >> about how to fast-forward a tape, but what happens in git when we use\n> >> that term.\n> >\n> > No. In this particular sentence we are using fast-forward *precisely*\n> > in the same way as a tape. We haven't even talked about what\n> > constitutes a \"fast-forward\" in git jargon.\n> >\n> > Substitute the word \"fast-forward\", and the meaning remains intact:\n> >\n> > After the remote changes have been synchronized, the local `master`\n> > will be advanced to the same commit as the remote one, therefore\n> > creating a linear history.\n> >\n> > As I already explained.\n> \n> I think even if you can accurately substitute the jargon it's worth quoting the\n> jargon, to call out that it's jargon we're using quoted that place and others.\n> \n> Anyway, that doesn't have much to do with your isolated change, just a\n> general comment on quoting v.s. not quoting invented v.s. borrowed/reused\n> words.\n> \n> >> As an aside after however many years of using git this is the first\n> >> time I made the connection to that usage of the term, I thought it\n> >> was jargon git invented. That's also something to consider,\n> >\n> > I was in your camp, but after thinking deeply about what would be a\n> > better term than \"fast-forward\" (advance, forward, boost), I realized\n> > that in fact \"fast-forward\" is perfectly fine because it already\n> > exists in English and conveys precisely the meaning we want: quickly\n> > advance to a desired position.\n> \n> I think whatever term we're introducing will need git-specific explanation.\n> E.g. because a \"tree\" is an everyday object our use of it needs explaining.\n> \n> >> I've also actually seen an interacted with a tape record and VHS tape\n> >> in my lifetime, but I suspect many readers of this documentation have\n> not.\n> >\n> > But they have pressed fast-forward on their Roku control, or whatever.\n> >\n> > Not only is it part of modern technology, but it's even used inside\n> > films, TV shows, and video games. See TV Tropes for dozens of examples\n> > where inside the film they fast-forward [1].\n> \n> Unfortunately I haven't been able to non-fast-forward say the Game of\n> Thrones TV show in such a way that the latest seasons makes any sense,\n> since no amount of button mashing will merge their version with mine :)\n> \n> So I think in the context of us using this jargon to describe git-specific\n> concepts the connection to reality is tenuous at best\n \n\n> > This is one of those rare occasions where I think the git project\n> > chose the perfect word.\n\nI agree.\n\n> Perhaps, it's not like I've got much in the way of a holistic world view with\n> which to replace it.\n> \n> I do think \"perfect\" would do a few things it doesn't though, imagine reading\n> about it for the first time and not making the connection to tapes. Is it an\n> optimization? Is there a slow-forward? What if upstream rewound there\n> branch and I merge, is that a merge-backwards?\n> \n> It's not immediately obvious how rebase/merge/fast-forward relate or\n> if/when (e.g. merge sometimes being a merge-ff) they're incompatible\n> concepts.\n\nOn the one hand, I think fast-forward is an entirely suitable term for git to use, based on what it does. Instantaneously moving the branch head pointer forward to the new head\nOn the other hand I think it is distinctly different from the use with transport controls for linear media (ie tape - video or audio).\nFor all of them fast-forward moves the play/record point relative to the media, maybe to the end (or to \"now\"), maybe not. There may or may not be a cueing play that happens while the tape is moving.\nFor a modern stream (eg podcast) player, such as BBC Sounds (via its web-site) there is no fast-forward control. There is play/pause, +20 and -20 seconds, go to the start of the stream and (for live broadcasts) go to now. The latter is very close to Git's fast-forward, but is not labelled as such. There is also a time-line, where the user can go to an arbitrary point in time and play from there.\nHardware players do have fast-forward controls, even for streams, or files.\n\nSo, yes, the term is very widely known in the wider world (even for those who didn't grow up with tape).\nAnd yes, irrespective of the above, it makes complete sense for git's usage.\n\nRegards,\nRichard.\n\n"},{"id":"428489","messageId":"60d6138c185bf_cc8d20811@natae.notmuch","threadId":"55978","inReplyTo":"AS8PR02MB730230DADF38B6C572CE8DC39C069@AS8PR02MB7302.eurprd02.prod.outlook.com","subject":"RE: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-25T17:34:04Z","receivedAt":"2021-06-25T17:34:09Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Kerry, Richard wrote:\n> \n> > From: Ævar Arnfjörð Bjarmason \n> > Sent: 25 June 2021 11:59\n\n> > Perhaps, it's not like I've got much in the way of a holistic world view with\n> > which to replace it.\n> > \n> > I do think \"perfect\" would do a few things it doesn't though, imagine reading\n> > about it for the first time and not making the connection to tapes. Is it an\n> > optimization? Is there a slow-forward? What if upstream rewound there\n> > branch and I merge, is that a merge-backwards?\n> > \n> > It's not immediately obvious how rebase/merge/fast-forward relate or\n> > if/when (e.g. merge sometimes being a merge-ff) they're incompatible\n> > concepts.\n> \n> On the one hand, I think fast-forward is an entirely suitable term for git to use, based on what it does. Instantaneously moving the branch head pointer forward to the new head\n> On the other hand I think it is distinctly different from the use with transport controls for linear media (ie tape - video or audio).\n> For all of them fast-forward moves the play/record point relative to the media, maybe to the end (or to \"now\"), maybe not. There may or may not be a cueing play that happens while the tape is moving.\n> For a modern stream (eg podcast) player, such as BBC Sounds (via its web-site) there is no fast-forward control. There is play/pause, +20 and -20 seconds, go to the start of the stream and (for live broadcasts) go to now. The latter is very close to Git's fast-forward, but is not labelled as such. There is also a time-line, where the user can go to an arbitrary point in time and play from there.\n> Hardware players do have fast-forward controls, even for streams, or files.\n\nYes, but regardless of that for whatever reason it's already part of the\nculture, and people are using fast-forward irrespective of the original\nmeaning:\n\n \"They fast-forward to present day ten years later, where he has been\n hospitalized and is on life support.\" [1]\n\n \"So then fast-forward to now and, like, six months ago, they found the\n script and called me up.\" [2]\n\nThis is similar to what happened with the floppy disk icon. New\ngenerations may have no idea what it originally meant, regardless of\nthat today it means \"save\". Except the fast-forward button still exists\nin many remote controls.\n\nSame with other concepts like carbon copy. I'm not sure if newer\ngenerations have ever seen an actual physical carbon copy take place. Or\na physical bookmark.\n\nWords evolve beyond their original meaning, and today I think that has\nalready happened with fast-forward.\n\n> So, yes, the term is very widely known in the wider world (even for those who didn't grow up with tape).\n> And yes, irrespective of the above, it makes complete sense for git's usage.\n\nIndeed.\n\n[1] https://en.wikipedia.org/wiki/I_Need_a_Doctor\n[2] https://en.wikipedia.org/wiki/Predators_(film)\n\n-- \nFelipe Contreras"},{"id":"428506","messageId":"60d64c7bc3d52_118e82088a@natae.notmuch","threadId":"55978","inReplyTo":"60d6138c185bf_cc8d20811@natae.notmuch","subject":"RE: [PATCH 1/2] doc: pull: explain what is a fast-forward","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-25T21:36:59Z","receivedAt":"2021-06-25T21:37:05Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n\n> Yes, but regardless of that for whatever reason it's already part of the\n> culture, and people are using fast-forward irrespective of the original\n> meaning:\n> \n> \"They fast-forward to present day ten years later, where he has been\n> hospitalized and is on life support.\" [1]\n> \n> \"So then fast-forward to now and, like, six months ago, they found the\n> script and called me up.\" [2]\n\nHmmm,\n\n Fast-forward 6 years and all this code has been substantially\n overhauled by several folks over the years\n\nhttps://lore.kernel.org/git/CAPMMpohp6+jW2C0ewfYEp3rrwbKSqGVa94LRgQDcKJvYmiANuA@mail.gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"428535","messageId":"CAMMLpeSa=Shw3Y5=D9VZhRFJb922ZJD5L=X=eqGZFRkrDJG7dw@mail.gmail.com","threadId":"55978","inReplyTo":"60d41e6464a6c_3d32208a7@natae.notmuch","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-06-27T00:17:59Z","receivedAt":"2021-06-27T00:18:16Z","isPatch":true,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Wed, Jun 23, 2021 at 11:55 PM Felipe Contreras\n wrote:\n>\n> Alex Henrie wrote:\n> > On Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras\n> > wrote:\n> > >\n> > > Similarly, until \"git pull\" does something sensible by default (which\n> > > isn't the case now), these debates will continue, and there's value in\n> > > them.\n> >\n> > At this point, I'm inclined to push for s/advise/die/ in pull.c in the\n> > next release, without a transitional period, just to end the argument\n> > over how to best explain the current awkward situation. (I'm sure\n> > there will be more arguments after that, but hopefully they won't be\n> > as tiresome.)\n>\n> Give it a try. You will inevitably stumble upon all the problems I\n> already fixed.\n\nPatch sent.\n\n> In the meantime what's the problem with v2?\n\nI think that setting pull.rebase on a per-repository basis (instead of\nglobally or per-invocation) makes for the easiest workflow in the\nmajority of cases, so I would prefer to continue to recommend that to\nusers primarily, but I don't have a strong opinion.\n\n-Alex\n"},{"id":"428545","messageId":"60d7fcb7d229e_b8dfe2089f@natae.notmuch","threadId":"55978","inReplyTo":"CAMMLpeSa=Shw3Y5=D9VZhRFJb922ZJD5L=X=eqGZFRkrDJG7dw@mail.gmail.com","subject":"Re: [PATCH 2/2] pull: improve default warning","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-27T04:21:11Z","receivedAt":"2021-06-27T04:21:20Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Alex Henrie wrote:\n> On Wed, Jun 23, 2021 at 11:55 PM Felipe Contreras\n> wrote:\n> >\n> > Alex Henrie wrote:\n> > > On Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras\n> > > wrote:\n> > > >\n> > > > Similarly, until \"git pull\" does something sensible by default (which\n> > > > isn't the case now), these debates will continue, and there's value in\n> > > > them.\n> > >\n> > > At this point, I'm inclined to push for s/advise/die/ in pull.c in the\n> > > next release, without a transitional period, just to end the argument\n> > > over how to best explain the current awkward situation. (I'm sure\n> > > there will be more arguments after that, but hopefully they won't be\n> > > as tiresome.)\n> >\n> > Give it a try. You will inevitably stumble upon all the problems I\n> > already fixed.\n> \n> Patch sent.\n\nI sent a bunch of comments to the approach you sent. I think that's not\nall the issues, but it's been a while since the last time I took a good\nlook at this, I feel I'm still missing one issue.\n\n> > In the meantime what's the problem with v2?\n> \n> I think that setting pull.rebase on a per-repository basis (instead of\n> globally or per-invocation) makes for the easiest workflow in the\n> majority of cases, so I would prefer to continue to recommend that to\n> users primarily, but I don't have a strong opinion.\n\nOK. What happens if you don't have the configuration in the particular\nrepository you are using?\n\n-- \nFelipe Contreras\n"}]}