From: Andrej Shadura <firstname.lastname@example.org>
To: "brian m. carlson" <email@example.com>,
Andrej Shadura via GitGitGadget <firstname.lastname@example.org>,
Subject: Re: [PATCH 0/2] Add --no-filters option to git-add
Date: Sat, 20 Feb 2021 09:06:10 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 19/02/2021 23:36, brian m. carlson wrote:
> On 2021-02-19 at 18:12:11, Andrej Shadura via GitGitGadget wrote:
>> It is possible for a user to disable attribute-based filtering when
>> committing by doing one of the following:
>> * Create .git/info/attributes unapplying all possible transforming
>> * Use git hash-object and git update-index to stage files manually.
>> Doing the former requires keeping an up-to-date list of all attributes which
>> can transform files when committing or checking out. Doing the latter is
>> difficult, error-prone and slow when done from scripts.
>> Instead, similarly to git hash-object, --no-filter can be added to git add
>> to enable temporarily disabling filtering in an easy to use way.
> I'm interested in your use cases here. While I agree that this is an
> interesting feature, it also means that practically, a user who checks
> out a file that's added this way may find that git status marks it as
> perpetually modified until a properly cleaned version is committed.
> Moreover, even "git reset --hard" won't fix this situation.
> We see this problem extremely frequently with Git LFS where people
> change the .gitattributes file but don't run "git add --renormalize ."
> and then end up with this problem. However, it's not limited to Git LFS
> in particular; anything that uses filters, working tree encodings, or
> end of line attributes can be affected.
> So I think that while this might be a useful escape hatch for users, I
> definitely want to see a compelling rationale for it and a big warning
> in the documentation and an update to the relevant entry in the Git FAQ
> before we accept such a patch.
My use case here is mostly non-interactive use in scripts creating Git
trees that need to exactly correspond to a working directory regardless
of whether or not they have any .gitattributes files.
For example, for git-buildpackage or dgit, which facilitate Git
workflows with Debian packages, want to ensure the contents of the
packages can be exactly reproduced, which is difficult if the upstream’s
tarball has .gitattributes. It is possible to "defuse" the attributes as
demonstrated above, but this will break if the user modifies the
.git/i/a file *or* if Git adds more attribute-based conversions. This is
what dgit currently does, and this is what git-buildpackage will soon do
Of course, this patch set only addresses staging files. While working on
a patch to git-buildpackage to reproducibly import the contents of
tarballs, I realised that the only realistic way seem to do that is to
use hash-object + update-index manually, which is likely to come with a
performance drop compared to git add (which is what gbp currently uses).
A workaround might be to use dulwich (which would allow to do
hash-object without fork/exec) or perhaps GitPython (which I haven’t
really looked into), or maybe to use git fast-import, but all of these
alternatives are quite complex and don’t guarantee the same performance.
Adding a new option to git add allows to keep the performance without
having to ensure attributes are set to the right values. The attributes
will likely have to be adjusted anyway for user’s convenience, but at
least if they modify them afterwards, the tools won’t break.
next prev parent reply other threads:[~2021-02-20 8:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 18:12 [PATCH 0/2] Add --no-filters option to git-add Andrej Shadura via GitGitGadget
2021-02-19 18:12 ` [PATCH 1/2] add: add option --no-filters to disable attribute-based filtering Andrej Shadura via GitGitGadget
2021-02-19 18:12 ` [PATCH 2/2] hash-object: use the new HASH_RAW flag instead of setting path to NULL Andrej Shadura via GitGitGadget
2021-02-19 22:36 ` [PATCH 0/2] Add --no-filters option to git-add brian m. carlson
2021-02-20 8:06 ` Andrej Shadura [this message]
2021-02-20 9:30 ` Andrej Shadura
2021-02-20 14:10 ` brian m. carlson
2021-02-20 17:07 ` [PATCH v2 " Andrej Shadura via GitGitGadget
2021-02-20 17:07 ` [PATCH v2 1/2] add: add option --no-filters to disable attribute-based filtering Andrej Shadura via GitGitGadget
2021-02-20 17:07 ` [PATCH v2 2/2] hash-object: use the new HASH_RAW flag instead of setting path to NULL Andrej Shadura via GitGitGadget
2021-02-20 21:34 ` [PATCH v2 0/2] Add --no-filters option to git-add Junio C Hamano
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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 read-only IMAP folder(s) and NNTP newsgroup(s).