Le samedi, 16 mai 2015 à 12:11, Thomas Leonard a écrit : > The problems with the two previous modes were: > > - In VCS mode, you make a change, recompile everything (which often > takes ages), test it and eventually reaslise your change wasn't > included because you didn't commit. >
I'm not sure I understand this. If you forget to commit, the pin will not update, so nothing will recompile when you do an `opam update -u` and hence I don't see what takes ages here. It seems to me that the desire for mixed-mode was rather to avoid going through the pain of staging/committing/reamending a fix until you are sure it actually works. With that respect it seems to me that the —dirty flags solves that problem quite well without the brittles of mixed-mode (and actually something I would be keen to use myself). I will also add that in practice mixed-mode can end up wasting a lot of your time as it can quickly ruin your opam install if you are not careful about the working directory of the pinned repo and that the package has many dependencies (case in point: cmdliner). Again, making sure that the working repo of each of your pin is in the right state whenever you `opam update -u` is unreasonable and cannot scale beyond a few pins. > Since the old mode is still available, the question is just about > choosing a default, which comes down to user expectations. My > expectation is that pinning a directory gets you the directory, not a > branch in its VCS, but only a user survey would reveal what other > people expect. > I don't think we need a user survey here. Consistency can be our guide. The fact that at the moment: opam pin -k git $PATH opam pin -k git $URL differ widely in the operational end results should raise some flags. Best, Daniel _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
