Full files in changesets?

Michael Ellerman michael at ellerman.id.au
Mon May 30 02:55:32 BST 2005


On Mon, 30 May 2005 11:24, Aaron Bentley wrote:
> But the other side of it is that it's significantly less human-readable.
>  Often, the files that have been renamed have *also* been modified.  But
> since the patch contains two complete 'before' and 'after' copies of the
> file, there's no way you'll see the difference between the 'before' and
> 'after' versions.
>
> I suppose this could be handled by inserting a special diff for the
> renamed file:
> # This is a human-readable diff of foo.c, which is renamed to bar.c
> #@ -5,0 6,0 @
> #- This is the old text
> #+ This is the new text

Yeah that's a good point. I think generally in the kernel community people 
would send that as a rename patch, followed by a patch with any changes, but 
that's perhaps just best-practice that's developed because of the 
shortcomings of patch when it comes to expressing renames.

I think you can just be smart about it and express it as two diffs, a change 
to the original file, and then a rename diff at the bottom of the changset.

> I'm happy with calling them changesets, but I think that's an
> overly-narrow view of the term 'patch'.  The patches applied by World of
> Warcraft or Doom or any number of programs are not unified diffs, but
> they are called patches.  And certainly unified diffs were new too, once
> upon a time.

Well true, I guess I'm biased. I think amoungst UNIXees there's an expectation 
that a "patch" can be applied with patch(1) though.

> Let's say 'patches that cannot be applied by diff'.  There's more than
> just binaries.  There's empty directory creation.  There's permission
> changes.

s/applied by diff/applied by patch/
But yeah ok, there not things I think about much, but valid.

> I think once we've got a true next-generation changeset format, it makes
> all kinds of sense to get it supported by patch.

Ambitious, that would be cool though.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050530/1ef0424e/attachment.pgp 


More information about the bazaar mailing list