list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Johannes Schindelin <>
Subject: Re: [RFH] sequencer: simplify logic around stopped-sha file
Date: Sat, 26 Sep 2020 17:08:46 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Johannes Schindelin's message of "Sat, 26 Sep 2020 23:28:14 +0200 (CEST)")

Johannes Schindelin <> 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.


  reply	other threads:[~2020-09-27  0:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25  5:48 Junio C Hamano
2020-09-26 21:28 ` Johannes Schindelin
2020-09-27  0:08   ` Junio C Hamano [this message]
2020-09-28 19:51     ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [RFH] sequencer: simplify logic around stopped-sha file' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for project(s) associated with this inbox:

AGPL code for this site: git clone