Re: [PATCH v2 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

From: Junio C Hamano <gitster@pobox.com>
Date: May 20, 2017, 23:49 UTC
Message-ID: <xmqqzie7qeal.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACpkpxmGzz0hUsypX5ORX7FLB3rh_xbyPOKz4SUt-zrjSjCq_g@mail.gmail.com>

Manish Goregaokar <manishearth@gmail.com> writes:

> One thing which I think hasn't been covered yet is the rebase
> ORIG_HEAD. I'll see if that's still a problem on `pu` and make a patch
> for it if so.

IIRC, ORIG_HEAD, FETCH_HEAD, MERGE_HEAD and others are be transitory and never served as the starting points of reachability traversal, even in the primary worktree (also when you are not using any extra worktrees). The commits listed in the todo list of "rebase -i" and "git cherry-pick A..B" are the same way.

Because ORIG_HEAD is expected to be in a reflog of some ref (at least, the reflog of HEAD), I do not see much benefit (or "more safety") in adding it to the starting points.

Among the ones that appear in .git/ and we never considered as starting points, the commits in FETCH_HEAD might be the ones we may want to give extra protection over what we currently have, simply because the ones that do not have remote-tracking branches have NO other refs pointing at them (compared to these transitory artifacts resulting from a local operation, i.e. ORIG_HEAD and ones in the todo list). But they by definition are "new" objects, and the reason why the user does *not* use remote-tracking branches for them is because the user does not want to keep record of them unless the user decides to merge them somewhere in the repository's history, so even for them the benefit is dubious...