[darcs-users] big-patches problem!

[Isaac Dupree]

Trent W. Buck wrote:
> Isaac Dupree <isaacdupree at charter.net> writes:
> 
>> Gwern Branwen wrote:
>>> There's no winning, is there. :( One big patch doesn't commute, and a
>>> lot of little patches pollutes the history, and mixing it into other
>>> changes is unclear.
>> "pollutes the history" is an excuse that bothers me.  Why?  Because
>> the only effect is on user-interface things that we could easily
>> change, such as `darcs changes`.  Maybe when you make a patch bundle
>> there should be some way to specify that all the patches do the same
>> thing and should normally be shown as just one entry in the history.
> 
> When discussing the power of amend with git users, they pointed out that
> I am essentially throwing away history when I amend.  As long as I'm
> happy to admit my mistakes, a better way[0] would be to just keep
> committing new patches, but somehow declare "this patch amends <hash>".
> 
> By default, then, "darcs changes" would collapse all the amendments into
> a single changelog entry, but some --no-collapse option would show the
> full history.  Further, this would avoid problems when upstream applies
> a patch that you later amend.

I agree... amending as a regular practice annoys me too.  It 
makes sharing proposed patches a lot harder, for example. 
It makes, where darcs is normally a fairly safe RCS to use, 
additional danger at every step :-)

I imagine there are situations where your amendment involves 
reverting a lot of the changes the original patch made; 
where you might want to actually get rid of that part of the 
history (it might affect commutation?).  But that's not an 
issue most of the time amendments are made.  Oh.. the other 
reason, that GHC used: amending to avoid conflict-resolution 
patches, because of the exponential blowup issue... is that 
still a problem in darcs2-format repos?

-Isaac