Le samedi, 16 mai 2015 à 13:22, David Sheets a écrit : > I don't usually use `opam update -u`
Right me neither, I do both operations in sequence but usually don't have a close look at the proposition. I tend to trust the work of the opam repo maintainers (shouldn't I ?). > I think that, whatever the outcome of these discussions, the mixed VCS > vs. explicit branch VCS modes should be made clearly distinct. Yes, that was my initial reaction and proposal in this comment: https://github.com/ocaml/opam/issues/2141#issuecomment-101994075 But by thinking more about this, I had the impression that we could kill a few concepts and get a simpler and better system for the end-user. > Afaik, git conventionally uses 'master' but this is only convention > and there is no mechanism to change this. Is that correct? In fact if we wanted to be consistent with what a `git clone` would do (the least surprising in my opinion), we should maybe rather take the repository's current active branch whenever we `opam pin -k git $PATH`. > What happens with a branch pin that is dirty-updated? Does it take the > working tree or only the working tree if the branch is the same? I would say let's keep this simple. This should mean: take the on-disk state of git-tracked files currently checked out in the working directory of the pin's git repo. Don't lookup branch information. > Or the working tree with the file filter of the branch specified? It > seems that working tree filtered by *current* branch is simplest which > you suggested. Not sure what you mean by file-filter. If you mean only take the on-disk state of the git-tracked files that are checked out in the working directory *and* are also tracked by the branch then I think the semantics is too tricky. I really want this to be obvious: now look at all the git-tracked files in the repo's working directory and try to use this for installing. (For this reason —working-dir may be a better name than —dirty, also it happens that `-w` is not used whereas `-d` is). > > I think that this would make a much more usable and and conceptually clean > > model of VCS pins. > > This is definitely a cleaner model than what we currently have. Do you > have objections against a solution using a pin parameter like `opam > pin -k git+dirty repo` which would behave as mixed mode currently does > except imply `--dirty` on relevant operations? Did you mean "would behave as mixed mode currently does *by* implying `—dirty` on relevant operations ?" No strong objection, but my initial aim was to try to reduce the pin modes to simplify the system both conceptually and from an implementation point of view. To me non automatic —dirty seems to be the only sane way of working with VCS pins if you need to scale. If you need something that always auto-syncs on sources you can still use path pins (as long as you do not build anything in them). It seems [1] that Louis tried to avoid having explicit dirty modes as it doubles the number of modes, but I think that by doing so the pin system became semantically much too obscure (cf. the comment I mentioned above). [1] https://github.com/ocaml/opam/issues/2033#issuecomment-76321338 Best, Daniel _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
