Re: What exactly is a "initial checkout"

From: Jeff King <peff@peff.net>
Date: Nov 6, 2018, 21:18 UTC
Message-ID: <20181106211852.GA8513@sigill.intra.peff.net>
In-Reply-To: <CAENte7hoHxQCiQwSaAGPyaeFK8rb2Q23DcbePd01fcvgxtodZg@mail.gmail.com>

On Tue, Nov 06, 2018 at 01:38:45PM +0100, Christian Halstrick wrote:

Show 14 quoted lines

> I am trying to teach JGit [1] to behave like native git regarding some
> corner cases during "git checkout". I am reading the "git read-tree"
> documentation and I am not sure about the case [2]. Git should behave
> differently during a normal checkout than when you are doing a
> "initial checkout". I can imagine that the first checkout you do after
> you have cloned a repo is a initial checkout but: What exactly defines
> a "initial checkout"? It can't be an empty or non-existing index
> because native git behaves like in a non-initial-checkout even if the
> index is empty (see example below).
> 
> Here are some commands explaining my case. Git is facing an empty
> index, HEAD and MERGE (the commit you checkout) have the some content
> for path 'p'  and still git is neither updating index nor workingtree
> file during checkout.

Without looking at the code, I'd assume that an empty HEAD is different than "there is no HEAD at all". I.e., what we call an "unborn branch" elsewhere.

So perhaps try:

  git init
  git fetch ../some/other/repo HEAD:tmp
  git checkout tmp

where you'd truly have no HEAD.

Though peeking at the code, it looks like we set the unpack_trees initial_checkout flag based on is_cache_unborn(), which looks for a totally missing index file (not just an empty one). That would trigger in the above case, too, though, because of course we have no index there either.

-Peff