git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kirill Smelkov <kirr@navytux.spb.ru>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 7/8] combine-diff: Fast changed-to-all-parents paths scanning
Date: Wed, 5 Feb 2014 23:14:27 +0400	[thread overview]
Message-ID: <20140205191427.GA3923@mini.zxlink> (raw)
In-Reply-To: <xmqqfvnx5umg.fsf@gitster.dls.corp.google.com>

On Wed, Feb 05, 2014 at 09:36:55AM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@mns.spb.ru> writes:
> 
> > Only, before I clean things up, I'd like to ask - would the following
> > patch be accepted
> >
> > ---- 8< ---
> > diff --git a/tree-walk.c b/tree-walk.c
> > index 79dba1d..4dc86c7 100644
> > --- a/tree-walk.c
> > +++ b/tree-walk.c
> > @@ -37,7 +37,7 @@ static void decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned
> >  
> >  	/* Initialize the descriptor entry */
> >  	desc->entry.path = path;
> > -	desc->entry.mode = mode;
> > +	desc->entry.mode = canon_mode(mode);
> >  	desc->entry.sha1 = (const unsigned char *)(path + len);
> >  }
> >  
> > diff --git a/tree-walk.h b/tree-walk.h
> > index ae04b64..ae7fb3a 100644
> > --- a/tree-walk.h
> > +++ b/tree-walk.h
> > @@ -16,7 +16,7 @@ struct tree_desc {
> >  static inline const unsigned char *tree_entry_extract(struct tree_desc *desc, const char **pathp, unsigned int *modep)
> >  {
> >  	*pathp = desc->entry.path;
> > -	*modep = canon_mode(desc->entry.mode);
> > +	*modep = desc->entry.mode;
> >  	return desc->entry.sha1;
> >  }
> > ---- 8< ---
> >  
> > ?
> 
> Doesn't desc point into and walks over the data we read from the
> tree object directly?
> 
> We try to keep (tree|commit)->buffer intact and that is done pretty
> deliberately.  While you are walking a tree or parsing a commit,
> somebody else, perhaps called indirectly by a helper function you
> call, may call lookup_object() for the same object, get the copy
> that has already been read and start using it.  This kind of change
> will introduce bugs that are hard to debug unless it is done very
> carefully (e.g. starting from making tree.buffer into a const pointer
> and propagating constness throughout the system), which might not be
> worth the pain.

I agree object data should be immutable for good. The only thing I'm talking
about here is mode, which is parsed from a tree buffer and is stored in
separate field:

        ---- 8< ---- tree-walk.h
        struct name_entry {
                const unsigned char *sha1;
                const char *path;
                unsigned int mode;              <---
        };

        struct tree_desc {
                const void *buffer;
                struct name_entry entry;
                unsigned int size;
        };

        ---- 8< ---- tree-walk.c
        const char *get_mode(const char *str, unsigned int *modep)
        { ... }     /* parses symbolic mode from tree buffer to uint */

        void decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned long size)
        {
                const char *path;
                unsigned int mode, len;

                ...
                path = get_mode(buf, &mode);

                /* Initialize the descriptor entry */
                desc->entry.path = path;
                desc->entry.mode = mode;        <---
                desc->entry.sha1 = (const unsigned char *)(path + len);


so we are not talking about modifying object buffers here. All I'm
asking is about canonicalizing _already_ parsed and copied mode on the
fly.

Does that change anything?


Sorry, if I'm maybe misunderstanding something, and thanks,
Kirill

  reply	other threads:[~2014-02-05 19:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 12:47 [PATCH 0/8] `log -c` speedup (part 2) Kirill Smelkov
2014-02-03 12:47 ` [PATCH 1/8] fixup! combine_diff: simplify intersect_paths() further Kirill Smelkov
2014-02-03 19:40   ` Junio C Hamano
2014-02-03 12:47 ` [PATCH 2/8] tests: add checking that combine-diff emits only correct paths Kirill Smelkov
2014-02-03 23:10   ` Junio C Hamano
2014-02-05 10:36     ` Kirill Smelkov
2014-02-03 12:47 ` [PATCH 3/8] tree-diff: no need to manually verify that there is no mode change for a path Kirill Smelkov
2014-02-03 23:12   ` Junio C Hamano
2014-02-03 12:47 ` [PATCH 4/8] tree-diff: no need to pass match to skip_uninteresting() Kirill Smelkov
2014-02-03 12:47 ` [PATCH 5/8] combine-diff: move show_log_first logic/action out of paths scanning Kirill Smelkov
2014-02-03 23:21   ` Junio C Hamano
2014-02-03 12:47 ` [PATCH 6/8] combine-diff: Move changed-paths scanning logic into its own function Kirill Smelkov
2014-02-03 12:47 ` [PATCH 7/8] combine-diff: Fast changed-to-all-parents paths scanning Kirill Smelkov
2014-02-03 23:26   ` Junio C Hamano
2014-02-03 23:39     ` Junio C Hamano
2014-02-04 16:34       ` Kirill Smelkov
2014-02-04 18:37         ` Junio C Hamano
2014-02-05 16:51           ` Kirill Smelkov
2014-02-05 17:36             ` Junio C Hamano
2014-02-05 19:14               ` Kirill Smelkov [this message]
2014-02-05 19:42                 ` Junio C Hamano
2014-02-05 20:22                   ` Kirill Smelkov
2014-02-05 22:58                     ` Junio C Hamano
2014-02-06 16:22                       ` Kirill Smelkov
2014-02-04  0:00   ` Junio C Hamano
2014-02-03 12:47 ` [PATCH 8/8] combine-diff: bail out early, if num_paths=0 Kirill Smelkov

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=20140205191427.GA3923@mini.zxlink \
    --to=kirr@navytux.spb.ru \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).