Re: [PATCH 1/5] git-prompt: do not look for refs/stash in $GIT_DIR

Re: [PATCH 1/5] git-prompt: do not look for refs/stash in $GIT_DIR

[Gábor Szeder]

Hi,

On Aug 23, 2014 12:26 PM, Jeff King <peff@peff.net> wrote:
> Since dd0b72c (bash prompt: use bash builtins to check stash 
> state, 2011-04-01), git-prompt checks whether we have a 
> stash by looking for $GIT_DIR/refs/stash. Generally external 
> programs should never do this, because they would miss 
> packed-refs.

Not sure whether the prompt script is external program or not, but doesn't matter, this is the right thing to do.

> That commit claims that packed-refs does not pack 
> refs/stash, but that is not quite true. It does pack the 
> ref, but due to a bug, fails to prune the ref. When we fix 
> that bug, we would want to be doing the right thing here. 
>
> Signed-off-by: Jeff King <peff@peff.net> 
> --- 
> I know we are pretty sensitive to forks in the prompt code (after all, 
> that was the point of dd0b72c). This patch is essentially a reversion of 
> this hunk of dd0b72c, and is definitely safe.

I'm not sure, but if I remember correctly (don't have the means to check it at the moment, sorry) in that commit I also added a 'git pack-ref' invocation to the relevant test(s?) to guard us against breakages due to changes in 'git pack-refs'.  If that is so, then I think those invocations should be removed as well, as they'll become useless.

Best,
Gábor

Re: [PATCH 1/5] git-prompt: do not look for refs/stash in $GIT_DIR

[Jeff King]

On Sun, Aug 24, 2014 at 08:22:41PM +0700, Gábor Szeder wrote:

> On Aug 23, 2014 12:26 PM, Jeff King <peff@peff.net> wrote:
> > Since dd0b72c (bash prompt: use bash builtins to check stash 
> > state, 2011-04-01), git-prompt checks whether we have a 
> > stash by looking for $GIT_DIR/refs/stash. Generally external 
> > programs should never do this, because they would miss 
> > packed-refs.
> 
> Not sure whether the prompt script is external program or not, but
> doesn't matter, this is the right thing to do.

Yeah, by external I just meant "nothing outside of refs.c should make
this assumption".

> > That commit claims that packed-refs does not pack 
> > refs/stash, but that is not quite true. It does pack the 
> > ref, but due to a bug, fails to prune the ref. When we fix 
> > that bug, we would want to be doing the right thing here. 
> >
> > Signed-off-by: Jeff King <peff@peff.net> 
> > --- 
> > I know we are pretty sensitive to forks in the prompt code (after all, 
> > that was the point of dd0b72c). This patch is essentially a reversion of 
> > this hunk of dd0b72c, and is definitely safe.
> 
> I'm not sure, but if I remember correctly (don't have the means to
> check it at the moment, sorry) in that commit I also added a 'git
> pack-ref' invocation to the relevant test(s?) to guard us against
> breakages due to changes in 'git pack-refs'.  If that is so, then I
> think those invocations should be removed as well, as they'll become
> useless.

It did add that change (that's actually how I noticed the problem!
Thank you for being thorough in dd0b72c). My inclination is to leave the
pack-refs invocations, as they protect against a certain class of errors
(we are not doing the risky behavior now, but the purpose of the test
suite is to detect regressions; the next person to touch that code may
not be so careful as you were).

I don't feel too strongly, though, so if we want them gone, I'm OK with
that.

-Peff

[PATCH 0/5] fix pack-refs pruning of refs/foo

[Jeff King]

I noticed that "git pack-refs --all" will pack a top-level ref like
"refs/foo", but will not actually prune "$GIT_DIR/refs/foo". I do not
see the point in having a policy not to pack "refs/foo" if "--all" is
given. But even if we did have such a policy, this seems broken; we
should either pack and prune, or leave them untouched. I don't see any
indication that the existing behavior was intentional.

The problem is that pack-refs's prune_ref calls lock_ref_sha1, which
enforces this "no toplevel" behavior. I am not sure there is any real
point to this, given that most callers use lock_any_ref_for_update,
which is exactly equivalent but without the toplevel check.

The first two patches deal with this by switching pack-refs to use
lock_any_ref_for_update. This will conflict slightly with Ronnie's
ref-transaction work, as he gets rid of lock_ref_sha1 entirely, and
moves the code directly into prune_ref. This can be trivially resolved
in favor of my patch, I think.

The third patch is a cleanup I noticed while looking around, and I think
should not conflict with anyone (and is a good thing to do).

The last two are trickier. I wondered if we could get rid of
lock_ref_sha1 entirely. After pack-refs, there are two callers:
fast-import.c and walker.c. After converting the first, it occurred to
me that Ronnie might be touching the same areas, and I see that yes,
indeed, there's quite a bit of conflict (and he reaches the same end
goal of dropping it entirely).

So in that sense I do not mind dropping the final two patches. Ronnie's
endpoint is much better, moving to a ref_transaction. However, there is
actually a buffer overflow in the existing code. Ronnie's series fixes
it in a similar way (moving to a strbuf), and I'm fine with that
endpoint. But given that the ref transaction code is not yet merged (and
would certainly never be maint-track), I think it is worth applying the
buffer overflow fix separately.

I think the final patch can probably be dropped, then. It is a clean-up,
but one that we can just get when Ronnie's series is merged.

  [1/5]: git-prompt: do not look for refs/stash in $GIT_DIR
  [2/5]: pack-refs: prune top-level refs like "refs/foo"
  [3/5]: fast-import: clean up pack_data pointer in end_packfile
  [4/5]: fast-import: fix buffer overflow in dump_tags
  [5/5]: fast-import: stop using lock_ref_sha1

-Peff

[PATCH 1/5] git-prompt: do not look for refs/stash in $GIT_DIR

[Jeff King]

Since dd0b72c (bash prompt: use bash builtins to check stash
state, 2011-04-01), git-prompt checks whether we have a
stash by looking for $GIT_DIR/refs/stash. Generally external
programs should never do this, because they would miss
packed-refs.

That commit claims that packed-refs does not pack
refs/stash, but that is not quite true. It does pack the
ref, but due to a bug, fails to prune the ref. When we fix
that bug, we would want to be doing the right thing here.

Signed-off-by: Jeff King <peff@peff.net>
---
I know we are pretty sensitive to forks in the prompt code (after all,
that was the point of dd0b72c). This patch is essentially a reversion of
this hunk of dd0b72c, and is definitely safe.

I think we could probably get by with:

  [ -r "$g/logs/ref/stash" ]

since reflogs are always in the filesystem. However, that seems somewhat
short-sighted, as the work Ronnie is doing is moving in the direction of
more abstraction here. I hope a day will come soon when reflogs do not
have to be stored in $GIT_DIR/logs, and then we would end up updating
this code again.

 contrib/completion/git-prompt.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9d684b1..c5473dc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -468,7 +468,8 @@ __git_ps1 ()
 			fi
 		fi
 		if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ] &&
-		   [ -r "$g/refs/stash" ]; then
+		   git rev-parse --verify --quiet refs/stash >/dev/null
+		then
 			s="$"
 		fi
 
-- 
2.1.0.346.ga0367b9