[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Encoding handling proposal
From: |
Marcus Sundman |
Subject: |
Re: [Gnu-arch-users] Encoding handling proposal |
Date: |
Tue, 31 Aug 2004 01:12:36 +0300 |
User-agent: |
KMail/1.7 |
On Tuesday 31 August 2004 00:24, Charles Duffy wrote:
> On Sun, 2004-08-29 at 17:29, Marcus Sundman wrote:
> > On Monday 30 August 2004 01:09, Charles Duffy wrote:
> > > Hmm -- being able to view the difference between two files in a way
> > > sensitive to their type without being able to apply those changes in
> > > a way sensitive to the file type seems like rather a waste.
> >
> > Yes, but that doesn't mean the patch file format has to be different,
> > just that it has to be flexible enough to accomodate a wide range of
> > situations. E.g. a diff tool for java source code might notice that a
> > 20 line method you moved hasn't changed at all, so it might write a
> > patch file saying that the corresponding byte range is moved to another
> > offset. A generic text diff tool on the other hand might make a patch
> > file saying 20 lines have been removed and 20 new lines have been
> > introduced at another offset. The latter patch file would be a lot
> > larger than the former, but that doesn't mean they would have to have
> > different formats.
>
> "Move this byte range from here to here" isn't robust against patching
> on inexact input; such a patch would thus be unmergable.
I don't see why the format couldn't support variable size pre- and
post-contexts. That wouldn't be as nice as a custom, fully context-aware
diff/patch pair, but at least it'd be as good as the standard gnu diff.
> "Move the method with *this* name to be above the method with *this*
> name" is more robust, and could be applied (or rejected with an
> intelligent explanation about why it won't apply) -- but doing it means
> a file-format-aware diff/patch tool pair.
I agree that such an approach would be more robust, but I don't think the
benefits outweigh the problems. I strongly believe in having only one patch
file format, but I wouldn't mind having it support some "fancy"
transformations. That way features could be added to future diff tools
without having to update all existing systems.
- Marcus Sundman
- [Gnu-arch-users] Encoding handling proposal, Marcus Sundman, 2004/08/29
- Re: [Gnu-arch-users] Encoding handling proposal, John Meinel, 2004/08/29
- Re: [Gnu-arch-users] Encoding handling proposal, Marcus Sundman, 2004/08/29
- Re: [Gnu-arch-users] Encoding handling proposal, Charles Duffy, 2004/08/29
- Re: [Gnu-arch-users] Encoding handling proposal, Marcus Sundman, 2004/08/29
- Re: [Gnu-arch-users] Encoding handling proposal, Charles Duffy, 2004/08/29
- Re: [Gnu-arch-users] Encoding handling proposal, Marcus Sundman, 2004/08/29
- Re: [Gnu-arch-users] Encoding handling proposal, Charles Duffy, 2004/08/30
- Re: [Gnu-arch-users] Encoding handling proposal,
Marcus Sundman <=
- Re: [Gnu-arch-users] Encoding handling proposal, Charles Duffy, 2004/08/30
Re: [Gnu-arch-users] Encoding handling proposal, Alexey N. Solofnenko, 2004/08/29
Re: [Gnu-arch-users] Encoding handling proposal, David Allouche, 2004/08/30
[Gnu-arch-users] Re: Encoding handling proposal, Stefan Monnier, 2004/08/30
Re: [Gnu-arch-users] Encoding handling proposal, Tom Lord, 2004/08/30