Re: Fwd: possible Improving diff algoritm
- From
Javier Domingo <javierdo1@gmail.com>
- Date
- Dec 12, 2012, 23:32 UTC
- Message-ID
- <CALZVapnzYBhPU1nR=eCSnm73c9-SpHq34DHu7OWCkouCQS0FxQ@mail.gmail.com>
- In-Reply-To
- <CAH5451=4dqqMnQa-R6O4ZrHOPSpHU9joWqf2UuOkbLtU9f8bkQ@mail.gmail.com>
I must say it is _quite_ helpfull having the diffs well done (natural diffs as here named), just because when you want to review a patch on the fly, this sort of things are annoying.
I just wanted to say my opinion. No idea on how to fix that, nor why does it happen.
Javier Domingo
2012/12/12 Andrew Ardill <andrew.ardill@gmail.com>:
Show 20 quoted lines
> On 13 December 2012 08:53, Junio C Hamano <gitster@pobox.com> wrote: >> The output being "a correct patch" is not the only thing we need to >> consider, though, as I mentioned in another response to Kevin >> regarding the "consequences". > > The main benefit of picking a more 'natural' diff is a usability one. > I know that when a chunk begins and ends one line after the logical > break point (typically with braces in my experience) mentally parsing > the diff becomes significantly harder. If there was a way to teach git > where it should try and break out a chunk (potentially per filetype?) > this is a good thing for readability, and I think would outweigh any > temporary pain with regards to cached rerere and diff data. > > Regards, > > Andrew Ardill > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html