From: Matt McCutchen <matt@mattmccutchen.net>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: git <git@vger.kernel.org>
Subject: Re: update_linked_gitdir writes relative path to .git/worktrees/<id>/gitdir
Date: Tue, 09 Feb 2016 15:05:54 -0500 [thread overview]
Message-ID: <1455048354.2511.199.camel@mattmccutchen.net> (raw)
In-Reply-To: <xmqqziva6e6e.fsf@gitster.mtv.corp.google.com>
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
next prev parent reply other threads:[~2016-02-09 20:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-06 20:12 update_linked_gitdir writes relative path to .git/worktrees/<id>/gitdir Matt McCutchen
2016-02-07 23:56 ` Junio C Hamano
2016-02-08 1:04 ` Matt McCutchen
2016-02-08 4:56 ` Duy Nguyen
2016-02-08 13:56 ` Jeff King
2016-02-08 22:16 ` Junio C Hamano
2016-02-09 20:05 ` Matt McCutchen [this message]
2016-02-09 21:02 ` Junio C Hamano
2016-02-09 20:30 ` Making the "Note from the maintainer" information discoverable Matt McCutchen
2016-02-09 0:34 ` [PATCH] git.txt: encourage bug reporters to test recent versions Matt McCutchen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1455048354.2511.199.camel@mattmccutchen.net \
--to=matt@mattmccutchen.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.