From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] branch: do not fail a no-op --edit-desc
Date: Wed, 28 Sep 2022 16:40:58 -0700 [thread overview]
Message-ID: <xmqq1qrvqd85.fsf@gitster.g> (raw)
In-Reply-To: 1faa5c44-1a59-7a60-d29b-c4d4e8d0bf92@gmail.com
Rubén Justo <rjusto@gmail.com> writes:
> On 28/9/22 21:15, Junio C Hamano wrote:
>> In a repository on a branch without branch description, try running
>
> On a branch without description, ..
>
>> The simpler solution of course introduces TOCTOU, but you are
>
> Nice to introduce a term that can generate curiosity.
>
>> fooling yourself in your own repository. Not overwriting the branch
>> description on the same branch you added in another window, while
>> you had this other editor open, may even be a feature ;-)
>
> Not overwriting if there was no description in the first place, otherwise
> will clear.. ¿?
Time-of-check-time-of-use is an established term to describe classes
of "bugs" that arises if you do
1. check if something is in one state
2. perform an action to change that something's state
in separate steps, expecting that the result of the check done in
the earlier step is unchanged. A "bug" is what happens in the
second step, when that expectation is violated.
In our case, in the "check" stage, we set "exists" based on whether
we had the branch.<current>.description configuration variable.
Then later, we use that "exists" condition and expect that nobody
messed with the state of the variable in the meantime.
An example of what happens in the updated code is
1. We saw the description did not exist.
2. The user told us to abort editing/setting the description. We
assume description does not still exist, and skip the call to
git_config_set().
Now, what if you added a description for the branch between these
two points in time, perhaps from another window? Because 2. above
bases its decision not to bother calling git_config_set() (because
!buf.len and !exists are both true), the description you set from
the other window will be kept. That is the comment "feature ;-)"
refers to.
Of course, this can bite the other way. If we did have a
description, and the user told us to remove it by giving an empty
editor result, then
1. We see that the description does exist.
2. We see the buf.len == 0. Because we think the description
exists and the user asks to remove it, we call git_config_set()
will NULL as the value to attempt to remove the variable.
What if you removed the description for the branch between these two
points in time from another window? We end up triggering the exact
bug that comes from the fact that we use git_config_set(), not the
_gently variant, because we are now removing what does not exist.
But at that point, the user deserves it and the problem falls
squarely into "doctor, it hurts when I twist my arm in this unusual
way! -- well, don't do it then", I would think.
Thinking what happens in the remaining two combinations is left as
an exercise to readers ;-).
next prev parent reply other threads:[~2022-09-28 23:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 19:15 [PATCH] branch: do not fail a no-op --edit-desc Junio C Hamano
2022-09-28 23:04 ` Rubén Justo
2022-09-28 23:40 ` Junio C Hamano [this message]
2022-09-29 21:49 ` Rubén Justo
2022-09-29 22:26 ` Junio C Hamano
2022-09-30 22:59 ` Rubén Justo
2022-10-01 9:15 ` Rubén Justo
2022-09-30 1:27 ` [PATCH v2] " Junio C Hamano
2022-09-30 10:21 ` Ævar Arnfjörð Bjarmason
2022-09-30 17:01 ` Junio C Hamano
2022-09-30 17:58 ` Ævar Arnfjörð Bjarmason
2022-09-30 18:13 ` Junio C Hamano
2022-09-30 18:06 ` [PATCH v3] " 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=xmqq1qrvqd85.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=rjusto@gmail.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).