Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Matt McCutchen]

On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote:
> Jeff King  writes:
> 
> > FWIW, as the person who wrote that section, I think that is a good
> > addition.  We do have a link to Simon Tatham's bug-reporting guide, but
> > this is a good place to put project-specific advice.
> > 
> > In addition to "try it on next" you may want to also mention "try it on
> > the latest version of git". That is another frequently given pointer to
> > bug reporters.  Trying "next" is obviously a superset, but I suspect
> > trying a released version may be an easier first step for some people.
> 
> Yes, definitely.
> 
> I agree that testing with the latest released version would
> typically be much easier to end users than building from the source.
> It would reduce the need for "Ah, that's ancient issue, we know it
> was fixed a few releases ago." responses by us; I do not recall many
> of such responses in the recent history on the list, though.
> 
> For the ones who are more into the spirit of helping each other who
> can build from the source to help us even more, checking 'master'
> and finding regressions before it gets too late is a very good
> thing.  Checking 'next' and confirming an upcoming fix is equally
> valuable.

OK, so this testing is an encouragement, not an expectation per se,
even if bug reports may be less likely to get attention without it (I'm
not familiar with the degree to which this may have been the case
recently).  See my revised proposed text here:

https://github.com/git/git-scm.com/pull/676/files

I'll send an analogous patch for the git(1) man page in a moment.

I left a mention of providing feedback on pending fixes but thought it
would be too much to go into the details of how to identify whether
there is a pending fix.  Is this sensible?

Matt


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Junio C Hamano]

Matt McCutchen  writes:

> See my revised proposed text here:
>
> https://github.com/git/git-scm.com/pull/676/files

If somebody says "The ancient version I use has this bug, it does
not reproduce with 'next'", the first thing we would ask would be
"Does it still happen on 'master'?"  Even though it is often clear
from the context and the nature of the bug which topic in 'next' is
likely to have fixed it, if the reporter skipped 'master', we would
end up scratching our head which topic in 'next' that is not
'master' fixed it as a side effect.  And because not everything on
'next' is ready for 'master', we cannot just merge everything ;-)

On the other hand, if somebody says "The ancient version I use has
this bug, it does not reproduce with 'master'", we would likely not
to say anything other than "Oh, that's good for you.".

If somebody says "The ancient version I use has this bug, it still
reproduces with 'master'", then we would ask 'next' to be tried.

For these reasons, I'd say "try the 'master' branch".  Trying 'next'
is highly appreciated, but not without trying 'master'.

> I left a mention of providing feedback on pending fixes but thought it
> would be too much to go into the details of how to identify whether
> there is a pending fix.

What is in 'master' relative to the version of Git the bug reporter
has can be seen by reading through RelNotes of the released versions
since the version reporter used, and RelNotes in the 'master'.
Every time an updated 'master' is pushed out, the changes made by
the topics merged to it are added to update RelNotes.

"What's cooking" report, issued once or twice a week, summarizes the
topics that are still not in 'master' (the description in there are
used to update RelNotes when topics graduate to 'master').

Also "Git Rev News" may cover recent efforts on tackling interesting
bugs.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Jeff King]

On Sun, Feb 07, 2016 at 08:04:38PM -0500, Matt McCutchen wrote:

> > it is very much
> > appreciated when reporting bugs people check if a presumed fix is
> > already cooking in 'next', try it to verify if it really fixes their
> > problem, and send in a "OK fix is good" / "No that does not fix my
> > case"?
> 
> Sorry to waste your time.  This wasn't documented where I looked,
> namely the "Bug Reporting" section on http://git-scm.com/community .
>  Here's a straw-man proposed update to that page:
> 
> https://github.com/mattmccutchen/git-scm.com/compare/master...bug-reporting-next
> 
> If you like it, I will submit it as a pull request.  I can propose a
> similar update to the "REPORTING BUGS" section of the git(1) man page
> if you like.

FWIW, as the person who wrote that section, I think that is a good
addition.  We do have a link to Simon Tatham's bug-reporting guide, but
this is a good place to put project-specific advice.

In addition to "try it on next" you may want to also mention "try it on
the latest version of git". That is another frequently given pointer to
bug reporters.  Trying "next" is obviously a superset, but I suspect
trying a released version may be an easier first step for some people.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Junio C Hamano]

Jeff King  writes:

> FWIW, as the person who wrote that section, I think that is a good
> addition.  We do have a link to Simon Tatham's bug-reporting guide, but
> this is a good place to put project-specific advice.
>
> In addition to "try it on next" you may want to also mention "try it on
> the latest version of git". That is another frequently given pointer to
> bug reporters.  Trying "next" is obviously a superset, but I suspect
> trying a released version may be an easier first step for some people.

Yes, definitely.

I agree that testing with the latest released version would
typically be much easier to end users than building from the source.
It would reduce the need for "Ah, that's ancient issue, we know it
was fixed a few releases ago." responses by us; I do not recall many
of such responses in the recent history on the list, though.

For the ones who are more into the spirit of helping each other who
can build from the source to help us even more, checking 'master'
and finding regressions before it gets too late is a very good
thing.  Checking 'next' and confirming an upcoming fix is equally
valuable.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Matt McCutchen]

I noticed that when update_linked_gitdir chooses to update
.git/worktrees//gitdir, the path it writes is relative, at least
under some circumstances.  This contradicts the gitrepository-layout
man page, which says:

worktrees//gitdir::
A text file containing the absolute path back to the .git file
that points to here.

IIUC, this behavior defeats one of the three safeguards that is
supposed to prevent "git worktree prune" from pruning information for
worktrees that still exist.

A simple script to reproduce:

#!/bin/bash
set -e -x
rm -rf repo worktree2
git init repo
cd repo
touch foo
git add foo
git commit -m 'dummy commit'
git worktree add ../worktree2 -b branch2
cat .git/worktrees/worktree2/gitdir
touch -d '2 days ago' .git/worktrees/worktree2/gitdir
(cd ../worktree2 && git status)
cat .git/worktrees/worktree2/gitdir

Trying this on master as of earlier today (ff4ea60), I get:

[...]
/PATH/REDACTED/worktree2/.git
[...]
.git

Matt


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Junio C Hamano]

Matt McCutchen  writes:

> I noticed that when update_linked_gitdir chooses to update
> .git/worktrees//gitdir, the path it writes is relative, at least
> under some circumstances.  This contradicts the gitrepository-layout
> man page, which says:

Duy, is it safe to say that the fix has already been cooking in
'next' as nd/do-not-move-worktree-manually topic, we are about to
solve this by merging down to 'master', _and_ it is very much
appreciated when reporting bugs people check if a presumed fix is
already cooking in 'next', try it to verify if it really fixes their
problem, and send in a "OK fix is good" / "No that does not fix my
case"?

>
> worktrees//gitdir::
> A text file containing the absolute path back to the .git file
> that points to here.
>
> IIUC, this behavior defeats one of the three safeguards that is
> supposed to prevent "git worktree prune" from pruning information for
> worktrees that still exist.
>
> A simple script to reproduce:
>
> #!/bin/bash
> set -e -x
> rm -rf repo worktree2
> git init repo
> cd repo
> touch foo
> git add foo
> git commit -m 'dummy commit'
> git worktree add ../worktree2 -b branch2
> cat .git/worktrees/worktree2/gitdir
> touch -d '2 days ago' .git/worktrees/worktree2/gitdir
> (cd ../worktree2 && git status)
> cat .git/worktrees/worktree2/gitdir
>
> Trying this on master as of earlier today (ff4ea60), I get:
>
> [...]
> /PATH/REDACTED/worktree2/.git
> [...]
> .git
>
> Matt
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Matt McCutchen]

On Sun, 2016-02-07 at 15:56 -0800, Junio C Hamano wrote:
> Matt McCutchen  writes:
> 
> > I noticed that when update_linked_gitdir chooses to update
> > .git/worktrees//gitdir, the path it writes is relative, at
> > least
> > under some circumstances.  This contradicts the gitrepository-
> > layout
> > man page, which says:
> 
> Duy, is it safe to say that the fix has already been cooking in
> 'next' as nd/do-not-move-worktree-manually topic,

Yes, looks like that topic removes the buggy functionality.

> it is very much
> appreciated when reporting bugs people check if a presumed fix is
> already cooking in 'next', try it to verify if it really fixes their
> problem, and send in a "OK fix is good" / "No that does not fix my
> case"?

Sorry to waste your time.  This wasn't documented where I looked,
namely the "Bug Reporting" section on http://git-scm.com/community .
 Here's a straw-man proposed update to that page:

https://github.com/mattmccutchen/git-scm.com/compare/master...bug-reporting-next

If you like it, I will submit it as a pull request.  I can propose a
similar update to the "REPORTING BUGS" section of the git(1) man page
if you like.

Matt


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

[Duy Nguyen]

On Mon, Feb 8, 2016 at 8:04 AM, Matt McCutchen  wrote:
> On Sun, 2016-02-07 at 15:56 -0800, Junio C Hamano wrote:
>> Matt McCutchen  writes:
>>
>> > I noticed that when update_linked_gitdir chooses to update
>> > .git/worktrees//gitdir, the path it writes is relative, at
>> > least
>> > under some circumstances.  This contradicts the gitrepository-
>> > layout
>> > man page, which says:
>>
>> Duy, is it safe to say that the fix has already been cooking in
>> 'next' as nd/do-not-move-worktree-manually topic,
>
> Yes, looks like that topic removes the buggy functionality.

I'm also pretty sure it's update_linked_gitdir() that writes relative
path. So yes nd/do-not-move-worktree-manually should "fix" it. We
don't have a way to recover broken gitdir files though.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html