From: "Pavel Raiskup" <xraisk00@gmail.com>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC)
Date: Tue, 22 Mar 2011 13:32:48 +0100 [thread overview]
Message-ID: <op.vsqvsyit2m56ex@localhost.localdomain> (raw)
In-Reply-To: <AANLkTi=6z=4m8opfhy9pV1S6ySobSA+WEEESESOJ0MZ4@mail.gmail.com>
>> Histogram diff:
>> There is no mentor mentioned in [1]. Does it mean that there is no person
>> ..
>
> As the original author of HistogramDiff in JGit, and a contributor to
> C Git... I'm probably the best person to mentor this task. I'm really
> busy, so I didn't sign up to mentor anything else this year, but I
> think I would make time for this project.
Thanks for your answer and for your ability to be a mentor of this task.
>> There is a goal "Get this feature merged to the upstream git." -- but I have
>> one theoretical question -- what if the benchmarking/study of histogram diff
>> leads to conclusion that this algorithm will not be useful for upstream?
>
> Then the project doesn't merge. :-)
>
>> Does it mean "fail" in terms of GSOC? I have to think about it even if it
>> looks that there should be speedup quite obvious. I don't want to fail
>> a priory :).
>
> I don't think so
>
> I think the success of this project is if the code is of the quality
> that upstream would accept it, and if the final analysis data makes it
> clear whether or not its worth including. Its probably not worth
> including if its the same speed as the current Myers diff
> implementation from libxdiff or slower. But if its 2x faster, its
> probably worth merging. If the code quality is acceptable to the
> upstream maintainers.
I wanted to know exactly this kind of information. Of course
I don't want to make a code of unacceptable quality from any perspective.
And I think that you probably don't expect histogram diff to be significantly
faster in general :)
Thanks again - it is good to know that you as author of histogram diff are
here. And sorry for my latency ..
[ot] this is because of hectic school schedule now - which is actually not
good :( I need to study git source very deeply _NOW_ (I wanted to reply
earlier but..) [/ot]
Thanks to Junio C Hamano with almost the same answer here:
http://thread.gmane.org/gmane.comp.version-control.git/169498/focus=169516
Pavel
>> [1] https://git.wiki.kernel.org/index.php/SoC2011Ideas
next prev parent reply other threads:[~2011-03-22 12:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-20 10:55 Histogram diff, libgit2 enhancement, libgit2 => git merge (GSOC) Pavel Raiskup
2011-03-20 18:06 ` Shawn Pearce
2011-03-22 12:32 ` Pavel Raiskup [this message]
2011-03-20 18:25 ` Junio C Hamano
2011-03-20 21:01 ` Vicent Marti
2011-03-20 23:44 ` Jeff King
2011-03-21 0:38 ` Vicent Marti
2011-03-22 17:32 ` Pavel Raiskup
2011-03-22 18:47 ` Jeff King
2011-03-22 19:18 ` Junio C Hamano
2011-03-21 1:27 ` Jonathan Nieder
2011-03-22 16:43 ` Pavel Raiskup
2011-03-23 0:24 ` Vincent van Ravesteijn
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=op.vsqvsyit2m56ex@localhost.localdomain \
--to=xraisk00@gmail.com \
--cc=git@vger.kernel.org \
/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).