git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Han-Wen Nienhuys <hanwen@google.com>
Cc: Han-Wen Nienhuys via GitGitGadget <gitgitgadget@gmail.com>,
	git <git@vger.kernel.org>, Han-Wen Nienhuys <hanwenn@gmail.com>
Subject: Re: [PATCH v3 0/3] Remove special casing for PSEUDOREF updates
Date: Mon, 03 Aug 2020 13:07:12 -0700	[thread overview]
Message-ID: <xmqqh7tjv6hb.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAFQ2z_O1sRm-_SNP=-GvgNLqB+qgf6k9YVfbF1XCAmFWdeX6Ew@mail.gmail.com> (Han-Wen Nienhuys's message of "Mon, 3 Aug 2020 21:07:18 +0200")

Han-Wen Nienhuys <hanwen@google.com> writes:

>> >> As the file is quite different from all the other pseudo references
>> >> in that it needs to store more than one object name and in that each
>> >> ref in it needs more than just the object name, I doubt that it
>> >> makes much sense to enhance the refs API so that its requirements
>> >> can be covered.
>> >
>> > I agree. Do we ever pretend that FETCH_HEAD is a ref today?
>>
>> "git rev-parse FETCH_HEAD", "git show FETCH_HEAD" etc. all should keep
>> working, so in that sense, it is treated as a ref.
>
> I added this to the last version of the full reftable patch series
> that I posted, as patches
> "Split off reading loose ref data in separate function" and "Read
> FETCH_HEAD as loose ref".
>
> Which other refs that aren't really refs should also be supported? The
> JGit source code suggests that MERGE_HEAD should also be special
> cased?

I'd think all .git/${SOMETHING}_HEAD are of transitory nature that
can be left as simple on-disk files that are read (and preferrably
written---except for FETCH_HEAD for obvious reasons) as if they are
loose refs handled by files backend.  It probably makes sense not to
even write reflog entries for them---it is not like the MERGE_HEAD
I see now in .git/ directory is an updated version of MERGE_HEAD I
had there yesterday. "git log -g MERGE_HEAD" gives no interesting
information.

>> "git merge FETCH_HEAD" is an interesting case---I haven't thought it
>> through.
>>
>> What should happen after "git pull origin foo bar" attempts to grab
>> two branches and make an octopus merge into the branch currently
>> checked out, and then "git reset --hard && git merge FETCH_HEAD" is
>> given?
>
> I don't understand this question.

The request "git pull origin foo bar" is "grab the tip of 'foo' and
'bar' branches from remote whose name is 'origin'; merge these two
commits into the commit that I have checked out".

To fulfill the request, "git pull" runs "git fetch", and the latter
leaves two lines of interest in .git/FETCH_HEAD file.  Each line
lists the name of the object at the ref, an optional "not-for-merge"
token (which in this case does not exist, as both records are for
merging), and piece of human-readable text to describe where that
object came from to help later step that computes the default
message for the resulting merge commit.

If the octopus merge does not finish correctly (e.g. due to
conflicts), with "git reset --hard", we can recover to the original
state and re-attempt the opeation with "git merge FETCH_HEAD".  Such
a merge using FETCH_HEAD will produce an octopus merge.

Which means that at least "git merge", FETCH_HEAD is not just a
regular ref where you can ask what object it points at and it gives
you a single object name back.

But to other commands like "git log master..FETCH_HEAD", it acts as
if there is only one object recorded.  That makes it an interesting
case.  Making it act as if "git log ^master origin/foo origin/bar"
were given might be a "bugfix" to make it behave more "correctly",
but I do not know how large a fallout such a change brings in.




  reply	other threads:[~2020-08-03 20:07 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06 17:29 [PATCH 0/2] " Han-Wen Nienhuys via GitGitGadget
2020-07-06 17:29 ` [PATCH 1/2] Modify pseudo refs through ref backend storage Han-Wen Nienhuys via GitGitGadget
2020-07-06 20:26   ` Junio C Hamano
2020-07-07 13:56     ` Han-Wen Nienhuys
2020-07-07 15:20       ` Junio C Hamano
2020-07-07 17:15         ` Han-Wen Nienhuys
2020-07-07 18:14           ` Junio C Hamano
2020-07-06 17:29 ` [PATCH 2/2] Make HEAD a PSEUDOREF rather than PER_WORKTREE Han-Wen Nienhuys via GitGitGadget
2020-07-06 20:30   ` Junio C Hamano
2020-07-07  9:24     ` Han-Wen Nienhuys
2020-07-09 21:11 ` [PATCH v2 0/3] Remove special casing for PSEUDOREF updates Han-Wen Nienhuys via GitGitGadget
2020-07-09 21:11   ` [PATCH v2 1/3] t1400: use git rev-parse for testing PSEUDOREF existence Han-Wen Nienhuys via GitGitGadget
2020-07-09 21:11   ` [PATCH v2 2/3] Modify pseudo refs through ref backend storage Han-Wen Nienhuys via GitGitGadget
2020-07-09 21:11   ` [PATCH v2 3/3] Make HEAD a PSEUDOREF rather than PER_WORKTREE Han-Wen Nienhuys via GitGitGadget
2020-07-10 19:25   ` [PATCH v2 0/3] Remove special casing for PSEUDOREF updates Junio C Hamano
2020-07-16 18:45   ` [PATCH v3 " Han-Wen Nienhuys via GitGitGadget
2020-07-16 18:45     ` [PATCH v3 1/3] t1400: use git rev-parse for testing PSEUDOREF existence Han-Wen Nienhuys via GitGitGadget
2020-07-16 18:45     ` [PATCH v3 2/3] Modify pseudo refs through ref backend storage Han-Wen Nienhuys via GitGitGadget
2020-07-17  8:52       ` Johannes Schindelin
2020-07-27 15:41         ` Han-Wen Nienhuys
2020-07-16 18:45     ` [PATCH v3 3/3] Make HEAD a PSEUDOREF rather than PER_WORKTREE Han-Wen Nienhuys via GitGitGadget
2020-07-16 22:09     ` [PATCH v3 0/3] Remove special casing for PSEUDOREF updates Junio C Hamano
2020-07-27  8:50       ` Han-Wen Nienhuys
2020-07-27 16:20         ` Junio C Hamano
2020-08-03 19:07           ` Han-Wen Nienhuys
2020-08-03 20:07             ` Junio C Hamano [this message]
2020-08-05  1:45               ` Junio C Hamano
2020-08-05 10:48                 ` Han-Wen Nienhuys
2020-08-05 15:54                   ` Junio C Hamano
2020-08-10 14:27                     ` Han-Wen Nienhuys
2020-08-10 16:04                       ` Junio C Hamano
2020-08-11 10:49                         ` Han-Wen Nienhuys
2020-08-11 18:38                           ` Junio C Hamano
2020-08-19 13:19                     ` Han-Wen Nienhuys
2020-08-19 15:52                       ` Junio C Hamano
2020-07-27 16:25     ` [PATCH v4 " Han-Wen Nienhuys via GitGitGadget
2020-07-27 16:25       ` [PATCH v4 1/3] t1400: use git rev-parse for testing PSEUDOREF existence Han-Wen Nienhuys via GitGitGadget
2020-07-27 16:25       ` [PATCH v4 2/3] Modify pseudo refs through ref backend storage Han-Wen Nienhuys via GitGitGadget
2020-07-27 16:25       ` [PATCH v4 3/3] Make HEAD a PSEUDOREF rather than PER_WORKTREE Han-Wen Nienhuys via GitGitGadget

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=xmqqh7tjv6hb.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=hanwen@google.com \
    --cc=hanwenn@gmail.com \
    --subject='Re: [PATCH v3 0/3] Remove special casing for PSEUDOREF updates' \
    /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

Code repositories for project(s) associated with this 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).