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

[Amit Shah]

Martin Pool wrote:

> On 16 Apr 2004, Amit Shah <address@hidden> wrote:
>> Martin Pool wrote:
>> 
>> > As an alternative to the 'merge request format' recently discussed, I
>> > have been wondering about an 'arch send format'.
>> > 
>> > I think this might be a better fit for the way open projects tend to
>> > work at the moment: I send a patch to a maintainer, asking for them to
>> > merge it.  They can review it and act on it immediately.
>> 
>> [snip suggestions]
>> 
>> This seems like a good idea, but won't work very well for representing
>> file renames, deletions, etc.
> 
> 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.

> 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.

We could have a shell script with a normal patch that shows changes within
files. For representing changes to the file structure (like renames,
deletes, etc.), we could put shell commands like "mv foo.h bar.h" and so
on, so that patches created by people using arch for people using other
systems (or even arch, but don't want to "get" the changesets from some
archive) can be applied normally.

This could introduce a security risk, but checking a (small) shell script
before running it could easily automate this process.

> 
> 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.
> 
> At the moment I imagine a diff plus some special comments, similar to
> those produced by 'bk send' or 'makepatch'.

I don't know how bk does it, and I guess it's best not to discuss how it
does it, for the obvious licensing horrors (you could be asked not to
enhance arch just because you use or know how bk works, am I right?)

> If I mail you a changeset you probably cannot do the same kind of
> smart star-merging that you might be able to do with full access to my
> archive.  But in some cases, this is a kind of social feature: the
> upstream maintainer doesn't *want* to get into doing a search through
> someone else's archive to find the right changeset.  They want to get
> a changeset that has already been made to fit, or they'll just reject
> it.


-- 
Amit Shah
http://amitshah.nav.to/