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)? > > At least in my understanding, you are not missing anything: > > - this file is an implementation detail, > > - it is not exposed directly via any user-visible interface, > > - any reader will _have_ to be prepared for an unabbreviated object ID (in > the highly unlikely case that an object ID would be ambiguous if > abbreviated even by one hex character), Ah, no that was not what I was worried about. If an existing code, after restarting and reading the abbreviated object name back from the file, compares that shortened string against list of shortened strings it has in-core (perhaps it reads todo back from the user in abbreviated form, does comparison with stopped-sha as-is, before it expands the object names from todo to full length), this change would break it. > - 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. Thanks.
