Re: [PATCH] worktree: update is_bare heuristics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, 18 Apr 2019, Junio C Hamano wrote:

> Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes:
>
> > When "git branch -D <name>" is run, Git usually first checks if that
> > branch is currently checked out. But this check is not performed if the
> > Git directory of that repository is not at "<repo>/.git", which is the
> > case if that repository is a submodule that has its Git directory stored
> > as "super/.git/modules/<repo>", for example.
> >
> > This is because get_main_worktree() in worktree.c sets is_bare on a
> > worktree only using the heuristic that a repo is bare if the worktree's
> > path ends in "/.git", and not bare otherwise. This is_bare code was
> > introduced in 92718b7438 ("worktree: add details to the worktree
> > struct", 2015-10-08), following a pre-core.bare heuristic. This patch
> > does 2 things:
> >
> >  - Teach get_main_worktree() to use is_bare_repository() instead,
> >    introduced in 7d1864ce67 ("Introduce is_bare_repository() and
> >    core.bare configuration variable", 2007-01-07) and updated in
> >    e90fdc39b6 ("Clean up work-tree handling", 2007-08-01). This solves
> >    the "git branch -D <name>" problem described above. However...
> >
> >  - If a repository has core.bare=1 but the "git" command is being run
> >    from one of its added worktrees, is_bare_repository() returns false
> >    (which is fine, since there is a worktree available). However,
> >    commands like "git worktree list" currently distinguish between a
> >    repository that has core.bare=1 but has a worktree available, and a
> >    repository that is truly non-bare (core.bare=0). To preserve this
> >    distinction, also check core.bare when setting is_bare. If
> >    core.bare=1, trust it, and otherwise, use is_bare_repository().
>
> I am not sure if the latter is worth keeping, but the former
> definitely is a huge improvement, I would imagine.

I think that both are improvements, with the former definitely being the
more impactful one.

> Somebody did "git branch -D <that-branch>" by accident in a submodule
> checkout, or something?

/me shudders at the thought of it

The patch makes tons of sense to me.

Thank you,
Dscho




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux