git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Hilco Wijbenga <hilco.wijbenga@gmail.com>,
	git@vger.kernel.org, Aleem Zaki <aleemzaki@gmail.com>
Subject: Re: .gitignore is not enough
Date: Thu, 03 Aug 2023 14:53:18 -0700	[thread overview]
Message-ID: <xmqqsf8z3i9d.fsf@gitster.g> (raw)
In-Reply-To: <e453bee1-942f-ea9a-9c50-3cf5d0f9e936@kdbg.org> (Johannes Sixt's message of "Thu, 3 Aug 2023 22:27:39 +0200")

Johannes Sixt <j6t@kdbg.org> writes:

> Am 03.08.23 um 19:49 schrieb Hilco Wijbenga:
>> The promise part, I was aware of. In that sense, my wording was too
>> strong. It's more like "just trust me".
>> 
>> So the "you will get what you deserve" makes sense. If the
>> original/default/skeleton changes for some reason, your local changes
>> will just get overwritten. Nothing surprising there.
>> 
>> But in what scenario would Git "commit them nevertheless"? That one is
>> a surprise to me and is a bit worrisome.
>
> I don't know. In my book it is called "undefined behavior". Anything can
> happen, including things that I did not enumerate.

Exactly.

"Is commit affected?" and "Can we guarantee that operation X is not
affected?" are meaningless questions, as our implementation is not
frozen and we reserve the right to take any valid optimization
oppoertunities as long as correctness is not violated.

The assume unchanged bit allows Git to take advantage of the promise
the user has made and choose whichever is more efficient and/or
convenient to use between the file in the working tree and the blob
object for a given path when that bit is set.  When you expect an
existing blob object to be used (e.g. the one registered in the
index), in _any_ operation (which is defined now or will be invented
in the future), Git is allowed to instead use the contents of the
corresponding working tree file.  Or vice versa.

Perhaps you may be creating an archive of some format out of the
tree of HEAD, and may expect that local changes in the working tree
would not have any effect in the result.  But instead of having to
reconstruct the contents of a blob object known to be at path
"README" in the tree by uncompressing the base object and then
repeatedly applying delta data read from different parts of a
packfile, it may be easier/faster to open/read the file in the
working tree.  And if there is such a promise from the user that the
contents of the file will be kept the same as what was in the index
and the HEAD, Git is allowed to do so.  If the contents of the file
was different from the blob, the resulting archive will not be an
archive of the tree of HEAD, but that is "what you deserve".


  reply	other threads:[~2023-08-03 21:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03  3:23 .gitignore is not enough Aleem Zaki
2023-08-03  5:35 ` Hilco Wijbenga
2023-08-03 17:17   ` Johannes Sixt
2023-08-03 17:49     ` Hilco Wijbenga
2023-08-03 20:27       ` Johannes Sixt
2023-08-03 21:53         ` Junio C Hamano [this message]
2023-08-03 21:38     ` brian m. carlson
2023-08-03 21:47       ` Aleem Zaki

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=xmqqsf8z3i9d.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=aleemzaki@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=hilco.wijbenga@gmail.com \
    --cc=j6t@kdbg.org \
    /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).