{"thread":{"id":"56511","subject":"Possible git bug","startedAt":"2021-09-16T03:38:18Z","lastAt":"2021-09-20T16:07:24Z","messageCount":20,"participants":["Wesley Schwengle","Taylor Blau","wesley@schwengle.net","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"436063","messageId":"30651e4d-10fb-8bc7-7f52-8fbabf042f4a@schwengle.net","threadId":"56511","inReplyTo":null,"subject":"Possible git bug","fromName":"Wesley Schwengle","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T03:29:14Z","receivedAt":"2021-09-16T03:38:18Z","isPatch":false,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"\nHello,\n\nI'm running into a weird issue with git at the moment and I'm wondering \nif this is a bug. I have a small reproduction path:\n\n$ mkdir reproduction\n$ cd reproduction\n$ git init .\n$ echo \"commit a\" > file.txt\n$ git commit -m \"First commit\" file.txt\n$ echo \"commit b\" >> file.txt\n$ git commit -m \"Second commit\" file.txt\n\n$ git switch -c foo\n$ echo \"commit c\" >> file.txt\"\n$ git commit -m \"Third commit\" file.txt\n$ git branch --set-upstream-to=master\n\n$ git status\nOn branch foo\nYour branch is ahead of 'master' by 1 commit.\n\n$ git switch master\n$ git merge foo\n$ git reset --hard HEAD^\n$ git switch foo\nSwitched to branch 'foo'\nYour branch is ahead of 'master' by 1 commit.\n\n$ git log --format='%C(yellow)%h%Creset %Cgreen%s%Creset'\n5f427e3 Third commit\n03ad791 Second commit\n411e6d4 First commit\n\n$ git rebase master\n$ git status\nOn branch foo\nYour branch is up to date with 'master'.\n\n$ git log --format='%C(yellow)%h%Creset %Cgreen%s%Creset'\n03ad791 Second commit\n411e6d4 First commit\n\nI do not expect to lose the commits from foo, it seems the ref of master \ndoesn't get updated after a reset.\n\nI didn't lose any work because I pushed my work to a remote and can \nstill get it from there (and git reflog would also reach my code). It is \nrather surprising to see this kind of behavior.\n\nI'm running:\n$ git --version\ngit version 2.33.0.363.g4c719308ce\n\nBut I also got this behavior with the git shipped with Debian:\n$ /usr/bin/git --version\ngit version 2.32.0\n\nCheers,\nWesley\n\n-- \nWesley Schwengle\nE: wesley@schwengle.net\n"},{"id":"436077","messageId":"YULYG970Ltnbshdn@nand.local","threadId":"56511","inReplyTo":"30651e4d-10fb-8bc7-7f52-8fbabf042f4a@schwengle.net","subject":"Re: Possible git bug","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-09-16T05:37:31Z","receivedAt":"2021-09-16T05:37:35Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Sep 15, 2021 at 11:29:14PM -0400, Wesley Schwengle wrote:\n>\n> Hello,\n>\n> I'm running into a weird issue with git at the moment and I'm wondering if\n> this is a bug. I have a small reproduction path:\n\n> $ git commit -m \"First commit\" file.txt\n\nFWIW, I had to tweak this script a little, since file.txt is untracked\nbefore it is added initially. (So a \"git add file.txt\" before this first\ncommit is required.)\n\nBut even after this, I got exactly what I expected from this script\n(which was that your \"foo\" branch had three commits before and after).\nIs there something else interesting going on with your setup that might\nexplain why I can't reproduce this?\n\nThanks,\nTaylor\n"},{"id":"436115","messageId":"c7949156-a7e5-085f-4779-82d0538a4d72@schwengle.net","threadId":"56511","inReplyTo":"YULYG970Ltnbshdn@nand.local","subject":"Re: Possible git bug","fromName":"Wesley Schwengle","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T12:07:33Z","receivedAt":"2021-09-16T12:07:42Z","isPatch":false,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"On 9/16/21 1:37 AM, Taylor Blau wrote:\n\n> FWIW, I had to tweak this script a little, since file.txt is untracked\n> before it is added initially. (So a \"git add file.txt\" before this first\n> commit is required.)\n\nOh sorry! I overlooked that part.\n\n> But even after this, I got exactly what I expected from this script\n> (which was that your \"foo\" branch had three commits before and after).\n> Is there something else interesting going on with your setup that might\n> explain why I can't reproduce this?\n\nOh, I found it.. Replace `git rebase master' with `git rebase' in the \nreproduction path.\n\nDisregard my post, it seems this is documented behavior in the rebase \nman-page. When you have an upstream configured and you don't specify it \non the command line, --fork-point is used, while if you specify the \nupstream --no-fork-point is used. `git rebase master --fork-point' \nexhibits the same as I was seeing. Although I'm now completely confused \nby this behavior. It doesn't make sense to me.\n\nThis happens:\n\nWe are on a branch, we merge it into another branch.\nWe undo the merge because reasons.\nNow we git rebase, without the upstream, because we've set it.\nFork-point is used now, because we haven't specified an upstream, but we \ndid set it and git merge-base decides, oh, we had those commits in \nmaster but these where dropped so we drop them in this branch as well.\n\nNew question, is there a way to tell rebase to NOT use fork-point via \ngit-config in this situation?\n\nCheers,\nWesley\n\n-- \nWesley Schwengle\nE: wesley@schwengle.net\n"},{"id":"436118","messageId":"20210916124709.2824551-1-wesley@schwengle.net","threadId":"56511","inReplyTo":"c7949156-a7e5-085f-4779-82d0538a4d72@schwengle.net","subject":"Re: Possible git bug","fromName":"","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T12:47:08Z","receivedAt":"2021-09-16T12:47:37Z","isPatch":false,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"\nOn 9/16/21 8:07 AM, Wesley Schwengle wrote:\n \n> New question, is there a way to tell rebase to NOT use fork-point via \n> git-config in this situation?\n\nI seem to have found the answer in the source code: rebase.forkpoint exists.\n\nWould you accept the following patch that adds the following text to the\ndocumentation?\n\nCheers,\nWesley\n\n"},{"id":"436119","messageId":"20210916124709.2824551-2-wesley@schwengle.net","threadId":"56511","inReplyTo":"20210916124709.2824551-1-wesley@schwengle.net","subject":"[PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T12:47:09Z","receivedAt":"2021-09-16T12:47:38Z","isPatch":true,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"From: Wesley Schwengle \n\nThe option exists and the rebase behaviour tricked me into thinking\nthere was a bug with git. This will tell people how they can tweak the\ndefault behavior.\n\nSigned-off-by: Wesley Schwengle \n---\n Documentation/git-rebase.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 506345cb0e..8d2bee3365 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -446,7 +446,8 @@ When --fork-point is active, 'fork_point' will be used instead of\n ends up being empty, the will be used as a fallback.\n +\n If is given on the command line, then the default is\n-`--no-fork-point`, otherwise the default is `--fork-point`.\n+`--no-fork-point`, otherwise the default is `--fork-point`. You can override\n+this default by setting the configuration option `rebase.forkpoint` to false.\n +\n If your branch was based on but was rewound and\n your branch contains commits which were dropped, this option can be used\n-- \n2.33.0.364.gff7047fb76\n\n"},{"id":"436125","messageId":"xmqqzgsctu10.fsf@gitster.g","threadId":"56511","inReplyTo":"20210916124709.2824551-1-wesley@schwengle.net","subject":"Re: Possible git bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-16T15:33:15Z","receivedAt":"2021-09-16T15:33:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"wesley@schwengle.net writes:\n\n> On 9/16/21 8:07 AM, Wesley Schwengle wrote:\n> \n>> New question, is there a way to tell rebase to NOT use fork-point via \n>> git-config in this situation?\n>\n> I seem to have found the answer in the source code: rebase.forkpoint exists.\n>\n> Would you accept the following patch that adds the following text to the\n> documentation?\n\nNot so fast.\n\nEarlier you said:\n\n> ... When you have an upstream configured and you don't specify\n> it on the command line, --fork-point is used, while if you specify the \n> upstream --no-fork-point is used. `git rebase master --fork-point'\n> exhibits the same as I was seeing. Although I'm now completely\n> confused by this behavior. It doesn't make sense to me.\n>\n> This happens:\n>\n> We are on a branch, we merge it into another branch.\n> We undo the merge because reasons.\n> Now we git rebase, without the upstream, because we've set it.\n> Fork-point is used now, because we haven't specified an upstream, but\n> we did set it and git merge-base decides, oh, we had those commits in \n> master but these where dropped so we drop them in this branch as well.\n\nIf you feel \"It doesn't make sense to me\", either\n\n - the behaviour does not make sense because it is simply buggy, in\n which case, adding a sentence to the documentation and explaining\n how not to use it is missing the point---don't you rather want it\n to behave in a way that makes sense to you instead?\n\nor\n\n - it appears as nonsense to you only because your understanding of\n the behaviour is faulty but the feature is working correctly and\n is not a bug, in which case, adding a sentence to the\n documentation and explaining how not to use it is missing the\n point---don't you rather want the existing documentation extended\n to help you and other users to understand the behaviour better\n first?\n\nBetween \"buggy behaviour\" and \"bad documentation of a well-designed\nbehaviour\", I offhand do not know which side \"--fork-point\" is for\nthis particular case, but I've always felt that it is a bad\nheuristic that should be used with care, and my gut feeling is it\nmight be the third possibility: \"bad heuristic that sometimes\nmisbehave badly and that is unfixable\". If that is the case,\nperhaps the documentation should tell readers the unreliable nature\nof the option and warn them to double check the result before\nteaching them how to turn it off permanently.\n\nThanks.\n\n\n"},{"id":"436127","messageId":"xmqqv930ttkr.fsf@gitster.g","threadId":"56511","inReplyTo":"20210916124709.2824551-2-wesley@schwengle.net","subject":"Re: [PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-16T15:43:00Z","receivedAt":"2021-09-16T15:43:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"wesley@schwengle.net writes:\n\n> From: Wesley Schwengle \n>\n> The option exists and the rebase behaviour tricked me into thinking\n> there was a bug with git. This will tell people how they can tweak the\n> default behavior.\n\nThis tells readers about almost nothing but your frustration.\n\nWe, or anybody who will be reading \"git log\" in 6 months to improve\nthe system, will not need to hear it. Instead we need to understand\nwhat the real problem is, what was wrong in the behaviour, or what\nthe expected behaviour was and why the use of the feature was\ninappropriate in the particular case, without which it is impossible\nto understand why this sentence was added when a future developer\nand documenter tries to improve upon this text.\n\n> Signed-off-by: Wesley Schwengle \n> ---\n> Documentation/git-rebase.txt | 3 ++-\n> 1 file changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 506345cb0e..8d2bee3365 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -446,7 +446,8 @@ When --fork-point is active, 'fork_point' will be used instead of\n> ends up being empty, the will be used as a fallback.\n> +\n> If is given on the command line, then the default is\n> -`--no-fork-point`, otherwise the default is `--fork-point`.\n> +`--no-fork-point`, otherwise the default is `--fork-point`. You can override\n> +this default by setting the configuration option `rebase.forkpoint` to false.\n\nWe often do:\n\n \"See also `rebase.forkpoint` in linkgit:git-config[1].\"\n\n(for example, there is a reference to linkgit:githooks[5] in the\nsame page).\n\nThanks.\n\n\n"},{"id":"436147","messageId":"3b4270f9-6139-7007-301b-8a084f4336cf@schwengle.net","threadId":"56511","inReplyTo":"xmqqzgsctu10.fsf@gitster.g","subject":"Re: Possible git bug","fromName":"Wesley Schwengle","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T19:39:04Z","receivedAt":"2021-09-16T19:39:20Z","isPatch":false,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"On 9/16/21 11:33 AM, Junio C Hamano wrote:\n\n>> We are on a branch, we merge it into another branch.\n>> We undo the merge because reasons.\n>> Now we git rebase, without the upstream, because we've set it.\n>> Fork-point is used now, because we haven't specified an upstream, but\n>> we did set it and git merge-base decides, oh, we had those commits in\n>> master but these where dropped so we drop them in this branch as well.\n> \n> If you feel \"It doesn't make sense to me\", either\n> \n> - the behaviour does not make sense because it is simply buggy, in\n> which case, adding a sentence to the documentation and explaining\n> how not to use it is missing the point---don't you rather want it\n> to behave in a way that makes sense to you instead?\n> \n> or\n> \n> - it appears as nonsense to you only because your understanding of\n> the behaviour is faulty but the feature is working correctly and\n> is not a bug, in which case, adding a sentence to the\n> documentation and explaining how not to use it is missing the\n> point---don't you rather want the existing documentation extended\n> to help you and other users to understand the behaviour better\n> first?\n> \n> Between \"buggy behaviour\" and \"bad documentation of a well-designed\n> behaviour\", I offhand do not know which side \"--fork-point\" is for\n> this particular case, but I've always felt that it is a bad\n> heuristic that should be used with care, and my gut feeling is it\n> might be the third possibility: \"bad heuristic that sometimes\n> misbehave badly and that is unfixable\". If that is the case,\n> perhaps the documentation should tell readers the unreliable nature\n> of the option and warn them to double check the result before\n> teaching them how to turn it off permanently.\n\nI feel like it is a bad default, it caught me by surprise. Especially \nbecause in the reproduction path I wanted to explicit in my rebase \naction and this caused different behavior. After this was pointed out I \nread the man page because I thought `git rebase' and `git rebase master' \nwas the same thing if that was configured as an upstream. It took me a \nwhile to figure this out, because I kept typing `git rebase' instead of \n`git rebase master' when quickly trying to find out why it wasn't \nbehaving like it did earlier.\n\nI'm clueless about \"buggy behavior\", \"bad documentation of a well \ndesigned feature\" or \"bad heuristic that sometimes misbehave badly and \nthat is unfixable\". To me `git rebase' with a configured upstream should \nbehave the same as `git rebase @{u}'. Only when adding --fork-point it \nshould behave as it does currently. I'm not sure when I would want to \nuse it, but I'm thinking people want it, otherwise it wouldn't be a default.\n\nAs for the patch. The reason why --fork-point is default I do not know, \nbut how to disable it isn't documented and I think it should. It is \nhidden in the source code and the release notes of 2.31.0. It should be \nmore visible. Which is the reason I submitted the patch.\n\nCheers,\nWesley\n\n-- \nWesley Schwengle\nE: wesley@schwengle.net\n"},{"id":"436164","messageId":"xmqqtuikrzca.fsf@gitster.g","threadId":"56511","inReplyTo":"xmqqv930ttkr.fsf@gitster.g","subject":"Re: [PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-16T21:21:25Z","receivedAt":"2021-09-16T21:21:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> wesley@schwengle.net writes:\n>\n>> From: Wesley Schwengle \n>>\n>> The option exists and the rebase behaviour tricked me into thinking\n>> there was a bug with git. This will tell people how they can tweak the\n>> default behavior.\n>\n> This tells readers about almost nothing but your frustration.\n>\n> We, or anybody who will be reading \"git log\" in 6 months to improve\n> the system, will not need to hear it. Instead we need to understand\n>\n> what the real problem is, what was wrong in the behaviour, or what\n> the expected behaviour was and why the use of the feature was\n> inappropriate in the particular case, without which it is impossible\n> to understand why this sentence was added when a future developer\n> and documenter tries to improve upon this text.\n\nI misspke a bit here. While hearing only your frustration and\nnothing else won't help us much, we do need to understand what\ncaused your frustration, to avoid frustrating the next user the same\nway. All of the \"Instead we need to understand ...\" are about that.\n\n> We often do:\n>\n> \"See also `rebase.forkpoint` in linkgit:git-config[1].\"\n>\n> (for example, there is a reference to linkgit:githooks[5] in the\n> same page).\n\nOne reason why you didn't find how to tweak the forkpoint feature,\nother than giving a command line option to countermand it, is\nbecause this link pointing at the list of configurations, where the\nvariable is already described, was missing in the doucmentation for\nthe \"rebase\" command.\n\nThanks.\n"},{"id":"436170","messageId":"xmqqmtocrxwq.fsf@gitster.g","threadId":"56511","inReplyTo":"3b4270f9-6139-7007-301b-8a084f4336cf@schwengle.net","subject":"Re: Possible git bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-16T21:52:21Z","receivedAt":"2021-09-16T21:52:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wesley Schwengle writes:\n\n> I feel like it is a bad default, it caught me by surprise.\n\nI tend to agree. It seems that d44e7126 (pull: support rebased\nupstream + fetch + pull --rebase, 2009-07-19) started it, probably\nby mistake, which was partially corrected by ad8261d2 (rebase: use\nreflog to find common base with upstream, 2013-12-09).\n\nThe thread that contains\n\n https://lore.kernel.org/git/xmqq7gbdzsvt.fsf@gitster.dls.corp.google.com/\n\nseems to have resulted in the design of the current behaviour, where \nthe discussion refers to an even older discussion thread:\n\nhttps://lore.kernel.org/git/d8e9f102609ee4502f579cb4ce872e0a40756204.1381949622.git.john@keeping.me.uk/\n\n\tSide note: I am kind-of surprised that I contributed the\n\tcore computation of the fork-point logic, even though I\n\twasn't buying it is a good feature back then.\n\nIn any case, updating the documentation to refer to the configuraion\nvariable that tweaks the default for --fork-point would be a good\nnear-term thing to do, but in the longer term, I think it may make\nsense to fix this \"surprise\" and transition the default over time,\ni.e.\n\n (1) when \"git rebase\" is run without --[no-]fork-point from the\n command line, and without rebase.forkpoint configuration\n variable in effect, give a warning that says we'll change the\n default to 'false' and the users who want to can use the\n configuration variable to force it to 'true'. Update the\n documentation to say the special casing of \"If is\n not specified, --fork-point option is assumed\" will be changed\n in the future.\n\n Ship such a version of Git and wait for several development\n cycles.\n\n\n (2) flip the default and remove the warning. Update the\n documentation.\n\n> As for the patch. The reason why --fork-point is default I do not\n> know, but how to disable it isn't documented and I think it should. It\n> is hidden in the source code and the release notes of 2.31.0. It\n> should be more visible. Which is the reason I submitted the patch.\n\nCertainly.\n\n\"git config --help\" is the only end-user facing place the reference\nfrom the configuration variable to the command line option is found.\nWe should also have a backreference from the command line option to\nthe configuration variable.\n\n\n"},{"id":"436177","messageId":"4d17d26a-d945-3875-beed-e23ae6281f54@schwengle.net","threadId":"56511","inReplyTo":"xmqqmtocrxwq.fsf@gitster.g","subject":"Re: Possible git bug","fromName":"Wesley Schwengle","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T22:30:46Z","receivedAt":"2021-09-16T22:31:02Z","isPatch":false,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"On 9/16/21 5:52 PM, Junio C Hamano wrote:\n> Wesley Schwengle writes:\n\n>> As for the patch. The reason why --fork-point is default I do not\n>> know, but how to disable it isn't documented and I think it should. It\n>> is hidden in the source code and the release notes of 2.31.0. It\n>> should be more visible. Which is the reason I submitted the patch.\n> \n> Certainly.\n> \n > In any case, updating the documentation to refer to the configuraion\n > variable that tweaks the default for --fork-point would be a good\n > near-term thing to do, but in the longer term, I think it may make\n > sense to fix this \"surprise\" and transition the default over time,\n > i.e.\n >\n > \"git config --help\" is the only end-user facing place the reference\n > from the configuration variable to the command line option is found.\n > We should also have a backreference from the command line option to\n > the configuration variable.\n\nA simple reference in the documentation would be a good first step and \nthe change of the default can than happen over multiple iterations/versions.\n\nCheers,\nWesley\n\n-- \nWesley Schwengle\nE: wesley@schwengle.net\n"},{"id":"436178","messageId":"20210916223528.2910292-1-wesley@schwengle.net","threadId":"56511","inReplyTo":"xmqqtuikrzca.fsf@gitster.g","subject":"Re: Possible git bug","fromName":"","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T22:35:27Z","receivedAt":"2021-09-16T22:35:55Z","isPatch":false,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"\nI've updated the patch and the commit message. I hope this is sufficient\nto be included.\n\nCheers,\nWesley\n\n"},{"id":"436179","messageId":"20210916223528.2910292-2-wesley@schwengle.net","threadId":"56511","inReplyTo":"20210916223528.2910292-1-wesley@schwengle.net","subject":"[PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T22:35:28Z","receivedAt":"2021-09-16T22:35:57Z","isPatch":true,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"From: Wesley Schwengle \n\nThe option exists and the rebase behaviour tricked me into thinking\nthere was a bug with git. This will tell people how they can tweak the\ndefault behavior.\n\nSigned-off-by: Wesley Schwengle \n---\n Documentation/git-rebase.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 506345cb0e..8d2bee3365 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -446,7 +446,8 @@ When --fork-point is active, 'fork_point' will be used instead of\n ends up being empty, the will be used as a fallback.\n +\n If is given on the command line, then the default is\n-`--no-fork-point`, otherwise the default is `--fork-point`.\n+`--no-fork-point`, otherwise the default is `--fork-point`. You can override\n+this default by setting the configuration option `rebase.forkpoint` to false.\n +\n If your branch was based on but was rewound and\n your branch contains commits which were dropped, this option can be used\n-- \n2.33.0.364.gff7047fb76\n\n"},{"id":"436185","messageId":"20210916224603.2912887-1-wesley@schwengle.net","threadId":"56511","inReplyTo":"xmqqtuikrzca.fsf@gitster.g","subject":"Re: Possible git bug","fromName":"","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T22:46:02Z","receivedAt":"2021-09-16T22:46:19Z","isPatch":false,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"\nI failed to include the correct format-patch, 3rd time is a charm :)\n\nCheers,\nWesley\n\n"},{"id":"436186","messageId":"20210916224603.2912887-2-wesley@schwengle.net","threadId":"56511","inReplyTo":"20210916224603.2912887-1-wesley@schwengle.net","subject":"[PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-16T22:46:03Z","receivedAt":"2021-09-16T22:46:20Z","isPatch":true,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"From: Wesley Schwengle \n\nThe configuration option `rebase.forkpoint' is only mentioned in the man\npage of git-config(1). Since it is a configuration for rebase, mention\nit in the documentation of rebase at the --fork-point/--no-fork-point\nsection. This will help users set a preferred default for their\nworkflow.\n\nSigned-off-by: Wesley Schwengle \n---\n Documentation/git-rebase.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 506345cb0e..c116dbf4bb 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -446,7 +446,8 @@ When --fork-point is active, 'fork_point' will be used instead of\n ends up being empty, the will be used as a fallback.\n +\n If is given on the command line, then the default is\n-`--no-fork-point`, otherwise the default is `--fork-point`.\n+`--no-fork-point`, otherwise the default is `--fork-point`. See also\n+`rebase.forkpoint` in linkgit:git-config[1].\n +\n If your branch was based on but was rewound and\n your branch contains commits which were dropped, this option can be used\n-- \n2.33.0.364.gff7047fb76\n\n"},{"id":"436187","messageId":"xmqq4kakrvdc.fsf@gitster.g","threadId":"56511","inReplyTo":"20210916223528.2910292-2-wesley@schwengle.net","subject":"Re: [PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-16T22:47:11Z","receivedAt":"2021-09-16T22:47:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"wesley@schwengle.net writes:\n\n> From: Wesley Schwengle \n>\n> The option exists and the rebase behaviour tricked me into thinking\n> there was a bug with git. This will tell people how they can tweak the\n> default behavior.\n\nSo this still does not explain what rebase behaviour tricked you\ninto thinking so. That leaves the readers of \"git log\" frustrated,\nmuch more than a log message based only on a simple statement of\nfact, e.g.\n\n \"git config --help\" describes rebase.forkpoint as a way to give\n the default value for --[no-]forkpoint option, but \"git rebase\n --help\" does not mention it. \n\n Help people who visits the documentation of \"rebase\" to find the\n variable.\n\nor something like that.\n\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 506345cb0e..8d2bee3365 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -446,7 +446,8 @@ When --fork-point is active, 'fork_point' will be used instead of\n> ends up being empty, the will be used as a fallback.\n> +\n> If is given on the command line, then the default is\n> -`--no-fork-point`, otherwise the default is `--fork-point`.\n> +`--no-fork-point`, otherwise the default is `--fork-point`. You can override\n> +this default by setting the configuration option `rebase.forkpoint` to false.\n\nIt is not wrong per-se, but sounds overly verbose and seems to give\nonly half an advice. You can also set it to 'true' to override the\ndefault --no-fork-point given when you give on the\ncommand line, no? So perhaps only a single line addition (plus\ndowncasing \"If\" to \"if\"), i.e.\n\n+ If `rebase.forkpoint` is set, that gives the default. Otherwise,\n if wesley@schwengle.net writes:\n> \n>> From: Wesley Schwengle \n>>\n>> The option exists and the rebase behaviour tricked me into thinking\n>> there was a bug with git. This will tell people how they can tweak the\n>> default behavior.\n> \n> So this still does not explain what rebase behaviour tricked you\n> into thinking so. That leaves the readers of \"git log\" frustrated,\n> much more than a log message based only on a simple statement of\n> fact, e.g.\n> \n> \"git config --help\" describes rebase.forkpoint as a way to give\n> the default value for --[no-]forkpoint option, but \"git rebase\n> --help\" does not mention it.\n> \n> Help people who visits the documentation of \"rebase\" to find the\n> variable.\n> \n> or something like that.\n\nI made a booboo. I did not run format-patch with the updated commit \nmessage and commit. I saw it too late. You should have a new one by the \ntime you read this :)\n\nCheers,\nWesley\n\n\n-- \nWesley Schwengle\nE: wesley@schwengle.net\n"},{"id":"436192","messageId":"xmqqv930qgi6.fsf@gitster.g","threadId":"56511","inReplyTo":"287f826e-8fde-2c9a-ba66-a0a96e488b9c@schwengle.net","subject":"Re: [PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-16T22:53:37Z","receivedAt":"2021-09-16T22:53:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wesley Schwengle writes:\n\n> I made a booboo. I did not run format-patch with the updated commit\n> message and commit. I saw it too late. You should have a new one by\n\nThat is OK. Mistakes happen.\n\nI'll slow down to avoid further confusion from mails crossing, but I\nhave a feeling that you either forgot to read, or sent an updated\npatch before reading, the latter half of the message you are\nresponding to.\n\nThanks.\n"},{"id":"436417","messageId":"d1a1953b-5c1c-c18e-3e58-5b13f50b8980@schwengle.net","threadId":"56511","inReplyTo":"xmqqv930qgi6.fsf@gitster.g","subject":"Re: [PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"Wesley Schwengle","fromEmail":"wesley@schwengle.net","sentAt":"2021-09-20T14:34:29Z","receivedAt":"2021-09-20T14:34:43Z","isPatch":true,"sender":{"key":"wesley@schwengle.net","avatar":null},"body":"\n\nOn 9/16/21 6:53 PM, Junio C Hamano wrote:\n> Wesley Schwengle writes:\n> \n>> I made a booboo. I did not run format-patch with the updated commit\n>> message and commit. I saw it too late. You should have a new one by\n> \n> That is OK. Mistakes happen.\n> \n> I'll slow down to avoid further confusion from mails crossing, but I\n> have a feeling that you either forgot to read, or sent an updated\n> patch before reading, the latter half of the message you are\n> responding to.\n\nI did the same thing, the patch is present in the thread at \nhttps://public-inbox.org/git/20210916224603.2912887-1-wesley@schwengle.net/\n\nCheers,\nWesley\n\n-- \nWesley Schwengle\nE: wesley@schwengle.net\n"},{"id":"436436","messageId":"xmqqv92vcjt5.fsf@gitster.g","threadId":"56511","inReplyTo":"20210916224603.2912887-2-wesley@schwengle.net","subject":"Re: [PATCH] Document `rebase.forkpoint` in rebase man page","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-20T16:07:18Z","receivedAt":"2021-09-20T16:07:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"wesley@schwengle.net writes:\n\n> From: Wesley Schwengle \n>\n> The configuration option `rebase.forkpoint' is only mentioned in the man\n> page of git-config(1). Since it is a configuration for rebase, mention\n> it in the documentation of rebase at the --fork-point/--no-fork-point\n> section. This will help users set a preferred default for their\n> workflow.\n>\n> Signed-off-by: Wesley Schwengle \n> ---\n> Documentation/git-rebase.txt | 3 ++-\n> 1 file changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 506345cb0e..c116dbf4bb 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -446,7 +446,8 @@ When --fork-point is active, 'fork_point' will be used instead of\n> ends up being empty, the will be used as a fallback.\n> +\n> If is given on the command line, then the default is\n> -`--no-fork-point`, otherwise the default is `--fork-point`.\n> +`--no-fork-point`, otherwise the default is `--fork-point`. See also\n> +`rebase.forkpoint` in linkgit:git-config[1].\n> +\n> If your branch was based on but was rewound and\n> your branch contains commits which were dropped, this option can be used\n\nI still think \"the variable gives the default, otherwise the\npresence of on the command line affects which one is used\nas the default\" presentation order is better, but the above is a\nstrict improvement over the current message, so let's take it.\n\nThanks.\n"}]}