git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/2] rebase: find --fork-point with full ref

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Dec 6, 2019, 10:52 UTC
Message-ID
<e898ad43-5649-8f4c-7c93-fab09197fc92@gmail.com>
In-Reply-To
<20191206014828.GB16183@generichostname>
Hi Alex
Thanks for working on this
On 06/12/2019 01:48, Denton Liu wrote:
Show 23 quoted lines
> Hi Alex,
> 
> On Thu, Dec 05, 2019 at 06:57:04PM -0500, Alex Torok wrote:
>> rebase --fork-point needs to look up the full ref name before calling
>> get_fork_point in the same manner that merge-base --fork-point does.
>>
>> Signed-off-by: Alex Torok <alext9@gmail.com>
>> ---
>>   builtin/rebase.c             | 4 +++-
>>   t/t3431-rebase-fork-point.sh | 1 +
>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/builtin/rebase.c b/builtin/rebase.c
>> index e755087b0f..821994f676 100644
>> --- a/builtin/rebase.c
>> +++ b/builtin/rebase.c
>> @@ -1980,8 +1980,10 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
>>   		struct commit *head =
>>   			lookup_commit_reference(the_repository,
>>   						&options.orig_head);
>> +		char * full_name;
> 
> nit: * should be attached to the variable name.

I think you also need to free it once you've called get_fork_point() as well.

Show 7 quoted lines
> 
>> +		dwim_ref_or_die(options.upstream_name, strlen(options.upstream_name), &full_name);
> 
> Also, thinking about this more, would it be possible to put the dwim_ref
> logic into get_fork_point() directly? There are currently only these two
> callers so I suspect it should be fine and it'll result in cleaner
> logic.

If you do that then it would be better to use error() rather than die() in get_fork_point() and return an error to the caller as we try to avoid adding code to libgit that dies. This lets the caller handle any cleanup that they need to before exiting.

Best Wishes
Phillip
Show 47 quoted lines
> 
> We could also squash it down into one patch.
> 
>>   		options.restrict_revision =
>> -			get_fork_point(options.upstream_name, head);
>> +			get_fork_point(full_name, head);
>>   	}
>>   
>>   	if (repo_read_index(the_repository) < 0)
>> diff --git a/t/t3431-rebase-fork-point.sh b/t/t3431-rebase-fork-point.sh
>> index 78851b9a2a..6ecdae918e 100755
>> --- a/t/t3431-rebase-fork-point.sh
>> +++ b/t/t3431-rebase-fork-point.sh
>> @@ -49,6 +49,7 @@ test_rebase 'G F C D B A' --no-fork-point --onto D
>>   test_rebase 'G F C B A' --no-fork-point --keep-base
>>   test_rebase 'G F E D B A' --fork-point refs/heads/master
>>   test_rebase 'G F D B A' --fork-point --onto D refs/heads/master
>> +test_rebase 'G F D B A' --fork-point --onto D master
> 
> It's not obvious why this was failing in the first place. Perhaps we
> could document it better in the commit message?
> 
> Maybe something like:
> 
> 	We used to pass in the upstream_name directly into the
> 	get_fork_point() machinery. However, get_fork_point() was
> 	expecting a fully qualified ref name even though most users use
> 	the short name for branches. This resulted in `--fork-point` not
> 	working as expected since, without the full ref name, the reflog
> 	lookup would fail and it would behave as if we weren't passing
> 	in `--fork-point` at all.
> 
> Also, I'm not why this test case in particular that was duplicated (and
> not the one above) given that the first three `--fork-point` test cases
> fail without the change to rebase. Perhaps we want to duplicate all
> "refs/heads/master" tests with a corresponding "master" test?
> 
> Thanks,
> 
> Denton
> 
>>   test_rebase 'G F B A' --fork-point --keep-base refs/heads/master
>>   test_rebase 'G F C E D B A' refs/heads/master
>>   test_rebase 'G F C D B A' --onto D refs/heads/master
>> -- 
>> 2.17.1
>>
Previous: Denton LiuNext: Alex Torok
Message 13 of 23 in “rebase: fix bug in --fork-point”
  1. 0/3 rebase: fix bug in --fork-pointAlex Torok, Dec 5, 2019
  2. 1/3 rebase: add test for rebase --fork-point with short upstreamAlex Torok, Dec 5, 2019
  3. Junio C HamanoDec 5, 2019
  4. Alex TorokDec 5, 2019
  5. 2/3 rebase: refactor dwim_ref_or_die from merge-base.cAlex Torok, Dec 5, 2019
  6. 3/3 rebase: fix rebase to use full ref to find fork-pointAlex Torok, Dec 5, 2019
  7. 0/2 rebase: fix bug in --fork-pointAlex Torok, Dec 5, 2019
  8. 1/2 rebase: refactor dwim_ref_or_die from merge-base.cAlex Torok, Dec 5, 2019
  9. Denton LiuDec 6, 2019
  10. Alex TorokDec 6, 2019
  11. 2/2 rebase: find --fork-point with full refAlex Torok, Dec 5, 2019
  12. Denton LiuDec 6, 2019
  13. Phillip WoodDec 6, 2019
  14. Alex TorokDec 6, 2019
  15. Denton LiuDec 6, 2019
  16. Phillip WoodDec 6, 2019
  17. 0/1 rebase: fix --fork-point with short ref upstreamAlex Torok, Dec 9, 2019
  18. 1/1 rebase: fix --fork-point with short refnameAlex Torok, Dec 9, 2019
  19. Junio C HamanoDec 9, 2019
  20. Alex TorokDec 11, 2019
  21. Denton LiuDec 11, 2019
  22. Eric SunshineDec 11, 2019
  23. Junio C HamanoFeb 11, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.