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

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

Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal


From: Matthew Dempsky
Subject: Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal
Date: Sun, 31 Oct 2004 01:02:25 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Aaron Bentley <address@hidden> writes:

> Thomas Lord wrote:
>>     > From: Aaron Bentley <address@hidden>
>>     > Thomas Lord wrote:
>>     > >     > From: Aaron Bentley <address@hidden>
>>     > >     > One of the features of Arch I really like is the
>> history-sensitive     > >     > merging.  This process breaks
>> history-sensitive merge commands.
>>     > > That is a complete misapprehension.
>>     > No, that is totally accurate.  The process that Matthew
>> Dempsky used to     > commit patch-7 breaks all conceivable
>> history-based merge commands, and     > requires a human to
>> determine its origins.
>> You're full of it.
>
> Unless you can demonstrate that the information is not lost, *you're*
> full of it.  If there's no history, there can't be history-based
> commands.
>
> Tell me exactly how I can determine that patch-7 is derived from
> address@hidden/tla--devo--1.2--patch-25 and
> address@hidden/tlasrc--devel--0.2--patch-22
> without recource to human intelligence.

For what it's worth, patch-7 was generated by star-merging
address@hidden/tla--get-changeset-fix--1.3.  Presumably under
the modifications to the process Tom has recommended, you would be
able to additionally know that.  (Right now that's not evident,
however.)

I expect the necessary changes can be made by simply commiting a patch
to add =merges with all the versions I've merged patches from, or if
it's necessary to know in the individual patches I can undo all the
work I've done right now and remerge them.




reply via email to

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