All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelius Weig <cornelius.weig@tngtech.com>
To: Jeff King <peff@peff.net>
Cc: gitster@pobox.com, git@vger.kernel.org, novalis@novalis.org,
	pclouds@gmail.com
Subject: Re: [PATCH] refs: add option core.logAllRefUpdates = always
Date: Thu, 26 Jan 2017 15:06:40 +0100	[thread overview]
Message-ID: <4faf836a-40b6-da9a-877a-3b2ce7c863df@tngtech.com> (raw)
In-Reply-To: <20170126033547.7bszipvkpi2jb4ad@sigill.intra.peff.net>

Hi Peff,

 thanks for your thoughts.

> I tried to read this patch with fresh eyes. But given the history, you
> may take my review with a grain of salt. :)

Does it mean another reviewer is needed?

> I don't think my original had tests for this, but it might be worth
> adding a test for this last bit (i.e., that an update of ORIG_HEAD does
> not write a reflog when logallrefupdates is set to "always").

Good point. I blindly copied your commit message without thinking too
much about it.

> I guess the backtick fixups came from my original. It might be easier to
> see the change if they were pulled into their own patch, but it's
> probably not that big a deal.

If it's best practice to break out such changes, I'll revise it.

>> @@ -2835,8 +2835,8 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
>>  {
>>  	int logfd, result, oflags = O_APPEND | O_WRONLY;
>>  
>> -	if (log_all_ref_updates < 0)
>> -		log_all_ref_updates = !is_bare_repository();
>> +	if (log_all_ref_updates == LOG_REFS_UNSET)
>> +		log_all_ref_updates = is_bare_repository() ? LOG_REFS_NONE : LOG_REFS_NORMAL;
> 
> This hunk is new, I think. The enum values are set in such a way that
> the original code would have continued to work, but I think using the
> symbolic names is an improvement.

Yes it's new.

> I assume you grepped for log_all_ref_updates to find this. I see only
> one spot that now doesn't use the symbolic names. In builtin/checkout.c,
> update_refs_for_switch() checks:
> 
>   if (opts->new_branch_log && !log_all_ref_updates)
> 
> That looks buggy, as it would treat LOG_REFS_NORMAL and LOG_REFS_UNSET
> the same, and I do not see us resolving the UNSET case to a true/false
> value. But I don't think the bug is new in your patch; the default value
> was "-1" already.
>
> I doubt it can be triggered in practice, because either:
> 
>   - the config value is set in the config file, and we pick up that
>     value, whether it's "true" or "false"
> 
>   - it's unset, in which case our default would be to enable reflogs in
>     a non-bare repo. And since git-checkout would refuse to run in a
>     bare repo, we must be non-bare, and thus enabling reflogs does the
>     right thing.

That far I can follow.

> But it works quite by accident. I wonder if we should this
> "is_bare_repository" check into a function that can be called instead of
> accessing log_all_ref_updates() directly.

Are you saying that we should move the `!log_all_ref_updates` check into
its own function where we should also check `is_bare_repository`? I
don't see that this would win much, because as you said: checkouts in a
bare repo are forbidden anyway.

Other than that, I guess it should better read `log_all_ref_update !=
LOG_REFS_NONE` instead of `!log_all_ref_updates`.


>> +test_expect_success 'update-ref does not create reflog with --no-create-reflog if core.logAllRefUpdates=always' '
> 
> This test title is _really_ long, and will wrap in the output on
> reasonable-sized terminals. Maybe '--no-create-reflog overrides
> core.logAllRefUpdates=always' would be shorter?

Yes, I agree.

>> +test_expect_success 'stdin does not create reflog when core.logAllRefUpdates=true' '
> 
> I don't mind these extra stdin tests, but IMHO they are just redundant.
> The "--stdin --create-reflog" one makes sure the option is propagated
> down via the --stdin machinery. But we know the config option is handled
> at a low level anyway.
> 
> I guess it depends on how black-box we want the testing to be. It just
> seems unlikely for a regression to be found here and not in the tests
> above.

Since these other stdin tests were around, I added this variant. But
you're right: this test breaks along with the other and doesn't add add
more safety. I'll remove it.

However, I realized that I have not written tests about ref updates in a
bare repository. Do you think it's worthwile?

Cheers,
  Cornelius


  reply	other threads:[~2017-01-26 14:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25  0:19 [PATCH] tag: add tag.createReflog option cornelius.weig
2017-01-25  5:06 ` Pranit Bauva
2017-01-25 18:00 ` Jeff King
2017-01-25 18:10   ` Junio C Hamano
2017-01-25 21:21   ` Cornelius Weig
2017-01-25 21:33     ` Jeff King
2017-01-25 21:43       ` Junio C Hamano
2017-01-25 22:56         ` Junio C Hamano
2017-01-25 23:40           ` Cornelius Weig
2017-01-26  1:16       ` [PATCH] refs: add option core.logAllRefUpdates = always cornelius.weig
2017-01-26  1:16         ` cornelius.weig
2017-01-26  3:35           ` Jeff King
2017-01-26 14:06             ` Cornelius Weig [this message]
2017-01-26 14:46               ` Jeff King
2017-01-26 22:31             ` [PATCH v2 1/3] config: add markup to core.logAllRefUpdates doc cornelius.weig
2017-01-26 22:31               ` [PATCH v2 2/3] refs: add option core.logAllRefUpdates = always cornelius.weig
2017-01-26 23:39                 ` Junio C Hamano
2017-01-26 22:31               ` [PATCH v2 3/3] update-ref: add test cases for bare repository cornelius.weig
2017-01-26 23:41                 ` Junio C Hamano
2017-01-26 23:24               ` [PATCH v2 1/3] config: add markup to core.logAllRefUpdates doc Junio C Hamano
2017-01-27 10:09                 ` [PATCH v3 " cornelius.weig
2017-01-27 10:09                   ` [PATCH v3 2/3] refs: add option core.logAllRefUpdates = always cornelius.weig
2017-01-30 21:58                     ` Junio C Hamano
2017-01-30 22:57                       ` Junio C Hamano
2017-01-31 13:16                         ` Cornelius Weig
2017-01-31 17:11                           ` Junio C Hamano
2017-01-30 23:37                       ` Jeff King
2017-01-31 14:00                         ` Cornelius Weig
2017-01-31 18:21                           ` Jeff King
2017-01-31 17:08                         ` Junio C Hamano
2017-01-31 20:28                           ` Cornelius Weig
2017-01-31 22:02                             ` Junio C Hamano
2017-01-27 10:09                   ` [PATCH v3 3/3] update-ref: add test cases for bare repository cornelius.weig

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=4faf836a-40b6-da9a-877a-3b2ce7c863df@tngtech.com \
    --to=cornelius.weig@tngtech.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=novalis@novalis.org \
    --cc=pclouds@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 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.