On Mon, May 15, 2023 at 05:37:27PM +0200, Christian Weisgerber wrote:
> I have found a new toy to probe the limits of GoT:
> https://github.com/mozilla/gecko-dev
> 
> I would like to update my worktree to a commit found somewhere in
> the convoluted (merge, merge) history of the current branch:
> 
>   $ cd gecko-dev
>   $ got br
>   release
>   $ got log -b -S FIREFOX_112_0_RELEASE
>   -----------------------------------------------
>   commit 51aeebd8221e07415c275453ebe88cce39e151ce
>   from: Mozilla Releng Treescript <release+treescript@mozilla.org>
>   date: Tue Apr 11 12:40:50 2023 UTC
>    
>    No bug - Tagging d2b2ff2c6e3ceb267e77b0163c860f7a1f13ff4a with FIREFOX_112_0_RELEASE a=release CLOSED TREE DONTBUILD
>    
>   $ got up -c 51aeebd8221e07415c275453ebe88cce39e151ce
>   got: work tree's head reference now points to a different branch; new head reference and/or update -b required
> 
> Aaand I'm lost.  What now?  The commit is in the branch's history,
> so why can't I go there?  update -b <what>??

What the error is saying is that this commit is not in the linear
(first-parent) history of the 'release' commit, which is correct.

This check is meant to prevent updates from F to D in the following case:

	 * (commit) D       F (base_commit)
	 *           \     /
	 *            C   E
	 *             \ /
	 *              B (yca)
	 *              |
	 *              A

This check, as implemented, is wrong for the case you presented, where
you are interested in some commit X, assuming A is a merge commit:

	 * (commit) D       F (base_commit)
	 *           \     /
	 *            C   E
	 *             \ /
	 *              B (yca)
	 *              |
	 *              A
	 *             / \
	 *            Y   X
	
At present 'got update' will only allow you to move the work tree from F to Y.
I agree that up^Wbackdating to X from F should work. Provided we will still
be blocking attempts to update from F to D, of course.