sequential checkout commits (commit-wise review local branch)

[goyalyashpal]

Is your feature request related to a problem? Please describe.

when rewriting history as part of cleanup, i want to be able to checkout commits from older-to-newer to check if all commits are buildable.

currently in lazygit (v0.52.0), this requires following steps:

1. go to 4-commits tab
2. navigate to the commit say, with arrow keys.
3. <SPC> (space) to checkout the commit (detached-head)
4. ... outside the lazygit: do the build and confirm it's buildable / working etc.
5. a. go to 3-branches tab,
   b. highlight base branch (attached-head 😆),
   c.<SPC> checkout.
   d. when going to 4-commits tab, this step causes the cursor to start from the first commit.
6. repeat from step 1. for as many commits you want to verify

the proposal aims to ease the redundancy of steps 5a-d, 1, 2 in above flow.

Describe the solution you'd like

just like we are able to view commits one-by-one in lazygit commits tab, it would be nice to be able to checkout them one-by-one too.
this is what i meant by "sequential checkout" or "commit-wise review"

1. this mode is enabled in 4-commits tab by some trigger on the intended commit to be checked out.
   say <SPC> with some modifier to keep similarity with normal checkout.
2. a. in lazygit, all the newer commits are grayed out. this is very similar in theory to how the "Pending rebase todos" and "Commits" are separated while rebasing.
   b. should moving cursor to them be disabled too?
3. a. press <ESC> escape to exit this mode.
   b. this will checkout the base branch. step 5 and 1 solved from the problem
   c. but the cursor will stay on the same highlighted commit. efforts in step 2 minimized from the problem
4. navigate to some other commit, and repeat.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

i read that lazygit has review pr feature. maybe that provides a similar feature?

i have never been in position to review other people's pr locally, so, i have never seen this feature in action.

Additional context

$ lazygit --version  | sed -n -e 's/, /\n/g' -e 's/=/: /gp;'  | nu --stdin --commands 'from yaml'
╭──────────────┬────────╮
│ commit       │        │
│ build date   │        │
│ build source │ nix    │
│ version      │ 0.52.0 │
│ os           │ linux  │
│ arch         │ amd64  │
│ git version  │ 2.49.0 │
╰──────────────┴────────╯

[mark2185]

Would this work for you?

Option A:

• go to the [4] Commits tab
• find the oldest commit, i.e. the one you wish to start from
• start an interactive rebase by pressing e (it will mark the commit with the edit command)
• select all of the commits above with shift+arrow keys or v
• press e to mark them as edit
• run the build command outside of lazygit
• if all is fine, just continue the rebase with m and then c, and it will stop on the next commit marked with edit (which is the next one)

Option B:

• launch git rebase --exec "<build command goes here>" HEAD~5 (you can even do it through the : command window or as a custom command that takes the currently highlighted commit as the starting point)
• if it stops somewhere, lazygit will probably reflect the state without restarting it? worth a try

[stefanhaller]

Some discussion on why e is better than space for checking out commits: #4117 (comment)

Easier version of option A: press * to select all commits, e to mark them all as "edit" and checkout the first one.

[goyalyashpal]

Option A:

• go to the [4] Commits tab
• find the oldest commit, i.e. the one you wish to start from
• start an interactive rebase by pressing e (it will mark the commit with the edit command)
  ...

- @ mark2185 at #4767 (comment)

nice. incorporating the * (all commits) & summarising:

1. 4 commits > highlight oldest > e rebase
2. select: * all / v range / individual > e mark edit
3. ... external task > mc to continue
4. ma or ESC RET to exit

---

Sometimes I would ... [do Test Driven Development]

I don't press space to do that; I press e to "edit" the commit I want to check out.

...reasons-list

- @ stefanhaller #4117 (comment)

wow, the reasons list covers most of concerns already. hehe. nice to see.

---

Git's use of names is just odd: using "rebase edit" to "check out" a commit is better than using checkout? Git frontends are supposed to provide a better abstraction, but maybe only something like jj can properly fix it

- @ YikChingTsui at around #4117 (comment)

hehe. that's probably just the disadvantage of succeeding in first implementation with git probably.
you only see what works as things evolve. but then you can't change the things already in place.