git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Duy Nguyen <pclouds@gmail.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: gc and repack ignore .git/*HEAD when checking reachability
Date: Tue, 12 Jul 2016 11:26:46 -0400	[thread overview]
Message-ID: <20160712152646.GF613@sigill.intra.peff.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1607121243470.6426@virtualbox>

On Tue, Jul 12, 2016 at 12:47:06PM +0200, Johannes Schindelin wrote:

> > Not so fast; it cuts both ways.
> > 
> > People who want multiple worktrees with branches checked out to work
> > in would want to do per-worktree things like bisection, which needs
> > tons more state than we'd be comfortable having directly under
> > $GIT_DIR (e.g. they may also want "git merge" or "git pull", which
> > would use MERGE_HEAD and FETCH_HEAD that are per-worktree and not
> > under refs/; "git bisect" would want to mark number of commits to
> > denote the perimeter of the area of the history being bisected and
> > they live refs/bisect/).
> 
> Sure, `git bisect` would need to realize that it is running in a worktree
> separate from the original one and use a different ref.

I am mostly a bystander in all of these worktree discussions, but your
comment here makes a lot of sense to me. We currently have a global ref
namespace, but the current proposals seem to want to slice it on
invisible lines into per-worktree and global bits, where "refs/bisect"
is no longer a global name. But we could also retain a global view, and
just let worktrees carve out their own portion of the namespace
("refs/worktree/foo/bisect", or even organize it by application area,
"refs/bisect/foo/bad", etc).

Besides being conceptually simpler in the code (global reachability Just
Works, because you see all of the refs), it would also let you access
individual refs between worktrees if you wanted. So for example, if you
are bisecting in worktree "foo", you can access its results from another
worktree with "git show bisect/foo/bad".

Likewise for other per-worktree items. If we used refs/MERGE_HEAD and
refs/worktree/foo/MERGE_HEAD, then you could access them independently
by using the fully qualified names.

The only downside I see is that the existing names are sometimes
well-known. I wonder if we could simply add:

  refs/worktree/<your-worktree>/%s

to the dwim ref-lookup when a command is running in a worktree.

-Peff

  reply	other threads:[~2016-07-12 15:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08  2:59 gc and repack ignore .git/*HEAD when checking reachability Josh Triplett
2016-07-08  4:34 ` Junio C Hamano
2016-07-08  6:44   ` Josh Triplett
2016-07-08 17:14     ` Junio C Hamano
2016-07-08 19:25       ` Theodore Ts'o
2016-07-08 20:30         ` Junio C Hamano
2016-07-08 23:50           ` Theodore Ts'o
2016-07-09  5:23             ` Josh Triplett
2016-07-08 20:29       ` Josh Triplett
2016-07-09  7:35       ` Johannes Schindelin
2016-07-09 14:09         ` Josh Triplett
2016-07-09 16:45           ` Duy Nguyen
2016-07-10 10:59             ` Johannes Schindelin
2016-07-10 11:04               ` Duy Nguyen
2016-07-10 14:16                 ` Johannes Schindelin
2016-07-10 15:01                   ` Duy Nguyen
2016-07-11  6:07                     ` Johannes Schindelin
2016-07-11 18:52                   ` Junio C Hamano
2016-07-12 10:47                     ` Johannes Schindelin
2016-07-12 15:26                       ` Jeff King [this message]
2016-07-12 15:46                         ` Duy Nguyen
2016-07-12 15:51                           ` Jeff King
2016-07-12 16:13                             ` Duy Nguyen
2016-07-13  8:20                               ` Johannes Schindelin
2016-07-13 14:54                                 ` Duy Nguyen
2016-07-13 18:59                                   ` Johannes Schindelin
2016-07-15 15:46                                     ` Duy Nguyen

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=20160712152646.GF613@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=josh@joshtriplett.org \
    --cc=pclouds@gmail.com \
    /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 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 NNTP newsgroup(s).