Re: [Gnu-arch-users] Fast commits

[Robin Farine]

Tom Lord wrote:

> One nice thing about the way patch-logs currently work is that mkpatch
> and dopatch don't have to know anything (much) special about them.
>  
Yes, I confess that I was a bit afraid to write in black on white that 
this nice property would probably go away ...

> So, summary files instead of patch-log is an interesting idea -- but 
> one question is whether it hairs-up mkpatch/dopatch or whether the
> format can be designed in such a way that the nice properties of the
> current system can be preserved.
>  
First, I tried to come up with a representation that would still work 
with diff/patch. But this does not make much sense since each change set 
should somehow be explicitly represented and thus even with 1 character 
per change set, it would result into a huge summary file for a version 
containing many thousands of change sets. So, the interval 
representation followed since, in most cases, a version will consist of 
long series of consecutive patches. And I am afraid a new pair of 
diff'/patch' tools working on intervals is required.

But this could also solve another old "problem", whether a missing 
patch-log means that the change set is missing or that it has been 
rejected.  With the summary file format and specialized diff' & patch' 
tools, it would probably be easier to define rules that distinguish 
missing change sets from rejected ones during a merge.

> (Now that you mention it -- I think a similar idea _did_ come up a
> long time ago but the mkpatch/dopatch hair was the stumbling block.
> One thing that has changed since then is that I might now be more
> willing to consider a little mkpatch/dopatch hair than I was then.)
>  
It might just grow a very thin and blond hair like, e.g., the handling 
of file permissions :-P


Robin