gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: Martin Pool
Subject: Re: [Gnu-arch-users] Re: 'arch send' format
Date: Fri, 16 Apr 2004 17:39:51 +1000
User-agent: Mutt/1.5.5.1+cvs20040105i

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.

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

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.

-- 
Martin 

Attachment: signature.asc
Description: Digital signature


reply via email to

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