From: Jonathan Nieder <jrnieder@gmail.com>
To: John Keeping <john@keeping.me.uk>
Cc: git@vger.kernel.org, Kevin Bracey <kevin@bracey.fi>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC/PATCH] patch-ids: check modified paths before calculating diff
Date: Sun, 19 May 2013 23:36:23 -0700 [thread overview]
Message-ID: <20130520063623.GB2919@elie.Belkin> (raw)
In-Reply-To: <20130519220206.GK27005@serenity.lan>
John Keeping wrote:
> On Sun, May 19, 2013 at 12:36:12PM -0700, Jonathan Nieder wrote:
>> Who is responsible for freeing
>> "path"? Would it make sense to use a strbuf here?
>>
>> strbuf_setlen(&buf, traverse_path_len(info, n));
>> make_traverse_path(&buf.buf, info, n);
>
> Perhaps alloc_traverse_path? I'm not sure the strbuf buys us much for
> this case, since we only use the result for a few lines before freeing
> it.
Good idea. Generally strbufs are nice for this kind of thing because
they make it easy to reuse buffers, but in this case there's no
opportunity for that.
[...]
> then this is "process_changed_path".
Sounds good.
[...]
>> What should happen for commits with more than 1 parent? If they're
>> supposed to not enter this codepath because of a previous check, a
>> die("BUG: ...") could be a good way to make reading easier.
>
> Currently the patch ID code compares the commit with its first parent,
> so I think this should do the same.
Ok. I guess a comment nearby would help future readers avoid the same
question.
I don't know what it should mean to try to use --cherry without
--no-merges or --first-parent, so I guess this is harmless.
[...]
> Thanks for the review.
No problem. Thanks for a pleasant read.
Ciao,
Jonathan
next prev parent reply other threads:[~2013-05-20 6:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-19 13:17 [RFC/PATCH] patch-ids: check modified paths before calculating diff John Keeping
2013-05-19 19:36 ` Jonathan Nieder
2013-05-19 22:02 ` John Keeping
2013-05-20 6:36 ` Jonathan Nieder [this message]
2013-05-20 8:16 ` John Keeping
2013-05-20 4:46 ` Junio C Hamano
2013-05-29 6:20 ` Jeff King
2013-05-29 7:22 ` Jeff King
2013-05-29 7:50 ` Jeff King
2013-05-29 18:08 ` Junio C Hamano
2013-05-29 18:36 ` Jeff King
2013-05-29 18:48 ` Junio C Hamano
2013-05-29 21:30 ` John Keeping
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=20130520063623.GB2919@elie.Belkin \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@keeping.me.uk \
--cc=kevin@bracey.fi \
/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