Hi Phillip, On 05/05/2020 20:42, Phillip Wood wrote: > Hi Mikko > > On 04/05/2020 09:26, Mikko Rantalainen wrote: >> While doing long rebases (I'm currently rebasing a feature branch with >> 166 patches) and rebase stopping in the middle of rebase, locating the >> old patch in gitk is sometimes hard. >> >> Could gitk automatically mark the original patch that failed to rebase >> after I press F5? >> >> The failing original commit SHA-1 can be found in file >> .git/rebase-merge/stopped-sha but as far as I know, git does have >> logical commit name similar to HEAD, ORIG_HEAD or anything else for this >> case so there's no easy way to get already running gitk to mark this >> patch. > > Since git v2.17 rebase which should set REBASE_HEAD to point to the > failing commit. Is that a proper Pseudo Ref or is it just a temporary feature during a rebase? I see it's only mentioned once in the Documentation in the Rebase man page. (I see a lot of discussion on the reftable support, with the pseudo refs being at least one sticking point.) Philip > > Best Wishes > > Phillip > >> Of course, doing the same thing for failed cherry-picks would be nice, >> too but in that case it's pretty clear where the source patch is. >> >> As a workaround I currently have to do something like >> git tag -f FAILED_HEAD $(cat .git/rebase-merge/stopped-sha) >> after seeing rebase failure. Then I can hit F5 in gitk to easily locate >> the source commit. >> >> PS. Is there a way to automatically run git tag -f FAILED_HEAD $(cat >> .git/rebase-merge/stopped-sha) if rebase fails in the middle of branch? >>
