git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <chriscool@tuxfamily.org>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH RFC] parse_object: pass on the original sha1, not the replaced one
Date: Sat, 14 Aug 2010 04:03:32 +0200	[thread overview]
Message-ID: <201008140403.33164.chriscool@tuxfamily.org> (raw)
In-Reply-To: <AANLkTinmJ0=VxFAaCXNjB2WAiPYHq3jXmRnzVoEiw_-f@mail.gmail.com>

On Friday 13 August 2010 11:02:40 Nguyen Thai Ngoc Duy wrote:
> On Fri, Aug 13, 2010 at 1:59 PM, Christian Couder
> 
> <chriscool@tuxfamily.org> wrote:
> > On Saturday 07 August 2010 06:03:05 Nguyen Thai Ngoc Duy wrote:
> >> On Thu, Aug 5, 2010 at 9:41 PM, Christian Couder
> >> 
> >> <chriscool@tuxfamily.org> wrote:
> >> > It looks like parse_commit() is buggy regarding replaced objects. But
> >> > I am not sure how it should be fixed.
> >> 
> >> It could be fixed the same way you did with parse_object(): replace
> >> read_sha1_file() with read_sha1_file_repl(). You would also need to
> >> fix parse_tree() and parse_tag(). But..
> >> 
> >> > Anyway if you use parse_object(), then you don't need parse_commit().
> >> > So if possible you should use parse_object() instead of both
> >> > lookup_commit() and parse_commit().
> >> 
> >> That's how those functions are used. For example, in
> >> traverse_commit_list(), lookup_*() may be called and uninteresting
> >> objects marked UNINTERESTING. Later on in process_{tree,blob,tag},
> >> parse_* may be called if their content is interesting.
> >> 
> >> To me, the fix above will leave a gap when object->sha1 is the
> >> original sha1, until parse_*() is called. It just does not sound good.
> > 
> > What do you think about adding a parse_commit_repl() function like the
> > patch below and then using it instead of parse_commit()?
> 
> How do you plan to use this new function? #define parse_commit(c)
> parse_commit_repl(c) or use the new function explictly when needed?

We have to use the new function explicitly instead of parse_commit() but I 
think in most cases we just need to change parse_commit(stuff) into 
parse_commit_repl(&stuff) and it will work.
 
> You are going to need parse_tree_repl() too 

Yes, probably, I did not look at that yet.

> unless you declare
> tree/blob replacement is not supported and make git-replace refuse
> blob/tree replacement.

I think they should be supported as much as possible in the long run but it is 
not as important as supporting commits.

> Another thing to address is, there will be a duration between
> lookup_commit() and parse_commit_repl(), where object.sha1 is the
> original one. If it is saved elsewhere, troubles are ahead.

Yes, parse_commit_repl() may not be the only solution needed in some cases but 
I think it is good enough in most cases.

> > ------- >8 ---------------------------------------------------
> > 
> > diff --git a/commit.c b/commit.c
> > index 652c1ba..183a735 100644
> > --- a/commit.c
> > +++ b/commit.c
> > @@ -316,6 +316,50 @@ int parse_commit(struct commit *item)
> >        return ret;
> >  }
> > 
> > +int parse_commit_repl(struct commit **commit)
> > +{
> > +       enum object_type type;
> > +       void *buffer;
> > +       unsigned long size;
> > +       int ret;
> > +       const unsigned char *repl;
> > +       struct commit *item = *commit;
> > +
> > +       if (!item)
> > +               return -1;
> > +       if (item->object.parsed)
> > +               return 0;
> > +       buffer = read_sha1_file_repl(item->object.sha1, &type, &size,
> > &repl); +       if (!buffer)
> > +               return error("Could not read %s",
> > +                            sha1_to_hex(item->object.sha1));
> > +
> > +       if (item->object.sha1 != repl) {
> > +               struct commit *repl_item = lookup_commit(repl);
> > +               if (!repl_item) {
> > +                       free(buffer);
> > +                       return error("Bad replacement %s for commit %s",
> > +                                    sha1_to_hex(repl),
> > +                                    sha1_to_hex(item->object.sha1));
> > +               }
> 
> You need to use lookup_object() instead here. lookup_commit() wil
> create new object if "repl" is not found.

We are inside the "if (item->object.sha1 != repl)" block, so we know that we 
will have to do "*commit = repl_item" with a repl_item that is different from 
item. So we have to create the repl_item commit if it doesn't exist.

Thanks,
Christian.

      reply	other threads:[~2010-08-14  2:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-31 12:36 [PATCH RFC] parse_object: pass on the original sha1, not the replaced one Nguyễn Thái Ngọc Duy
2010-08-02  7:42 ` Christian Couder
2010-08-02  9:31   ` Nguyen Thai Ngoc Duy
2010-08-03  5:00     ` Christian Couder
2010-08-03  6:01       ` Nguyen Thai Ngoc Duy
2010-08-04 11:58         ` Christian Couder
2010-08-04 12:42           ` Nguyen Thai Ngoc Duy
2010-08-04 12:57             ` Christian Couder
2010-08-04 22:07               ` Nguyen Thai Ngoc Duy
2010-08-05 11:41                 ` Christian Couder
2010-08-07  4:03                   ` Nguyen Thai Ngoc Duy
2010-08-13  3:59                     ` Christian Couder
2010-08-13  9:02                       ` Nguyen Thai Ngoc Duy
2010-08-14  2:03                         ` Christian Couder [this message]

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=201008140403.33164.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=pclouds@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).