All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: <rsbecker@nexbridge.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	<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, 03 Nov 2019 16:46:08 +0100	[thread overview]
Message-ID: <86bltthsjj.fsf@gmail.com> (raw)
In-Reply-To: <001501d591ba$1d190060$574b0120$@nexbridge.com> (rsbecker@nexbridge.com's message of "Sat, 2 Nov 2019 16:14:14 -0400")

<rsbecker@nexbridge.com> writes:

> On November 2, 2019 3:26 PM, brian m. carlson wrote:
>> It is quite common for users to want to ignore the changes to a file that Git
>> tracks.  Common scenarios for this case are IDE settings and configuration
>> files, which should generally not be tracked and possibly generated from
>> tracked files using a templating mechanism.
>> 
>> However, users learn about the assume-unchanged and skip-worktree bits
>> and try to use them to do this anyway.  This is problematic, because when
>> these bits are set, many operations behave as the user expects, but they
>> usually do not help when git checkout needs to replace a file.
[...]
> Just noodling about a potential solution. If we assume the use case that
> files are modified by an IDE that have no real relevance, but should not
> interfere with other git operations including checkout...
>
> What if we introduce something like .gitignore.changes, with the same syntax
> as .gitignore. The difference is files listed in this file will not show in
> `git status` (or could show as "changes ignored" with an option to enable
> that. The only way to have the changes considered would be `git add -f`, so
> `git add .` and `git commit -a` would not pick up the changes.
[...]

I think it would be better and easier to add new attribute and use
.gitattributes instead of a new .gitignore.changes (and its
per-repository, per-user and system-wide version).

> If this idea seems reasonable, it might make a nice small project for
> someone, possibly me, if I could unentangle from my current hellish $DAYJOB
> project.

I wish you luck.

The fact that it was nod done yet may mean that there are some annoying
corner-cases in the concept, or that it is not commonly useful... or
maybe that is the problem that needs reframing.

Best,
-- 
Jakub Narębski

  reply	other threads:[~2019-11-03 15:46 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 [this message]
2019-11-03 15:04   ` Jakub Narebski
2019-11-03 18:59     ` brian m. carlson
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=86bltthsjj.fsf@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=rsbecker@nexbridge.com \
    --cc=sandals@crustytoothpaste.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.