{"thread":{"id":"37598","subject":"[PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","startedAt":"2014-09-18T19:03:25Z","lastAt":"2014-09-29T20:17:48Z","messageCount":8,"participants":["Sergey Organov","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"249678","messageId":"87r3z72wiu.fsf@osv.gnss.ru","threadId":"37598","inReplyTo":null,"subject":"[PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2014-09-18T19:03:25Z","receivedAt":"2014-09-18T19:03:25Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Vanilla \"git rebase\" defaults to --fork-point that in some cases\nmakes behavior very different from \"git rebase <upstream>\",\nwhere --no-fork-point is assumed. This fact was not mentioned in\nthe DESCRIPTION section of the manual page, even though the case of\nomitted <upstream> was otherwise discussed. That in turn made actual\nbehavior of vanilla \"git rebase\" hardly discoverable.\n\nWhile we are at it, clarify the --fork-point description itself as well.\n\nSigned-off-by: Sergey Organov <sorganov@gmail.com>\n---\n Documentation/git-rebase.txt | 18 +++++++++---------\n 1 file changed, 9 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 4138554..73e1e1c 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -21,15 +21,16 @@ If <branch> is specified, 'git rebase' will perform an automatic\n it remains on the current branch.\n \n If <upstream> is not specified, the upstream configured in\n-branch.<name>.remote and branch.<name>.merge options will be used; see\n-linkgit:git-config[1] for details.  If you are currently not on any\n-branch or if the current branch does not have a configured upstream,\n-the rebase will abort.\n+branch.<name>.remote and branch.<name>.merge options will be used (see\n+linkgit:git-config[1] for details) and the `--fork-point` option is\n+assumed.  If you are currently not on any branch or if the current\n+branch does not have a configured upstream, the rebase will abort.\n \n All changes made by commits in the current branch but that are not\n in <upstream> are saved to a temporary area.  This is the same set\n-of commits that would be shown by `git log <upstream>..HEAD` (or\n-`git log HEAD`, if --root is specified).\n+of commits that would be shown by `git log <upstream>..HEAD`; or by\n+`git log <fork_point>..HEAD`, if --fork-point is either specified or\n+assumed; or by `git log HEAD`, if --root is specified.\n \n The current branch is reset to <upstream>, or <newbase> if the\n --onto option was supplied.  This has the exact same effect as\n@@ -331,9 +332,8 @@ link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details)\n \tbetween `upstream` and `branch` when calculating which commits have\n \thave been introduced by `branch` (see linkgit:git-merge-base[1]).\n +\n-If no non-option arguments are given on the command line, then the default is\n-`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally\n-unless the `--fork-point` option is specified.\n+If either <upstream> or --root is given on the command line, then the\n+default is `--no-fork-point`, otherwise the default is `--fork-point`.\n \n --ignore-whitespace::\n --whitespace=<option>::\n-- \n1.9.3\n"},{"id":"249990","messageId":"87k34mn0ht.fsf@osv.gnss.ru","threadId":"37598","inReplyTo":"87r3z72wiu.fsf@osv.gnss.ru","subject":"[PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2014-09-18T19:03:25Z","receivedAt":"2014-09-18T19:03:25Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Vanilla \"git rebase\" defaults to --fork-point that in some cases\nmakes behavior very different from \"git rebase <upstream>\",\nwhere --no-fork-point is assumed. This fact was not mentioned in\nthe DESCRIPTION section of the manual page, even though the case of\nomitted <upstream> was otherwise discussed. That in turn made actual\nbehavior of vanilla \"git rebase\" hardly discoverable.\n\nWhile we are at it, clarify the --fork-point description itself as well.\n\nSigned-off-by: Sergey Organov <sorganov@gmail.com>\n---\nAs asked by Junio C Hamano <gitster@pobox.com>, the newly introduced\n'fork_point' term has been described.\n\n\n Documentation/git-rebase.txt | 31 +++++++++++++++++++------------\n 1 file changed, 19 insertions(+), 12 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 4138554..2e6f125 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -21,15 +21,17 @@ If <branch> is specified, 'git rebase' will perform an automatic\n it remains on the current branch.\n \n If <upstream> is not specified, the upstream configured in\n-branch.<name>.remote and branch.<name>.merge options will be used; see\n-linkgit:git-config[1] for details.  If you are currently not on any\n-branch or if the current branch does not have a configured upstream,\n-the rebase will abort.\n+branch.<name>.remote and branch.<name>.merge options will be used (see\n+linkgit:git-config[1] for details) and the `--fork-point` option is\n+assumed.  If you are currently not on any branch or if the current\n+branch does not have a configured upstream, the rebase will abort.\n \n All changes made by commits in the current branch but that are not\n in <upstream> are saved to a temporary area.  This is the same set\n-of commits that would be shown by `git log <upstream>..HEAD` (or\n-`git log HEAD`, if --root is specified).\n+of commits that would be shown by `git log <upstream>..HEAD`; or by\n+`git log 'fork_point'..HEAD`, if --fork-point is either specified or\n+assumed (see --fork-point description below); or by `git log HEAD`, if\n+--root is specified.\n \n The current branch is reset to <upstream>, or <newbase> if the\n --onto option was supplied.  This has the exact same effect as\n@@ -327,13 +329,18 @@ link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details)\n \n --fork-point::\n --no-fork-point::\n-\tUse 'git merge-base --fork-point' to find a better common ancestor\n-\tbetween `upstream` and `branch` when calculating which commits have\n-\thave been introduced by `branch` (see linkgit:git-merge-base[1]).\n+\tUse reflog to find a better common ancestor between <upstream>\n+\tand <branch> when calculating which commits have been\n+\tintroduced by <branch>. \n +\n-If no non-option arguments are given on the command line, then the default is\n-`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally\n-unless the `--fork-point` option is specified.\n+When --fork-point is active, 'fork_point' will be used instead of\n+<upstream> to calculate the set of commits to rebase, where\n+'fork_point' is the result of `git merge-base --fork-point <upstream>\n+<branch>` command (see linkgit:git-merge-base[1]).  If 'fork_point'\n+ends up being empty, the <upstream> will be used instead.\n++\n+If either <upstream> or --root is given on the command line, then the\n+default is `--no-fork-point`, otherwise the default is `--fork-point`.\n \n --ignore-whitespace::\n --whitespace=<option>::\n-- \n1.9.3\n"},{"id":"249749","messageId":"xmqqzjdrjvnd.fsf@gitster.dls.corp.google.com","threadId":"37598","inReplyTo":"87r3z72wiu.fsf@osv.gnss.ru","subject":"Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-22T19:35:34Z","receivedAt":"2014-09-22T19:35:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n> Vanilla \"git rebase\" defaults to --fork-point that in some cases\n> makes behavior very different from \"git rebase <upstream>\",\n> where --no-fork-point is assumed. This fact was not mentioned in\n> the DESCRIPTION section of the manual page, even though the case of\n> omitted <upstream> was otherwise discussed. That in turn made actual\n> behavior of vanilla \"git rebase\" hardly discoverable.\n>\n> While we are at it, clarify the --fork-point description itself as well.\n>\n> Signed-off-by: Sergey Organov <sorganov@gmail.com>\n> ---\n>  Documentation/git-rebase.txt | 18 +++++++++---------\n>  1 file changed, 9 insertions(+), 9 deletions(-)\n>\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 4138554..73e1e1c 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -21,15 +21,16 @@ If <branch> is specified, 'git rebase' will perform an automatic\n>  it remains on the current branch.\n>  \n>  If <upstream> is not specified, the upstream configured in\n> -branch.<name>.remote and branch.<name>.merge options will be used; see\n> -linkgit:git-config[1] for details.  If you are currently not on any\n> -branch or if the current branch does not have a configured upstream,\n> -the rebase will abort.\n> +branch.<name>.remote and branch.<name>.merge options will be used (see\n> +linkgit:git-config[1] for details) and the `--fork-point` option is\n> +assumed.  If you are currently not on any branch or if the current\n> +branch does not have a configured upstream, the rebase will abort.\n\nOK.  When you do not tell rebase with respect to what exact _commit_\nthe operation is to be done, then we will enable --fork-point, which\nmakes perfect sense because it is clear that the user is rebasing\nwith respect to a _branch_, for which we may find a place better\nthan its current tip to rebase onto if we look at its reflog.\n\nIt is debatable if we should do the same when the user tells us to\nrebase with respect to a specific _branch_ by giving the 'upstream'\nargument, but that is an entirely separate issue.  We might want to\ndo a similar command line heuristics to tell between the branch\nswitching \"git checkout master\" (which is an operation about a\nbranch) and head detaching \"git checkout refs/heads/master^0\" (which\nis an operation about a commit) if we want to help the users by\nauto-enabling fork-point mode.\n\n>  All changes made by commits in the current branch but that are not\n>  in <upstream> are saved to a temporary area.  This is the same set\n> -of commits that would be shown by `git log <upstream>..HEAD` (or\n> -`git log HEAD`, if --root is specified).\n> +of commits that would be shown by `git log <upstream>..HEAD`; or by\n> +`git log <fork_point>..HEAD`, if --fork-point is either specified or\n> +assumed; or by `git log HEAD`, if --root is specified.\n\nOK.  <fork_point> is a new term this patch introduces to this\ndocument.  Do we define what it is anywhere in this document, or\nwould it help the readers to add something like \"... where <fork_point>\nis computed in such and such way (see ... for details)\"?\n\n> @@ -331,9 +332,8 @@ link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details)\n>  \tbetween `upstream` and `branch` when calculating which commits have\n>  \thave been introduced by `branch` (see linkgit:git-merge-base[1]).\n>  +\n> -If no non-option arguments are given on the command line, then the default is\n> -`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally\n> -unless the `--fork-point` option is specified.\n> +If either <upstream> or --root is given on the command line, then the\n> +default is `--no-fork-point`, otherwise the default is `--fork-point`.\n\nGood.  The original, especially the mention of \"@{u}\", does not make\nany sense and updated text reads more clearly.\n\nThanks.\n"},{"id":"249777","messageId":"87k34u9088.fsf@osv.gnss.ru","threadId":"37598","inReplyTo":"xmqqzjdrjvnd.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2014-09-23T09:04:23Z","receivedAt":"2014-09-23T09:04:23Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Sergey Organov <sorganov@gmail.com> writes:\n>\n>> Vanilla \"git rebase\" defaults to --fork-point that in some cases\n>> makes behavior very different from \"git rebase <upstream>\",\n>> where --no-fork-point is assumed. This fact was not mentioned in\n>> the DESCRIPTION section of the manual page, even though the case of\n>> omitted <upstream> was otherwise discussed. That in turn made actual\n>> behavior of vanilla \"git rebase\" hardly discoverable.\n>>\n>> While we are at it, clarify the --fork-point description itself as well.\n>>\n>> Signed-off-by: Sergey Organov <sorganov@gmail.com>\n>> ---\n>>  Documentation/git-rebase.txt | 18 +++++++++---------\n>>  1 file changed, 9 insertions(+), 9 deletions(-)\n>>\n>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n>> index 4138554..73e1e1c 100644\n>> --- a/Documentation/git-rebase.txt\n>> +++ b/Documentation/git-rebase.txt\n>> @@ -21,15 +21,16 @@ If <branch> is specified, 'git rebase' will perform an automatic\n>>  it remains on the current branch.\n>>  \n>>  If <upstream> is not specified, the upstream configured in\n>> -branch.<name>.remote and branch.<name>.merge options will be used; see\n>> -linkgit:git-config[1] for details.  If you are currently not on any\n>> -branch or if the current branch does not have a configured upstream,\n>> -the rebase will abort.\n>> +branch.<name>.remote and branch.<name>.merge options will be used (see\n>> +linkgit:git-config[1] for details) and the `--fork-point` option is\n>> +assumed.  If you are currently not on any branch or if the current\n>> +branch does not have a configured upstream, the rebase will abort.\n>\n> OK.  When you do not tell rebase with respect to what exact _commit_\n> the operation is to be done, then we will enable --fork-point, which\n> makes perfect sense because it is clear that the user is rebasing\n> with respect to a _branch_, for which we may find a place better\n> than its current tip to rebase onto if we look at its reflog.\n\nI think you meant to say that we may find a better source to calculate\nthe exact set of commits to rebase, as we still rebase onto the current\ntip. I.e., with this we select what to rebase, not where (the latter\nbeing handled by the --onto switch.)\n\n> It is debatable if we should do the same when the user tells us to\n> rebase with respect to a specific _branch_ by giving the 'upstream'\n> argument, but that is an entirely separate issue.  We might want to\n> do a similar command line heuristics to tell between the branch\n> switching \"git checkout master\" (which is an operation about a\n> branch) and head detaching \"git checkout refs/heads/master^0\" (which\n> is an operation about a commit) if we want to help the users by\n> auto-enabling fork-point mode.\n\nWell, IMHO \"git rebase\" and \"git rebase @{u}\" must do exactly the same\nthing. In its current state, when they have different default for\nfork-point, it's too surprising. From this POV I do like suggested\nheuristics to activate --fork-point when <upstream> (either specified or\nfigured from configuration) is a branch. However, it seems that this\nwould be functionally equivalent to just making the --fork-point the\ndefault, unconditionally, as trying to find better fork-point in a\nreflog for a non-reference will bring nothing anyway. The heuristics\ncould be considered an optimization, but it would optimize very rare\ncase.\n\nOn the other hand, I'm afraid different defaults were chosen for\nbackward compatibility?\n\n>>  All changes made by commits in the current branch but that are not\n>>  in <upstream> are saved to a temporary area.  This is the same set\n>> -of commits that would be shown by `git log <upstream>..HEAD` (or\n>> -`git log HEAD`, if --root is specified).\n>> +of commits that would be shown by `git log <upstream>..HEAD`; or by\n>> +`git log <fork_point>..HEAD`, if --fork-point is either specified or\n>> +assumed; or by `git log HEAD`, if --root is specified.\n>\n> OK.  <fork_point> is a new term this patch introduces to this\n> document.  Do we define what it is anywhere in this document, or\n> would it help the readers to add something like \"... where <fork_point>\n> is computed in such and such way (see ... for details)\"?\n\nYes, it's new and is not defined, but first I didn't want to overload\nthe DESCRIPTION with details, and second I don't know how it's actually\ndone, as it seems that \"fork_point=$(git merge-base <upstream>\n<branch>)\" sometimes returns nothing, in which case fork_point is set\nback to <upstream>? If we are going to describe it, I think it should go\nto --fork-point option description.\n\nCould you please suggest the wording?\n\n>\n>> @@ -331,9 +332,8 @@ link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details)\n>>  \tbetween `upstream` and `branch` when calculating which commits have\n>>  \thave been introduced by `branch` (see linkgit:git-merge-base[1]).\n>>  +\n>> -If no non-option arguments are given on the command line, then the default is\n>> -`--fork-point @{u}` otherwise the `upstream` argument is interpreted literally\n>> -unless the `--fork-point` option is specified.\n>> +If either <upstream> or --root is given on the command line, then the\n>> +default is `--no-fork-point`, otherwise the default is `--fork-point`.\n>\n> Good.  The original, especially the mention of \"@{u}\", does not make\n> any sense and updated text reads more clearly.\n>\n> Thanks.\n\nBR,\n-- Sergey.\n"},{"id":"249922","messageId":"xmqqvboa6lvj.fsf@gitster.dls.corp.google.com","threadId":"37598","inReplyTo":"87k34u9088.fsf@osv.gnss.ru","subject":"Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-26T22:46:24Z","receivedAt":"2014-09-26T22:46:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n> I think you meant to say that we may find a better source to calculate\n> the exact set of commits to rebase,...\n\nYes.\n\n>> It is debatable if we should do the same when the user tells us to\n>> rebase with respect to a specific _branch_ by giving the 'upstream'\n>> argument, but that is an entirely separate issue.  We might want to\n>> do a similar command line heuristics to tell between the branch\n>> switching \"git checkout master\" (which is an operation about a\n>> branch) and head detaching \"git checkout refs/heads/master^0\" (which\n>> is an operation about a commit) if we want to help the users by\n>> auto-enabling fork-point mode.\n>\n> Well, IMHO \"git rebase\" and \"git rebase @{u}\" must do exactly the same\n> thing.\n\n\"That is not part of the current discussion\" is what I meant by \"It\nis debatable... We might want to\".  There is no such patch to \"git\nrebase\" itself in this topic ;-).\n\nWith the \"We might want to\", I mean \"git rebase\", \"git rebase @{u}\"\nand \"git rebase origin/master\" (if your @{u} happens to be that\nbranch) may want to do exactly the same thing.  The last one however\nis very questionable, as sometimes you would want the --fork-point\nheuristics, and some other times you would want no digging of the\nreflogs involved (i.e. \"I want everything not in this _exact_ commit\nto be rebased\").\n\n> On the other hand, I'm afraid different defaults were chosen for\n> backward compatibility?\n\nThere is no backward compatibility issue involved with the current\nbehaviour.  Changing it _will_ break compatibility, of course.\n\nIt is more like the command used not to guess with fork-point at\nall, i.e. we liked its exactness, but \"git rebase\" (no argument)\ncase is so obviously not about an exact commit but is about branch\nthat it is safe to use --fork-point guess without being confusing.\nOnce you start giving the commit/branch with respect to which you\nconduct your rebase, it no longer is so cut-and-dried obvious that\nby \"git rebase @{u}\" if the user wants us to guess by digging the\nreflog of @{u} to find a better fork point, or if the user wants to\ndo an exact rebase with respect to the commit at the tip of that\nbranch.\n"},{"id":"249987","messageId":"87k34mvj0u.fsf@osv.gnss.ru","threadId":"37598","inReplyTo":"xmqqvboa6lvj.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2014-09-29T10:05:37Z","receivedAt":"2014-09-29T10:05:37Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Sergey Organov <sorganov@gmail.com> writes:\n>\n>> I think you meant to say that we may find a better source to calculate\n>> the exact set of commits to rebase,...\n>\n> Yes.\n>\n>>> It is debatable if we should do the same when the user tells us to\n>>> rebase with respect to a specific _branch_ by giving the 'upstream'\n>>> argument, but that is an entirely separate issue.  We might want to\n>>> do a similar command line heuristics to tell between the branch\n>>> switching \"git checkout master\" (which is an operation about a\n>>> branch) and head detaching \"git checkout refs/heads/master^0\" (which\n>>> is an operation about a commit) if we want to help the users by\n>>> auto-enabling fork-point mode.\n>>\n>> Well, IMHO \"git rebase\" and \"git rebase @{u}\" must do exactly the same\n>> thing.\n>\n> \"That is not part of the current discussion\" is what I meant by \"It\n> is debatable... We might want to\".  There is no such patch to \"git\n> rebase\" itself in this topic ;-).\n\nYes, but to suggest better documentation I figure I need to understand\nall the related issues, so it is still somewhat relevant.\n\n> With the \"We might want to\", I mean \"git rebase\", \"git rebase @{u}\"\n> and \"git rebase origin/master\" (if your @{u} happens to be that\n> branch) may want to do exactly the same thing.  The last one however\n> is very questionable, as sometimes you would want the --fork-point\n> heuristics, and some other times you would want no digging of the\n> reflogs involved (i.e. \"I want everything not in this _exact_ commit\n> to be rebased\").\n>\n>> On the other hand, I'm afraid different defaults were chosen for\n>> backward compatibility?\n>\n> There is no backward compatibility issue involved with the current\n> behaviour.  Changing it _will_ break compatibility, of course.\n>\n> It is more like the command used not to guess with fork-point at\n> all, i.e. we liked its exactness, but \"git rebase\" (no argument)\n> case is so obviously not about an exact commit but is about branch\n> that it is safe to use --fork-point guess without being confusing.\n\nWell, that's exactly what ended-up being /extremely/ confusing in my\ncase.\n\n> Once you start giving the commit/branch with respect to which you\n> conduct your rebase, it no longer is so cut-and-dried obvious that\n> by \"git rebase @{u}\" if the user wants us to guess by digging the\n> reflog of @{u} to find a better fork point, or if the user wants to\n> do an exact rebase with respect to the commit at the tip of that\n> branch.\n\nWhatever excuses are, to me it still looks entirely unnatural that 'git\nrebase' and 'git rebase @{u}' mean almost the same /except/ the default\nvalue of --fork-point is different, sorry.\n\nP.S. I'll prepare improved patch for the documentation shortly.\n\n-- \nSegey.\n"},{"id":"249993","messageId":"xmqq7g0m75qk.fsf@gitster.dls.corp.google.com","threadId":"37598","inReplyTo":"87k34mn0ht.fsf@osv.gnss.ru","subject":"Re: [PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-29T16:26:27Z","receivedAt":"2014-09-29T16:26:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n> Vanilla \"git rebase\" defaults to --fork-point that in some cases\n> makes behavior very different from \"git rebase <upstream>\",\n> where --no-fork-point is assumed. This fact was not mentioned in\n> the DESCRIPTION section of the manual page, even though the case of\n> omitted <upstream> was otherwise discussed. That in turn made actual\n> behavior of vanilla \"git rebase\" hardly discoverable.\n>\n> While we are at it, clarify the --fork-point description itself as well.\n>\n> Signed-off-by: Sergey Organov <sorganov@gmail.com>\n> ---\n> As asked by Junio C Hamano <gitster@pobox.com>, the newly introduced\n> 'fork_point' term has been described.\n>\n\nI suspect \"will be used as a fallback\" might be easier to understand\nwhat is going on instead of \"will be used instead\", but other than\nthat, the new explanation of what fork-point is is a very welcome\nupdate, I think.\n\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 4138554..2e6f125 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -21,15 +21,17 @@ If <branch> is specified, 'git rebase' will perform an automatic\n>  it remains on the current branch.\n>  \n>  If <upstream> is not specified, the upstream configured in\n> +branch.<name>.remote and branch.<name>.merge options will be used (see\n> +linkgit:git-config[1] for details) and the `--fork-point` option is\n> +assumed.  If you are currently not on any branch or if the current\n> +branch does not have a configured upstream, the rebase will abort.\n>  \n>  All changes made by commits in the current branch but that are not\n>  in <upstream> are saved to a temporary area.  This is the same set\n> +of commits that would be shown by `git log <upstream>..HEAD`; or by\n> +`git log 'fork_point'..HEAD`, if --fork-point is either specified or\n> +assumed (see --fork-point description below); or by `git log HEAD`, if\n> +--root is specified.\n\nIt is easier to read with \"is either specified or assumed\" shortened\nto \"is active\", I think, because that is the word you use to explain\nhow the commit is computed for --fork-point processing.\n\n> @@ -327,13 +329,18 @@\n> link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To]\n> for details)\n>  \n>  --fork-point::\n>  --no-fork-point::\n> +\tUse reflog to find a better common ancestor between <upstream>\n> +\tand <branch> when calculating which commits have been\n> +\tintroduced by <branch>. \n>  +\n> +When --fork-point is active, 'fork_point' will be used instead of\n> +<upstream> to calculate the set of commits to rebase, where\n> +'fork_point' is the result of `git merge-base --fork-point <upstream>\n> +<branch>` command (see linkgit:git-merge-base[1]).  If 'fork_point'\n> +ends up being empty, the <upstream> will be used instead.\n> ++\n> +If either <upstream> or --root is given on the command line, then the\n> +default is `--no-fork-point`, otherwise the default is `--fork-point`.\n>  \n>  --ignore-whitespace::\n>  --whitespace=<option>::\n\n\nThe patch failed to apply\n\nApplying: Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.\nfatal: corrupt patch at line 38\n\nbut the fix-up is trivial, so no need to resend.\n\nThanks.\n"},{"id":"250004","messageId":"8738ba5ggj.fsf@osv.gnss.ru","threadId":"37598","inReplyTo":"xmqq7g0m75qk.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2014-09-29T20:17:48Z","receivedAt":"2014-09-29T20:17:48Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n> Sergey Organov <sorganov@gmail.com> writes:\n>\n\n[...]\n\n>> As asked by Junio C Hamano <gitster@pobox.com>, the newly introduced\n>> 'fork_point' term has been described.\n>>\n>\n> I suspect \"will be used as a fallback\" might be easier to understand\n> what is going on instead of \"will be used instead\", but other than\n> that, the new explanation of what fork-point is is a very welcome\n> update, I think.\n\nYeah, sure. Wasn't satisfied with the wording myself.\n\n[...]\n\n> The patch failed to apply\n\nSorry about it.\n\n> Applying: Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla \"git rebase\" in DESCRIPTION.\n> fatal: corrupt patch at line 38\n\nI rather get:\n\n$ git apply x.patch\nx.patch:38: trailing whitespace.\n\tintroduced by <branch>. \nwarning: 1 line adds whitespace errors.\n\nI've used 'git format-patch' to prepare the patch. Shouldn't it warn\nabout such things? Or what should I do to avoid such problems in the\nfuture? \n\n>\n> but the fix-up is trivial, so no need to resend.\n\nThanks.\n\n-- \nSergey.\n"}]}