git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Miriam R." <mirucam@gmail.com>
Cc: git <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH 02/10] bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C
Date: Thu, 27 Feb 2020 08:41:55 -0800	[thread overview]
Message-ID: <xmqqwo88f0do.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAN7CjDDwgR=y8gyYmDzmuTW3AKvb1N=EdCtH-8Tr7T=b6cG5gQ@mail.gmail.com> (Miriam R.'s message of "Thu, 27 Feb 2020 16:34:46 +0100")

"Miriam R." <mirucam@gmail.com> writes:

>> It would be surprising if this code were correct.  It may be that it
>> happens to (appear to) work because parents of the commit hasn't
>> been painted and calling the helper only clears the mark from the
>> commit (so we won't see repeated "painting down to the root commit")
>> in which case this might be an extremely expensive looking variant
>> of
>>
>>         commit->object.flags &= ~ALL_REV_FLAGS;
>>
>> that only confuses the readers.
>>
>> Even then, I think by clearing bits like SEEN from commit, it breaks
>> the revision traversal machinery---for example, doesn't this mean
>> that the commit we just processed can be re-visited by
>> get_revision() without deduping in a history with forks and merges?
>>
>> Has this been shown to any of your mentors before sending it to the
>> list?
>
> Adding clear_commit_marks() was a suggestion of a previous review of this patch:
> https://public-inbox.org/git/nycvar.QRO.7.76.6.2001301619340.46@tvgsbejvaqbjf.bet/
>
> And of course, my mentor always reviews my patch series before sending.

OK, I just didn't know how you and your mentors work.  Some leave
their door open for mentees and help them when asked but otherwise
act as an ordinary reviewer who somehow prioritises reviewing the
work by their mentees.  So your mentors may be a better source of
information why this piece of code, which I still do not know how it
could be correct, is supposed to work.  Good.

After reading the above URL, I think you may have misread the
suggestion you were given.  Resetting using clear_commit_marks() may
be necessary, but you do so when you finished walking so that you
can do unrelated revision walk later.  For that, you clear the flag
bits after the while() loop that asks get_revision() to yield
commits are done, using the initial set of commits that you used to
start iteration.

That is how bisect.c::check_ancestors() work, that is

 - it initializes a rev_info 'revs' from an array of commit rev[]

 - it lets bisect_common() use the 'revs', which is allowed to
   smudge the flag bits of commit objects.

 - it uses clear_commit_marks_many() to clear the flags of the
   commits whose flag bits may have been smudged and their
   ancestors, recursively.  In order to use as the starting points,
   the original array of commit rev[] that started the revision
   traversal is used.

  reply	other threads:[~2020-02-27 16:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 10:14 [Outreachy][PATCH 00/10] Finish converting git bisect to C part 2 Miriam Rubio
2020-02-26 10:14 ` [PATCH 01/10] bisect--helper: introduce new `write_in_file()` function Miriam Rubio
2020-02-26 19:06   ` Junio C Hamano
2020-02-26 10:14 ` [PATCH 02/10] bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C Miriam Rubio
2020-02-26 19:34   ` Junio C Hamano
2020-02-27 15:34     ` Miriam R.
2020-02-27 16:41       ` Junio C Hamano [this message]
2020-03-06 18:19         ` Miriam R.
2020-03-06 19:05           ` Junio C Hamano
2020-03-11 18:58             ` Christian Couder
2020-02-26 10:14 ` [PATCH 03/10] bisect--helper: finish porting `bisect_start()` to C Miriam Rubio
2020-02-26 10:14 ` [PATCH 04/10] bisect--helper: retire `--bisect-clean-state` subcommand Miriam Rubio
2020-02-26 10:14 ` [PATCH 05/10] bisect--helper: retire `--next-all` subcommand Miriam Rubio
2020-02-26 10:14 ` [PATCH 06/10] bisect--helper: reimplement `bisect_autostart` shell function in C Miriam Rubio
2020-02-27 21:40   ` Johannes Schindelin
2020-02-26 10:14 ` [PATCH 07/10] bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions " Miriam Rubio
2020-02-27 23:12   ` Johannes Schindelin
2020-02-26 10:14 ` [PATCH 08/10] bisect--helper: retire `--check-expected-revs` subcommand Miriam Rubio
2020-02-26 10:14 ` [PATCH 09/10] bisect--helper: retire `--write-terms` subcommand Miriam Rubio
2020-02-26 10:14 ` [PATCH 10/10] bisect--helper: retire `--bisect-autostart` subcommand Miriam Rubio

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

  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 \
    --in-reply-to=xmqqwo88f0do.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=mirucam@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).