From: David Turner <dturner@twopensource.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>, git@vger.kernel.org, mhagger@alum.mit.edu
Subject: Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs
Date: Thu, 09 Jul 2015 17:53:20 -0400 [thread overview]
Message-ID: <1436478800.4542.61.camel@twopensource.com> (raw)
In-Reply-To: <xmqqmvz5x4cc.fsf@gitster.dls.corp.google.com>
On Wed, 2015-07-08 at 22:55 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
>
> > I didn't see this until after I had sent my previous message. I think
> > the "multiple working trees" argument is strong enough that I will
> > change the code (and tests).
>
> Not just code, but we probably should step back a bit and clearly
> define what we are trying to achieve. I _think_ what we want are:
>
> - Everything under refs/* and their associated logs would be handed
> off to the "pluggable ref backend" when one is in use.
>
> - All ref-like things with one-level ALL_CAPS names are per working
> tree.
>
> - They do not participate in "prunable?" reachability
> computation.
>
> - They (typically) do not want "logs".
Except HEAD definitely does.
> - Each may have extra information specific to it.
> - You can however read an object name off of them.
>
> One possible and straight-forward implementation to achieve
> "ref-like things with one-level ALL_CAPS names are per working tree"
> is to declare that they will not be handed off to the backend, but
> will always be implemented as files immediately under $GIT_DIR/.
>
> But note that there is no fundamental reason we have to do it that
> way; an alternative would be to allow backends to store these things
> per working tree, but then the interface to drive backends need to
> tell them which working tree we are working from.
>
> Unlike branches, HEAD must be per working tree; the "pluggable ref
> backend" needs to be able handle HEAD when you introduce it.
I actually punted on this in my implementation, because at the time,
git-new-workdir was only in contrib. But since the new worktree stuff,
multiple worktrees have first-class support, so I'll have to update the
code to handle it.
> So
> from that point of view, "multiple working tree" is *not* a valid
> argument why they *have* to be implemented as files under $GIT_DIR/.
> If you plan to let the pluggable ref backend to handle HEAD, you
> must have a solution for per working tree ref-like things anyway.
OK, here's my current best idea:
1. A "pseudoref" is an all-caps file in $GIT_DIR/ that always contains
at least a SHA1. CHERRY_PICK_HEAD and REVERT_HEAD are examples. Because
HEAD might be a symbolic ref, it is not a pseudoref.
Refs backends do not manage pseudorefs. Instead, when a pseudoref (an
all-caps ref containing no slashes) is requested (e.g. git rev-parse
FETCH_HEAD) the generic refs code checks for the existence of that
file and if it exists, returns immediately without hitting the backend.
The generic code will refuse to allow updates to pseudorefs.
2. The pluggable refs backend manages all refs other than HEAD.
3. The "files" backend always manages HEAD. This allows for a reflog
and for HEAD to be a symbolic ref.
The major complication here is ref transactions -- what if there's a
transaction that wants to update e.g. both HEAD and refs/heads/master?
It may be the case that this never happens; I have not actually audited
the code to figure it out. If someone knows for sure that it does not
happen, please say so. But assuming it does happen, here's my idea:
If the refs backend is the files backend, we can simply treat HEAD like
any other ref.
If the refs backend is different, then the refs code needs to hold a
files-backend transaction for HEAD, which it will commit immediately
after the other transaction succeeds. We can stick a pointer to the
extra transaction in the generic struct ref_transaction, which (as
Michael Haggerty suggests) specific backends will extend.
A failure to commit either transaction will be reported as a failure,
and we'll give an additional inconsistent state warning if the main
transaction succeeds but the HEAD transaction fails.
I don't love this idea -- it seems like kind of a hack. But it's the
best I can come up with.
What do other folks think?
> As to J6t's "no excessive plumbing invocations", I think the right
> approach is to have a single "git prompt--helper" command that does
> what the current script does to compute $r. "we want to keep
> peeking into files under $GIT_DIR/" alone is not a valid enough
> reason to constrain us (I am fine if the solution we find
> appropriate for the 'multiple working trees' and other issues ends
> up being "we solve it by having them as files in $GIT_DIR" for other
> reasons, though).
Agree.
next prev parent reply other threads:[~2015-07-09 21:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 0:55 [PATCH v7 1/8] refs.c: add err arguments to reflog functions David Turner
2015-07-08 0:55 ` [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs David Turner
2015-07-08 17:46 ` Johannes Sixt
2015-07-08 19:16 ` David Turner
2015-07-08 21:14 ` Johannes Sixt
2015-07-08 23:23 ` Junio C Hamano
2015-07-08 23:44 ` David Turner
2015-07-09 5:55 ` Junio C Hamano
2015-07-09 21:53 ` David Turner [this message]
2015-07-09 22:06 ` Junio C Hamano
2015-07-10 4:30 ` Michael Haggerty
2015-07-10 17:59 ` David Turner
2015-07-14 4:33 ` David Turner
2015-07-15 16:24 ` Junio C Hamano
2015-07-15 18:04 ` David Turner
2015-07-08 23:41 ` David Turner
2015-07-08 0:55 ` [PATCH v7 3/8] bisect: treat BISECT_HEAD as a ref David Turner
2015-07-08 0:55 ` [PATCH v7 4/8] refs: Break out check for reflog autocreation David Turner
2015-07-08 0:56 ` [PATCH v7 5/8] refs: new public ref function: safe_create_reflog David Turner
2015-07-08 11:49 ` Michael Haggerty
2015-07-08 0:56 ` [PATCH v7 6/8] git-reflog: add exists command David Turner
2015-07-08 0:56 ` [PATCH v7 7/8] update-ref and tag: add --create-reflog arg David Turner
2015-07-08 13:44 ` Michael Haggerty
2015-07-08 20:21 ` David Turner
2015-07-08 0:56 ` [PATCH v7 8/8] git-stash: use update-ref --create-reflog instead of creating files David Turner
2015-07-08 7:28 ` Junio C Hamano
2015-07-08 7:33 ` Junio C Hamano
2015-07-08 13:50 ` Michael Haggerty
2015-07-08 11:36 ` [PATCH v7 1/8] refs.c: add err arguments to reflog functions Michael Haggerty
2015-07-08 20:01 ` David Turner
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1436478800.4542.61.camel@twopensource.com \
--to=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=mhagger@alum.mit.edu \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.