Re: [PATCH 10/16] worktree: make branch creation distinct from worktree population
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 12, 2015, 10:03 UTC
- Message-ID
- <CACsJy8BS7Ss3jP9sq1TuD7-wH6tTYwTKBk9=YVMiJh2ePigjuQ@mail.gmail.com>
- In-Reply-To
- <CAPig+cRV8oNw2Jp0mkn=CLTJERG+=O2pvewcjqF=xZ+dMgPnHA@mail.gmail.com>
(resend, +everybody)
On Sun, Jul 12, 2015 at 10:27 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 26 quoted lines
>>> So, if I understand your concern correctly, then you are worried that,
>>> following the git-branch invocation, ref_exists() could return the
>>> wrong answer with a pluggable ref-backend since it might be answering
>>> based upon stale information. Is that what you mean? If so, I can see
>>> how that it could be an issue. (As far as I can tell, the current
>>> file-based backend doesn't have a problem with this since it's hitting
>>> the filesystem directly to answer the ref_exists() question.)
>>
>> I meant for this final sentence to end like this:
>>
>> ...to answer the ref_exists() question, but it still seems
>> fragile since some future change could introduce caching.
>
> In this case, it's easy enough to side-step the issue since there's no
> need to call ref_exists() if the new branch was created successfully
> (since we know it exists). The logic would effectively become this:
>
> branch = ...
> if (create_new_branch) {
> exec "git branch newbranch branch"
> exec "git symbolic-ref HEAD newbranch"
> } else if (ref_exists(branch) && !detach)
> exec "git symbolic-ref HEAD branch"
> else
> exec "git update-ref HEAD $(git rev-parse branch)"
> exec "git reset --hard"Yeah.. Another option we can take is deal with this at run-command.c level (and outside this series) because this could affect everywhere: by default, invalidate all cache after running any git commands. The caller can pass options to keep some cache intact if they know the command won't touch it.
If ref_exists() is the only thing we use, right now it does not use cache so we should be safe. If the new ref backend introduces a cache, they would need to examine all callers anyway, including this one. The cache in refs.c seems to be for for_each_ref.. only, which we don't call here.
-- Duy