[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: 'arch send' format

From: Colin Walters
Subject: Re: [Gnu-arch-users] Re: 'arch send' format
Date: Fri, 16 Apr 2004 11:29:06 -0400

On Fri, 2004-04-16 at 03:39, Martin Pool wrote:

> I don't think show-changeset can do that very well at the moment, but
> I don't see any in-principle reason why it could not be extended to do
> so.

This has come up several times in the past.

> For backward compatibility with patch deletes could be represented as
> an edit down to /dev/null.  (There is a corner case here in
> distinguishing "deleted" from "emptied" but it could be handled.)
> Showing the whole file as delete lines in the patch has the benefit of
> detecting conflicts in deleted files, much as changesets already have
> a removed-files-archive/ directory.
> Having said all that, most changes do not rename/delete files, and
> that is even less common when you are submitting your changes to the
> owner/integrator of the project.
> It might also be necessary to include file id indexes.

If you want the representation to be lossless, that is absolutely

> What I am proposing is basically just an textual representation of a
> changeset directory that does not lose any information and that can be
> converted back.
That's harder than you think.  The proposals later in this thread like
"mv foo.c bar.c" or "foo.c => bar.c" are broken.  I actually mentioned
this in my Grokking Arch presentation.  Arch changesets fundamentally
operate on file identities, not file names. 

You can never just pipe this hypothetical export format straight into
"patch" if you want it to be lossless, because "patch" doesn't
understand the fact that a file may have moved elsewhere, for example. 
If a file exists at the old name, it will blithely try to patch it.

My worry in providing such an export feature is that people would try to
use it in a lossless fashion with just patch/mv, and get burnt.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]