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.
Ganesh
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
