git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files
Date: Sun, 3 Nov 2019 18:59:08 +0000	[thread overview]
Message-ID: <20191103185908.GA32531@camp.crustytoothpaste.net> (raw)
In-Reply-To: <86h83lhugj.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

On 2019-11-03 at 15:04:44, Jakub Narebski wrote:
> Why the change between formatting '``assume unchanged''' (with double
> quotes and space separated) and 'skip-worktree' (without quotes, and
> kebab-cased)?  In the commit message you write about assume-unchanged
> and skip-worktree.
> 
> I guess that follows the inconsistency in git-update-index(1) headers,
> namely we have
> 
>   USING ``ASSUME UNCHANGED'' BIT
>   ------------------------------
> 
> but
> 
>   SKIP-WORKTREE BIT
>   -----------------
> 
> This incconsistency is much more viible when both names are on the same
> line, however.

Yeah, I can change them to make them consistent.  I did preserve the
existing formatting for both, as you mentioned.

> I'm not sure if it is a place for it, but the proposed text treats
> assume-unchanged and skip-worktree as similarly unsuited for intended
> purpose.  However, their failure modes are different: (ab)using the
> assume-unchanged for "ignore changed to tracked files" may lead to data
> loss (as changes are overwritten), while with skip-worktree the trouble
> is that some operations that should succeed (like unstashing) are
> unnecessarily blocked - but no data loss.

I agree the failure modes can be different, but from my experience there
are people who have seen checkout failures with both bits set
independently.  I'm not exactly sure what those cases are, but folks do
see them on Stack Overflow quite frequently.

Even if there is a difference in failure modes, I'd rather encourage
people to just not use this mechanism rather than explain why or in
which cases it won't do what you want.

> I would really like to see a simple example of such template, so that
> even people who are unfamiliar with Ruby's ERB can think of equivalent
> solution for their language or toolchain of choice.

I hesitated to mention ERB, but I wasn't sure that folks would know what
we meant by a "templating mechanism".  The reason I had chosen to
mention it is that someone could search for "Ruby ERB" and find out what
it looked like and then look for an option in their own language.

My concern with adding such a template is that an example will likely
grow this section quite a bit, and it's meant as a short aside to help
people avoid making a common mistake and guide them to a proper solution
rather than a comprehensive howto.  I'm planning on adding a FAQ
document in the future that covers a lot of these issues in more detail
and helps folks figure out solutions to common problems, and I'd prefer
to explain this more in depth there.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

  reply	other threads:[~2019-11-03 18:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-02 19:26 [PATCH v3 0/4] Documentation for common user misconceptions brian m. carlson
2019-11-02 19:26 ` [PATCH v3 1/4] doc: move author and committer information to git-commit(1) brian m. carlson
2019-11-03 11:13   ` Jakub Narebski
2019-11-04 22:18   ` Jeff King
2019-11-06  1:55     ` Junio C Hamano
2019-11-02 19:26 ` [PATCH v3 2/4] doc: provide guidance on user.name format brian m. carlson
2019-11-03 13:13   ` Jakub Narebski
2019-11-03 19:23     ` brian m. carlson
2019-11-02 19:26 ` [PATCH v3 3/4] doc: dissuade users from trying to ignore tracked files brian m. carlson
2019-11-02 20:14   ` rsbecker
2019-11-03 15:46     ` Jakub Narebski
2019-11-03 15:04   ` Jakub Narebski
2019-11-03 18:59     ` brian m. carlson [this message]
2019-11-03 19:40       ` Jakub Narebski
2019-11-03 21:46         ` brian m. carlson
2019-11-05  0:21           ` Jakub Narebski
2019-11-04 22:24       ` Jeff King
2019-11-04 23:52         ` brian m. carlson
2019-11-02 19:26 ` [PATCH v3 4/4] docs: mention when increasing http.postBuffer is valuable brian m. carlson
2019-11-04 22:26 ` [PATCH v3 0/4] Documentation for common user misconceptions Jeff King
2019-11-06  1:58   ` Junio C Hamano
2019-11-06  2:19     ` brian m. carlson
2019-11-06  3:15       ` Junio C Hamano
2020-01-16 21:08 ` Emily Shaffer
2020-01-16 23:35   ` brian m. carlson

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=20191103185908.GA32531@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.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 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).