Hi Junio, On Sat, 26 Sep 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> Is there something obvious I am not seeing that makes this change a > >> bad idea (other than "somebody may be in the middle of a rebase and > >> all of a sudden, version of Git gets updated to contain this one, > >> which is unable to read abbreviated object name the current version > >> left on disk", which I am deliberately ignoring)? > > > > [...] > > - and most importantly: just like we expand the commit IDs in the todo > > list, we actually want to expand them in `stopped-sha` because it _is_ > > possible that a new object is written that makes the previous > > unambiguously abbreviated object ID now ambiguous (e.g. when the user > > commits in a separate worktree while the rebase is interrupted, before > > continuing the rebase). > > Exactly. I just wasn't sure if stopped-sha is handled with the same > carefulness as the object names in todo, which are expanded after > read and shortened before given back to the users. The main purpose of `stopped-sha` is to let `git rebase --continue` after an `edit` command amend the commit where it stopped _iff_ it is still `HEAD`. So yes, I think we need to be as careful here. Ciao, Dscho
