Re: gc and repack ignore .git/*HEAD when checking reachability

On Wed, Jul 13, 2016 at 8:59 PM, Johannes Schindelin wrote: >> No. > > Oh? So you do not see that we are already heading into serious trouble > ourselves? I do see problems, that have solutions. But I have not yet seen that we are heading to a dead end. >> I prefer

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Duy, On Wed, 13 Jul 2016, Duy Nguyen wrote: > On Wed, Jul 13, 2016 at 10:20 AM, Johannes Schindelin > wrote: > > > > On Tue, 12 Jul 2016, Duy Nguyen wrote: > > > >> On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote: > >> > On Tue, Jul 12, 2016 at

Re: gc and repack ignore .git/*HEAD when checking reachability

On Wed, Jul 13, 2016 at 10:20 AM, Johannes Schindelin wrote: > Hi Duy, > > On Tue, 12 Jul 2016, Duy Nguyen wrote: > >> On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote: >> > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote: >> > >> >> I'm not

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Duy, On Tue, 12 Jul 2016, Duy Nguyen wrote: > On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote: > > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote: > > > >> I'm not opposed to letting one worktree see everything, but this move > >> makes it harder to write new

Re: gc and repack ignore .git/*HEAD when checking reachability

On Tue, Jul 12, 2016 at 5:51 PM, Jeff King wrote: > On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote: > >> I'm not opposed to letting one worktree see everything, but this move >> makes it harder to write new scripts (or new builtin commands, even) >> that works with both

Re: gc and repack ignore .git/*HEAD when checking reachability

On Tue, Jul 12, 2016 at 05:46:12PM +0200, Duy Nguyen wrote: > I'm not opposed to letting one worktree see everything, but this move > makes it harder to write new scripts (or new builtin commands, even) > that works with both single and multiple worktrees because you refer > to one ref (in

Re: gc and repack ignore .git/*HEAD when checking reachability

On Tue, Jul 12, 2016 at 5:26 PM, Jeff King wrote: > 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. I'm not opposed to letting one worktree see

Re: gc and repack ignore .git/*HEAD when checking reachability

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

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Junio, On Mon, 11 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> No, the point is, refs subsystem needs to know which refs is per-repo, > >> which is per-worktree. So far the rules are "everything under refs, > >> except a few known

Re: gc and repack ignore .git/*HEAD when checking reachability

Johannes Schindelin writes: >> No, the point is, refs subsystem needs to know which refs is per-repo, >> which is per-worktree. So far the rules are "everything under refs, >> except a few known exceptions, is per-repo" and "everything directly >> under $GIT_DIR is

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Duy, On Sun, 10 Jul 2016, Duy Nguyen wrote: > We will be able to see refs from all worktrees if we choose to. What I tried to say is: even if we make it technically feasible to have per-worktree refs or reflogs, the downsides are too prohibitive. We should simply not introduce support for

Re: gc and repack ignore .git/*HEAD when checking reachability

On Sun, Jul 10, 2016 at 4:16 PM, Johannes Schindelin wrote: >> No, the point is, refs subsystem needs to know which refs is per-repo, >> which is per-worktree. So far the rules are "everything under refs, >> except a few known exceptions, is per-repo" and "everything

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Duy, On Sun, 10 Jul 2016, Duy Nguyen wrote: > On Sun, Jul 10, 2016 at 12:59 PM, Johannes Schindelin > wrote: > >> >> Now, how about special-casing *just* these legacy files in gc: HEAD, > >> >> FETCH_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD? Any new transient refs >

Re: gc and repack ignore .git/*HEAD when checking reachability

On Sun, Jul 10, 2016 at 12:59 PM, Johannes Schindelin wrote: >> >> Now, how about special-casing *just* these legacy files in gc: HEAD, >> >> FETCH_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD? Any new transient refs should >> >> live in the refs/ namespace, which is already

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Duy, On Sat, 9 Jul 2016, Duy Nguyen wrote: > On Sat, Jul 9, 2016 at 4:09 PM, Josh Triplett wrote: > > On Sat, Jul 09, 2016 at 09:35:24AM +0200, Johannes Schindelin wrote: > >> On Fri, 8 Jul 2016, Junio C Hamano wrote: > >> > Josh Triplett

Re: gc and repack ignore .git/*HEAD when checking reachability

On Sat, Jul 9, 2016 at 4:09 PM, Josh Triplett wrote: > On Sat, Jul 09, 2016 at 09:35:24AM +0200, Johannes Schindelin wrote: >> On Fri, 8 Jul 2016, Junio C Hamano wrote: >> > Josh Triplett writes: >> > >> > > That sounds reasonable. And if they *do*

Re: gc and repack ignore .git/*HEAD when checking reachability

On Sat, Jul 09, 2016 at 09:35:24AM +0200, Johannes Schindelin wrote: > On Fri, 8 Jul 2016, Junio C Hamano wrote: > > Josh Triplett writes: > > > > > That sounds reasonable. And if they *do* end up taking any time to > > > traverse, it's because they weren't reachable from

Re: gc and repack ignore .git/*HEAD when checking reachability

Hi Junio, On Fri, 8 Jul 2016, Junio C Hamano wrote: > Josh Triplett writes: > > > That sounds reasonable. And if they *do* end up taking any time to > > traverse, it's because they weren't reachable from other anchoring > > points, so taking the extra time to traverse

Re: gc and repack ignore .git/*HEAD when checking reachability

On Fri, Jul 08, 2016 at 07:50:53PM -0400, Theodore Ts'o wrote: > On Fri, Jul 08, 2016 at 01:30:06PM -0700, Junio C Hamano wrote: > > > > I can imagine I'd start hacking on a project that I rarely touch, give up > > resolving a "git pull" from an unconfigured place (hence, some stuff is > > only

Re: gc and repack ignore .git/*HEAD when checking reachability

On Fri, Jul 08, 2016 at 01:30:06PM -0700, Junio C Hamano wrote: > > I can imagine I'd start hacking on a project that I rarely touch, give up > resolving a "git pull" from an unconfigured place (hence, some stuff is > only reachable from FETCH_HEAD), and after 2*N days, come back > to the

Re: gc and repack ignore .git/*HEAD when checking reachability

On Fri, Jul 8, 2016 at 12:25 PM, Theodore Ts'o wrote: > On Fri, Jul 08, 2016 at 10:14:33AM -0700, Junio C Hamano wrote: >> >> It cannot be "anything directly under .git that has all-caps name >> that ends with _HEAD". The ones we write we know are going to be >> removed at some

Re: gc and repack ignore .git/*HEAD when checking reachability

On Fri, Jul 08, 2016 at 10:14:33AM -0700, Junio C Hamano wrote: > Josh Triplett writes: > > > That sounds reasonable. And if they *do* end up taking any time to > > traverse, it's because they weren't reachable from other anchoring > > points, so taking the extra time to

Re: gc and repack ignore .git/*HEAD when checking reachability

On Fri, Jul 08, 2016 at 10:14:33AM -0700, Junio C Hamano wrote: > > It cannot be "anything directly under .git that has all-caps name > that ends with _HEAD". The ones we write we know are going to be > removed at some point in time (e.g. "git reset", "git bisect reset", > "git merge --abort",

Re: gc and repack ignore .git/*HEAD when checking reachability

Josh Triplett writes: > That sounds reasonable. And if they *do* end up taking any time to > traverse, it's because they weren't reachable from other anchoring > points, so taking the extra time to traverse them seems fine. The only thing that is hard is to clearly

Re: gc and repack ignore .git/*HEAD when checking reachability

On Thu, Jul 07, 2016 at 09:34:02PM -0700, Junio C Hamano wrote: > Josh Triplett writes: > > This could result in data loss, if a user expected that having an object > > referenced from those places would protect it from pruning. > > Yeah, luckily, nobody expects such. I

Re: gc and repack ignore .git/*HEAD when checking reachability

Josh Triplett writes: > This could result in data loss, if a user expected that having an object > referenced from those places would protect it from pruning. Yeah, luckily, nobody expects such. I do not think any of our document says nothing other than HEAD like

gc and repack ignore .git/*HEAD when checking reachability

The manpage for git gc says: > git gc tries very hard to be safe about the garbage it collects. In > particular, it will keep not only objects referenced by your current > set of branches and tags, but also objects referenced by the index, > remote-tracking branches, refs saved by git