[darcs-users] darcs patch: Resolve issue1588: make--dont-allow-conflicts filter ...
ganesh at earth.li
Mon Oct 5 19:51:59 UTC 2009
On Mon, 5 Oct 2009, Dan Pascu wrote:
> On 5 Oct 2009, at 16:28, Sittampalam, Ganesh wrote:
>> It's not an issue of the code, but of the user interface (I know I
>> started out this discussion by explaining what the code would do by
>> default, but that's actually irrelevant since it's quite easy for me to
>> implement either option.)
>> With just --don't-allow-conflicts, conflicting patches are presented
>> during interactive selection, but selecting one causes a later failure.
>> With just --skip-conflicts, conflicting patches are not presented during
>> interactive selection.
>> So if we say that they are mutually exclusive options, then
>> --skip-conflicts --don't-allow-conflicts will present conflicting
>> patches, because --skip-conflicts is completely suppressed.
> If they are mutually exclusive, I assume that the program will decide
> what option to use before it starts to do anything. So if I have
> skip-conflicts in the defaults file but I give --dont-allow-conflicts on
> the command line, then indeed I expect that skip-conflicts (specified in
> the defaults) is completely suppressed and ignored.
Right, and I am saying that this behaviour, while straightforward to
implement, might be rather confusing.
> The way you present things, it sounds like darcs starts to process
> skip-conflicts and filter out the patches before it sees
> --dont-allow-conflicts and later when it sees the second option it enters in
> a conflicting state because the second option was also processed and produced
> a conflicting set of patches.
That's not what happens. At point (1) in the code, --skip-conflicts
filters out all the patches that would cause a conflict. At point (2),
--dont-allow-conflicts throws an error if any patches are left that would
cause a conflict. So if they are not treated as mutually exclusive, then
specifying both leads to no conflicting patches being offered, so
--dont-allow-conflicts will never throw the error. If they are treated as
mutually exclusive, then conflicting patches are offered.
> At least this is what I understood from your description. I was under
> the assumption that darcs finds out what options it has to use before it
> starts to process anything, so it will never be in a position to see a
> conflicting request, because it never sees both options active during
> any given processing. For me mutually exclusive means that when I
> encounter the second option, I discard and forget about the first one
> and after I got all options by parsing the defaults files and command
> line, only then I start to do the processing according to those options.
> I feel like I'm missing something here.
The problem is not with the implementation, but with the user confusion
that might result from the addition of --dont-allow-conflicts causing
conflicting patches to be offered in interactive selection when they
weren't previously. But perhaps the fact that I'm finding it so hard to
get across what I mean shows that my preferred behaviour is actually the
more confusing one.
More information about the darcs-users