From: Stefan Sperling Subject: Re: Lost among the branches To: Christian Weisgerber Cc: gameoftrees@openbsd.org Date: Tue, 16 May 2023 17:18:26 +0200 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 > 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 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.