Re: [PATCH 3/3] Make clear_commit_marks() clean harder

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:

>> If we didn't mark them, then clearing them would be a no-op, so nobody 
>> really cares.
>
> My point being: if we try to clear commits we could not have possibly 
> marked, because they were not yet parsed, this is wrong.

While you say above is correct, object.parsed bit does not give
you enough information to decide if we could not have possibly
marked or not, because it is perfectly valid to mark a commit
that we have not parsed.

As Linus said in this thread already (I am rephrasing):

 - When you have a commit object, which is parsed, you can tell
   who its parents are; more importantly, at that point you have
   access to the commit objects for the parents already, but they
   may not have been parsed.

 - If you can make a decision whether the parents of a commit
   should be marked or not solely by looking at the commit, you
   are allowed to do so before parsing these parents.  The
   commit you look at to make that decision has to be parsed for
   you to know who the parents are, though.

Marking unparsed objects is a valid operation because even
unparsed objects have flags field that is retained when they are
later lazily parsed.

Right now, in the inner loop of the main loop of merge_base()
code, we parse each parent and insert it into the &list, but
instead we could parse commit (if not parsed yet) just before
taking its parents list in the outer loop.  That way we would
parse the parents lazily and will have commits marked but still
not parsed.



-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]