[darcs-users] rebase feedback and amend-record flexibility

[Ben Franksen]

Hi Michael

Michael Hendricks wrote:
>> >    - rewording commit messages, changing author, changing date, etc
>> >       - amend-record does this, it's just not smart enough yet
>> >       - rewording a patch needs no commute operations
>> >       - dependencies should never prevent a reword operation
>> >       - rewording a buried darcs patch only modifies other patches if
>> >       there are "record --ask-deps" dependencies (which appear easy to
>> >       adjust automatically)
>>
>> No, no, no! This is not possible, changing the meta data will change the
>> patch identity of an arbitrary number of other patches! I definitely want
>> to
>> have this disabled by default. Note that currently amend-record does not
>> mutate any patches other than the one I have explicitly chosen.
>>
> 
> If I want to change the meta data for patch P, three are three possible
> scenarios: no patches depend on P, a patch Q implicitly depends on P, a
> patch Q explicitly depends on P (via darcs record --ask-deps).  The first
> scenario is trivial and amend-record handles it well today.  The second
> doesn't mutate Q, so Darcs should handle allow it but doesn't. 

But it does mutate Q.

Suppose I have a patch named "fuzzled the wombaz", publish it, and then in 
my local copy I rename it to "foozled the wombaz". Then a darcs pull would 
pull in the original "fuzzled the wombaz" and then I had /two/ patches that 
did the same thing with slightly different names (and/or dates, authors, 
hash keys, etc).

I want to avoid such a situation.

> The third
> triggers the cascading effects you mention.  I agree that it should be
> disabled by default or generate a loud warning so the user isn't
> surprised.
>  In any case, the changes are easy, so a fancy rebase mechanism isn't
> needed.
> 
> Unfortunately, since Darcs refers to patches by their entire meta data,
> the
> cascading effect is worse than it needs to be.  A unique patch identifier,
> independent of other metadata, would let us correct typos in P without
> mutating Q at all.  Ignore-this "junk" might make a decent identifier, but
> that's for another discussion.

Ok, so you are aware of how things are, but you think meta data should not 
be part of the patch identity?

But then how does the system keep track of /which/ meta data is the right 
one?

>> >    - combining arbitrary, adjacent patches
>> >       - Darcs internals call this coalesce, but we have no UI for it
>> >       - current amend-record is a special case of this, applied to only
>> >       the top two patches
>>
>> To clarify: no, amend-record works fine for all patches that have no
>> dependents yet.
>>
> 
> Right.  One can view the current amend-record behavior as following these
> steps: commute patch A to the front, record working copy changes as patch
> C, coalesce A and C into A'.  In that sense, today's amend-record is a
> special case of combining patches, namely the top two.

In a way, yes. However, this is an implementation point of view, as opposed 
to the user interface. From the UI perspective, commutation is not something 
that has to be done, it is a fact. Change A commutes with change B, period. 
For me this means that there is no ordering relation between the two, and 
the way darcs lists them when I do 'darcs changes' is purely incidental. I 
think of a repository as a /set/ of changes, and I (mostly) regard two 
repositories that contain the same set of changes as equal.

On another level I am of course aware that the concrete representations of 
the two repos might be different, and in some cases I do care (for 
efficiency or presentation). But still: they are /semantically/ the same.

> Combining arbitrary, adjacent patches is a more general case.  As long as
> A and C can be commuted to adjacent positions somewhere in the patch list,
> amend-record should work.

Ok, I think I see now where this is heading...

> For example, imagine having patches A and B where B depends on A.  I want
> to amend changes C into A.  C does not depend on B.  Today's darcs fails
> this case because A can't commute to the front.  However, we could commute
> C backwards to get ACB, then combine into A'B

(I think you meant to say A'C)

Hm. But in this case the following should work

* temporarily obliterate B (keeping a copy in a clone)
* amend-record, combining A and C into A'C
* pull B from the clone...oops (conflict)

We cannot pull B with out pulling A. Because B depends on A. And A is no 
longer available locally, it has been changed into A'B. So B tries to pull A 
along, which most likely will lead to a conflict and to considerable 
confusion too, because A'B might have the same name as A.

I very much doubt that this can be made to work.

Cheers
Ben