git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Robin H. Johnson" <robbat2@gentoo.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC] single-level refs vs push --all/--mirror
Date: Fri, 19 Nov 2021 22:05:40 -0800	[thread overview]
Message-ID: <xmqqlf1jnyyz.fsf@gitster.g> (raw)
In-Reply-To: <robbat2-20211119T234158-903098822Z@orbis-terrarum.net> (Robin H. Johnson's message of "Sat, 20 Nov 2021 00:03:36 +0000")

"Robin H. Johnson" <robbat2@gentoo.org> writes:

> I didn't see response from Jeff King, so I'm wondering good next steps
> here.
>
> I'm esp. surprised that git-stash ends up using single-level refs when
> git-check-ref-format(1) says they aren't valid.

They aren't valid name to be used as regular branches, tags, etc.,
but as an implementation detail of stash, "refs/stash" is perfectly
good.  There is nothing to "fix".  You cannot and you do not want to
pretend "stash" is yet another ref in the first place.

You can "transfer" refs/stash by pushing the commit to an arbitrary
ref with a regular "three level" name, like so:

   $ git push there refs/stash:refs/my/stash

but it wouldn't be of much use to begin with.

The thing is, the "list of random quick changes stashed away" is not
something stored in the "stash" ref.  These list entries are stored
as reflog entries for the stash ref, which is *never* transferred
over the network.  So, if the higher level issue you want to address
is to allow "stash" to be shared across repositories, none of these
5 choices you listed at the end of your message helps all that much.

The single-level refs are the least of your problems.

Instead, you'd probably want to reimplement "stash" as a set of
normal refs, whose current value only matters, e.g. refs/stash/0
may be the oldest stash, refs/stash/1 is the next one, refs/stash/2
is yet another new one, etc., and have UIs like "git stash list" 
list them in a new way that is different from the current reflog
based implementation, and "git stash pop/apply" take them, e.g.

   $ git stash list
   stash/0: WIP on main: cd3e606211 Git 2.34
   stash/4: WIP on maint: Merge branch 'vd/pthread-setspecific-g11-fix' into maint
   $ git stash apply stash/0

And at that point you'd have refs/stash/* as an intermediate
hierarchy, with another level of real refs hanging there, so you can
transfer them just like refs/tags/* all you want.

> I think Git should change git-stash and start issuing warnings to users
> for single-level refs.

No, single-level refs is perfectly fine, as long as you are using
the current Git and using these refs locally.  The problem arises
only when you start wanting to share stash across repositories, and
it is not from the levels of the refname hierarchy but from the fact
that stash is implemented in terms of reflog mechanism that is not
shared across repositories.



      reply	other threads:[~2021-11-20  6:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15  6:53 [BUG] git push --mirror ignores refs outside head & tags Robin H. Johnson
2021-11-15 21:04 ` Jeff King
2021-11-16  6:28   ` Robin H. Johnson
2021-11-20  0:03     ` [RFC] single-level refs vs push --all/--mirror Robin H. Johnson
2021-11-20  6:05       ` Junio C Hamano [this message]

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=xmqqlf1jnyyz.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=robbat2@gentoo.org \
    /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).