git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Orgad Shaneh <orgads@gmail.com>,
	 Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] prune: mark rebase autostash and orig-head as reachable
Date: Thu, 08 Feb 2024 10:06:38 -0800	[thread overview]
Message-ID: <xmqqmssan841.fsf@gitster.g> (raw)
In-Reply-To: <pull.1656.git.1707411636382.gitgitgadget@gmail.com> (Phillip Wood via GitGitGadget's message of "Thu, 08 Feb 2024 17:00:36 +0000")

"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Rebase records the oid of HEAD before rebasing and the commit created by
> "--autostash" in files in the rebase state directory. This means that
> the autostash commit is never reachable from any ref or reflog and when
> rebasing a detached HEAD the original HEAD can become unreachable if the
> user expires HEAD's the reflog while the rebase is running. Fix this by
> reading the relevant files when marking reachable commits.

I do not like this kind of special casing in general, but because
these are our tools' droppings, I am OK to grandfather them in, as
long as we promise ourselves that we will not add more of these
ad-hoc "text files" that record object names, loss of which affects
correctness.  They should, like "git bisect", be using proper
references to protect these objects instead, of course.

I agree with you that we might want to add pseudorefs as a starting
points of reachability traversal, but I suspect it would add
unnecessary complexity we would rather not want to deal with.

For example, not GC'ing what is pointed at by lines in FETCH_HEAD is
OK.  Excluding those objects that are only reachable from an object
mentioned by a pseudoref, when a new "git fetch" is negotiating with
a remote what objects need to be sent here, might be disastrous, as
the pseudoref that said "this object is here and you can safely
consider everything reachable from it is" will be short-lived and
can go away anytime, and an auto-gc kicking in at a wrong time ...

Thanks.


  parent reply	other threads:[~2024-02-08 18:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-08 17:00 [PATCH] prune: mark rebase autostash and orig-head as reachable Phillip Wood via GitGitGadget
2024-02-08 17:25 ` Eric Sunshine
2024-02-09 11:08   ` Phillip Wood
2024-02-08 18:06 ` Junio C Hamano [this message]
2024-02-09 14:15   ` Phillip Wood
2024-02-09 16:19 ` [PATCH v2] " Phillip Wood via GitGitGadget
2024-02-09 18:04   ` Junio C Hamano

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqmssan841.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=orgads@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).