list mirror (unofficial, one of many)
 help / color / Atom feed
From: Junio C Hamano <>
To: Elijah Newren <>
Cc: Bert Wesarg <>,
	Matheus Tavares Bernardino <>,
	git <>, Jeff King <>,
	Derrick Stolee <>,
	Taylor Blau <>
Subject: Re: git-grep in sparse checkout
Date: Wed, 02 Oct 2019 15:33:37 +0900
Message-ID: <> (raw)
In-Reply-To: <> (Elijah Newren's message of "Tue, 1 Oct 2019 09:12:26 -0700")

Elijah Newren <> writes:

> * other commands (archive, bisect, clean?, gitk, shortlog, blame,
> fsck?, etc.) likely need to pay attention to sparsity patterns as
> well, but there are some special cases:

"git archive" falls into the same class as fast-(im|ex)port; it
should ignore the sparse cone by default.  I suspect you threw
"fsck" as a joke, but I do not think it should pay attention to the
sparse cone, either (besides, most of the time in fsck the objects
subject to checking do not know all the paths that reach them).

> * merge, cherry-pick, and rebase (anything touching the merge
> machinery) will need to expand the size of the non-sparse worktree if
> there are files outside the sparsity patterns with conflicts.  (Though
> merge should do a better job of not expanding the non-sparse worktree
> when files can cleanly be resolved.)

I think the important point is what is done to the result of
operation.  Result of these operations that create new commits are
meant to be consumed by other people, who may not share your
definition of sparse cone.  And such a command (i.e. those whose
results are consumed by others who may have different sparse cone)
must be full-tree by default.

> * fast-export and format-patch are not about viewing history but about
> exporting it, and limiting to sparsity patterns would result in the
> creation of an incompatible history.

I agree with the conclusion; see above.

> * New worktrees, by default, should copy the sparsity-patterns of the
> worktree they were created from (much like a new shell inherits the
> current working directory of it's parent process)

Sorry, but I do not share this view at all.

In my mental model, "worktree new" is to attach a brand-new worktree
to a bare repository that underlies the existing worktree I happen
to be in, and that existing worktree that I happen to type "worktree
new" in is no more or no less special than other worktrees.

The above isn't to say that I'd veto your "a new worktree inherits
traits from an existing worktree that 'git worktree add' was invoked
in" idea.  I am just saying that I have a problem with that mode of
operation and mental model being the default.

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01 13:06 Matheus Tavares Bernardino
2019-10-01 13:30 ` Bert Wesarg
2019-10-01 16:12   ` Elijah Newren
2019-10-02  6:33     ` Junio C Hamano [this message]
2019-10-02 16:46       ` Elijah Newren
2019-10-01 18:29 ` Derrick Stolee
2019-10-02  0:06   ` Matheus Tavares Bernardino
2019-10-02  6:18   ` Junio C Hamano
2019-10-02 12:09     ` Derrick Stolee

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone