[darcs-devel] about patches touching files

[Ben Franksen]

Am 16.10.2018 um 23:52 schrieb Ganesh Sittampalam:
> On 16/10/2018 21:53, Ben Franksen wrote:
>> This means we have two choices: either we add the idempotent patch pairs
>> to the effect of a conflictor or we create a new primitive interface
>> that is richer than listTouchedFiles and so allows us to fully
>> re-construct object identities. The first solution is awkward in its own
>> way. It means application of a conflictor does many operations to the
>> tree just to immediately revert them. This is really inefficient and
>> feels a bit stupid. The second solution looks more practical to me:
>> design a new prim interface tailored for tracking tree object identities
>> so we don't have to abuse patch application for that. I think I'll start
>> playing with this and see how far it gets me...
> 
> Sorry for misinterpreting first time round :-)
> 
> What you're saying makes sense, but I'm failing to form a clear picture
> in my head of what actual behaviour we want from the UI here. I think
> that would help to design the right solution.
> 
> I guess this is primarily about darcs changes (where we use it to look
> for changes to a specific file) and darcs annotate?

I think this concerns many more commands. One example that supports
filename arguments is 'darcs rollback <path>'. Other commands (e.g.
obliterate) can be used with --matches 'touch <path>' and are therefore
also affected.

> For example, do we want the user to be presented with the "potential"
> impact on those files from conflicts that actually have no effect in the
> sequence they are currently in? That seems more accurate. Or would it be
> better to show them something based on the current linearisation, even
> if that isn't invariant under commutation?

I think consistency is very important for a good user experience, so I'd
say yes, a conflictor should be regarded as touching anything the
original (undone) patch touches, in addition to its 'real' effect.

> It might also be instructive to think about what impact we'd expect hunk
> move to have. Would we end up having to track identity on a line-by-line
> basis?

Ha. I have completely forgotten about hunk moves. Yes, if we take hunk
moves seriously we might have to give identity to file content.
Interestingly, there is precedence for that: the annotate command
already does a bit of content tracking, albeit in a restricted form. I
have sometimes wondered if annotate could be made smarter. It is often
not as useful as I would like it to be. Instead of the last patch that
modified a piece of code, I am typically more interested in the /first/
patch that /created/ that code. Because then I can look at the full
patch, the patch info etc and so may get a better picture of what the
idea was. I am not sure this is possible with our current formalism,
even with hunk moves.

Cheers
Ben