Dan Pascu wrote: > On 2 Oct 2009, at 15:33, Sittampalam, Ganesh wrote: > >> However it's not completely obvious to me that --skip-conflicts >> really is mutually exclusive with --don't-allow-conflicts. In >> particular, with --don't-allow-conflicts but not --skip-conflicts, >> you'll get offered every patch and then get a failure if any >> conflict. So if we accept your argument, and you have >> --skip-conflicts as a default and then you specify >> --don't-allow-conflicts on the command line, then suddenly you'll >> get conflicting patches offered to you. > > Why? Aren't the options selected (from global defaults, local > defaults and command line) before any processing is started? I do not > know the code, but I would expect that before any processing is done, > the code has already determined what options will be applied.
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. Given the names of the options, it seems counterintuitive to me that this should happen. Arguably this is a failing of --don't-allow-conflicts, but we've already discussed whether that should be repurposed to skip conflicts and the conclusion seems to be "no" because of the loss of atomicity on push/apply. >> My general feeling is >> that --skip-conflicts may not be that useful as a default, and the >> more > > It may not be useful, but you cannot stop someone from using it like > that and then you still have to handle the situation in the code in > order for the code to work in any possible case the user is allowed > to create. I'm only saying that if the user specifies --skip-conflicts as a default, they'd have to explicitly use --no-skip-conflicts to turn it off [at least, I think darcs has automatic negation of arguments using --no-..., if not then it should :-)] >> likely use cases are for the user to specify --mark-conflicts or >> --don't-allow-conflicts in the defaults file, and then to override >> that on the command line with --skip-conflicts. > > > > OK, now I understand where you're coming from. However I do not agree > with this point of view. A darcs user doesn't know about all these > details and how the code is written and what dependencies are there > in the process of filtering out some patches. Making these options > not mutually-exclusive will make it very difficult for a user to > remember all the relations between them, which has to come first, > which affects which and how. Now even if he remembers that he would > have to also remember what options he put where (global defaults, > local defaults) and how they will combine with what he just typed on > the command line. This can get out of hand fast. > > IMO, these options should not mix with each other. The last one > specified should take effect, the previous ones should be ignored. > This would make the user interface much cleaner, simpler to use and > remember. > > I know that for a developer, these relations may be obvious or easy > to remember, but it would simplify it a lot of end users if it would > be restricted to a set of mutually exclusive options (which should be > easy to do by just picking the last one specified). I am arguing that making these options mutually exclusive is not necessarily intuitive (and hence clean, simple to use and remember), because out of all of them, only --skip-conflicts has an impact on interactive patch selection. Again, this isn't an issue about the code, but about what the user sees. I believe that in fact they are mostly orthogonal, except in that using --skip-conflicts happens to have the side-effect of making --don't-allow-conflicts and --mark-conflicts irrelevant. Perhaps the real answer is that we should figure out the right UI for all these options, including the --external-merge one you mention in your other email, rather than trying to bolt --skip-conflicts on top of existing behaviour. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html =============================================================================== _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
