git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Sep 2020, #01; Tue, 1)
Date: Wed, 02 Sep 2020 11:10:29 -0700	[thread overview]
Message-ID: <xmqqwo1caw2y.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAPig+cTGspJAGxRu+vqdko1ntkBonVaoStYde3+P5UxPxrCs7g@mail.gmail.com> (Eric Sunshine's message of "Wed, 2 Sep 2020 12:58:50 -0400")

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Wed, Sep 2, 2020 at 12:46 PM Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>> > I wonder if this could be reworded so it's clearer that "git worktree
>> > repair" is a new command, and to mention fixes to "git init
>> > --separate-git-dir". Perhaps like this?
>> >
>> >     "git worktree" gained a "repair" subcommand to help users recover
>> >     from problems arising from factors outside of Git's control.
>> >     Also, "git init --separate-git-dir" no longer corrupts
>> >     administrative data related to linked worktrees.
>>
>> OK that reads much better.
>>
>> -from problems arising from factors outside of Git's control.
>> +after moving the worktrees manually without telling Git.
>>
>> The latter is slightly shorter; does the "repair" help situations
>> other than that, or is the above cover all the "factors outside" out
>> control?
>
> The current implementation also helps out when the main worktree (or
> bare repository) is moved.

That is why I wrote "secondary worktrees" initially and then dropped
"secondary" from the description ;-)

> However, in the "git worktree repair" documentation, I intentionally
> avoided nailing down precisely the problems it repairs, instead
> leaving it open-ended since it may learn more repairs in the future.
> (The documentation is careful to say that it repairs "administrative
> files", and then talks about the currently-implemented repairs as
> _examples_ of what it might repair, without locking it into only those
> repairs.)
>
> I think the same generality of description can apply to the blurb
> here, as well. We don't necessarily need to give precise detail in
> this blurb -- the reader can learn the details by consulting the
> documentation.

Well given that the primary reason why I add these blub in What's
cooking is to draft the release notes for upcoming release, my
preference is to give "we help these cases" than giving overly large
promises to our users.

So...

  reply	other threads:[~2020-09-02 18:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01 21:28 What's cooking in git.git (Sep 2020, #01; Tue, 1) Junio C Hamano
2020-09-01 21:43 ` Eric Sunshine
2020-09-02 16:45   ` Junio C Hamano
2020-09-02 16:58     ` Eric Sunshine
2020-09-02 18:10       ` Junio C Hamano [this message]
2020-09-02 18:17         ` Eric Sunshine
2020-09-02 19:12           ` Junio C Hamano

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=xmqqwo1caw2y.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=sunshine@sunshineco.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).