update_linked_gitdir writes relative path to .git/worktrees/<id>/gitdir

update_linked_gitdir writes relative path to .git/worktrees/<id>/gitdir

[Matt McCutchen]

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

worktrees/<id>/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

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

[Junio C Hamano]

Matt McCutchen <matt@mattmccutchen.net> writes:

> I noticed that when update_linked_gitdir chooses to update
> .git/worktrees/<id>/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/<id>/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

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

[Matt McCutchen]

On Sun, 2016-02-07 at 15:56 -0800, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
> 
> > I noticed that when update_linked_gitdir chooses to update
> > .git/worktrees/<id>/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

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

[Duy Nguyen]

On Mon, Feb 8, 2016 at 8:04 AM, Matt McCutchen <matt@mattmccutchen.net> wrote:
> On Sun, 2016-02-07 at 15:56 -0800, Junio C Hamano wrote:
>> Matt McCutchen <matt@mattmccutchen.net> writes:
>>
>> > I noticed that when update_linked_gitdir chooses to update
>> > .git/worktrees/<id>/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

Re: update_linked_gitdir writes relative path to .git/worktrees/<id>/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

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

[Junio C Hamano]

Jeff King <peff@peff.net> 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.

[PATCH] git.txt: encourage bug reporters to test recent versions

[Matt McCutchen]

Specifically, the latest released version or the "next" branch, as
reporters are willing.  This is based on:

  http://marc.info/?l=git&m=145496979420513&w=2

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
 Documentation/git.txt | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index d987ad2..1a148bc 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -1226,7 +1226,11 @@ Reporting Bugs
 
 Report bugs to the Git mailing list <git@vger.kernel.org> where the
 development and maintenance is primarily done.  You do not have to be
-subscribed to the list to send a message there.
+subscribed to the list to send a message there.  You can help us out by
+attempting to reproduce the bug in the latest released version of git,
+or if you're willing to build git from source, the `next` branch.
+Sometimes an attempted fix may be pending in this branch, in which case
+your feedback as to whether the fix worked for you will be appreciated.
 
 SEE ALSO
 --------
-- 
2.5.0

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

[Matt McCutchen]

On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> 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

Making the "Note from the maintainer" information discoverable

[Matt McCutchen]

On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> 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.

While researching an unrelated issue, I stumbled upon
http://marc.info/?l=git&m=142714670111063&w=2, which seems to have even
more valuable information about community processes.  Is there any
interest in making this information discoverable from
https://git-scm.com/community and/or the man pages?  I'm happy to file
an issue or to write a patch that adds a link, but I don't see myself
spending more time on it than that.

Matt

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

[Junio C Hamano]

Matt McCutchen <matt@mattmccutchen.net> 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.