Antoine Pelisse writes:
> So here is a more thorough description of the option:
> - real changes are interesting
> - blank lines that are close enough (less than context size) to
> interesting changes are considered interesting (recursive definition)
> - "context" lines are used around each hunk
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for "break-rewrites".
When this option is used, git-diff will not create hunks that simply
add or remove empty lines, but will still show e
Antoine Pelisse writes:
> Re-reading note: OK, This last sentence ("If not we will eventually be
> too far and break") is actually a bug. We might break before we find
> something interesting while we should keep going. For example in such
> a case, we should display like this, but won't:
Glad t
+ } else if (changes != ULONG_MAX &&
+xch->i1 + changes - (lxch->i1 + lxch->chg1) >
max_common) {
+ break;
>>
>> If we are no longer in "interesting zone" (changes != ULONG_MAX), it
>> means we will stop if the distance is
Antoine Pelisse writes:
>>> + unsigned long changes = ULONG_MAX;
>
> Let me explain what "changes" means, as I know it will help the rest
> of the message:
> It counts the number of *added* blank lines we have ignored since
> "lxch" (needed to calculate the distance between lxch and xch)
> It
On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> So here is a more thorough description of the option:
>
>> - real changes are interesting
>
> OK, I think I can understand it.
>
>> - blank lines that are close enough (less than context size) to
>> interestin
On Mon, Jun 17, 2013 at 6:18 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> So here is a more thorough description of the option:
>
>> - real changes are interesting
>
> OK, I think I can understand it.
>
>> - blank lines that are close enough (less than context size) to
>> interestin
Antoine Pelisse writes:
> So here is a more thorough description of the option:
> - real changes are interesting
OK, I think I can understand it.
> - blank lines that are close enough (less than context size) to
> interesting changes are considered interesting (recursive definition)
OK.
>
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for "break-rewrites".
When this option is used, git-diff will not create hunks that simply
add or remove empty lines, but will still show e
Antoine Pelisse writes:
>>> Anyway, I'm starting to think that "show blank lines changes near
>>> other changes" makes sense more and more sense.
>>
>> Probably.
>
> I'm glad to see how convinced you are ;)
That is not me "not convinced".
It is merely "I do not have a strong conviction that you
On Mon, Jun 10, 2013 at 11:43 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano wrote:
>>> When any ignore blank option is used, there will be lines that
>>> actually has changes (hence should be shown with +/-) but we
>>> deliberately ignor
Antoine Pelisse writes:
> On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano wrote:
>> When any ignore blank option is used, there will be lines that
>> actually has changes (hence should be shown with +/-) but we
>> deliberately ignore their changes (hence, if they ever appear in the
>> hunk, they
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano wrote:
> When any ignore blank option is used, there will be lines that
> actually has changes (hence should be shown with +/-) but we
> deliberately ignore their changes (hence, if they ever appear in the
> hunk, they do so as context lines prefixed
Antoine Pelisse writes:
> It might be kind of noisy, but I think trying to improve the solution
> might lead to over-engineering.
> How would we compute the "minimal distance between interesting and
> blank" so that the blank becomes interesting ?
> Using the context size for that is quite conven
On Sun, Jun 9, 2013 at 10:07 PM, Junio C Hamano wrote:
> by
> the way, do we also handle deletions and do your new tests check
> them?
As stated in the commit message, yes we should, but we don't have
tests for that.
I will need to add some as I think I found a bug when removing blank lines.
>>
Antoine Pelisse writes:
> The goal of the patch is to introduce the GNU diff
> -B/--ignore-blank-lines as closely as possible. The short option is not
> available because it's already used for "break-rewrites".
>
> When this option is used, git-diff will not create hunks that simply
> adds or rem
On Sat, Jun 8, 2013 at 4:44 PM, Antoine Pelisse wrote:
> The goal of the patch is to introduce the GNU diff
> -B/--ignore-blank-lines as closely as possible. The short option is not
> available because it's already used for "break-rewrites".
>
> When this option is used, git-diff will not create h
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for "break-rewrites".
When this option is used, git-diff will not create hunks that simply
adds or removes empty lines, but will still show
On Tue, Jun 4, 2013 at 10:46 PM, Junio C Hamano wrote:
> OK. Thanks.
>
> I think the logic would be more like:
>
> 1. Start from xscr, find the first xchp that is !xchp->ignore;
> if there is none, we are done. There is no more to show.
>
> 2. Remember the xchp as the beginning.
>
> 3. Tan
Antoine Pelisse writes:
> On Tue, Jun 4, 2013 at 8:26 PM, Junio C Hamano wrote:
>> Antoine Pelisse writes:
>>
>>> +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg) {
>>> xdchange_t *xch, *xchp;
>>> long max_common = 2 * xecfg->ctxlen + xecfg->interhunkctxlen;
>
On Tue, Jun 4, 2013 at 8:26 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg) {
>> xdchange_t *xch, *xchp;
>> long max_common = 2 * xecfg->ctxlen + xecfg->interhunkctxlen;
>> + long ignorable_context =
Antoine Pelisse writes:
> +xdchange_t *xdl_get_hunk(xdchange_t **xscr, xdemitconf_t const *xecfg) {
> xdchange_t *xch, *xchp;
> long max_common = 2 * xecfg->ctxlen + xecfg->interhunkctxlen;
> + long ignorable_context = max_common / 2 - 1;
Could you explain how this math works? A
On Mon, May 27, 2013 at 9:14 AM, Antoine Pelisse wrote:
> On Sun, May 26, 2013 at 10:35 PM, Johannes Sixt wrote:
>> I'm thinking of diffs of files with CRLF
>
> Good you did, because I didn't ;-)
>
>> line breaks, where the CR would count as whitespace in the line, I think.
>
> With the current i
On Sun, May 26, 2013 at 10:35 PM, Johannes Sixt wrote:
> Am 26.05.2013 19:58, schrieb Antoine Pelisse:
>> The goal of the patch is to introduce the GNU diff
>> -B/--ignore-blank-lines as closely as possible. The short option is not
>> available because it's already used for "break-rewrites".
>>
>>
Am 26.05.2013 19:58, schrieb Antoine Pelisse:
> The goal of the patch is to introduce the GNU diff
> -B/--ignore-blank-lines as closely as possible. The short option is not
> available because it's already used for "break-rewrites".
>
> When this option is used, git-diff will not create hunks that
The goal of the patch is to introduce the GNU diff
-B/--ignore-blank-lines as closely as possible. The short option is not
available because it's already used for "break-rewrites".
When this option is used, git-diff will not create hunks that simply
adds or removes empty lines, but will still show
26 matches
Mail list logo
