pin -k: take current version of Git-tracked files

[talex5]

-k git makes development difficult by requiring you to commit before testing, and it's easy to forget to do this. -k path copies everything, including files like setup.data that will mess up the build.

It would be good to have a hybrid mode, where we use the current state of the files in the working directory, but use Git metadata to decide which files to copy. Two approaches have been suggested:

• I propose taking only files tracked by Git. If you add a new file to the project, you must git add it for opam to use it.
• @dbuenzli suggests the alternative of taking everything except ignored files.

(For development, I prefer the first option, because it means I can test by installing locally with opam and know I didn't forget to add a file.)

Original discussion: http://lists.ocaml.org/pipermail/opam-devel/2014-November/000806.html

[dbuenzli]

Thinking this over I'm also more in favor of the first, since it does safer by default, if you forgot to add your build with fail and that failure should be easy to diagnose. .gitignore are often only partially specified (at least mines).

[Drup]

I think it's an excellent idea. I would tend to prefer the first approach too.

[AltGr]

A behaviour equivalent to running rsync with --files-from =(git ls-files) then ? This sounds convenient indeed, and shouldn't be too difficult. I am wondering how to describe that in the interface though, should it:

• be a completely different git mode (with a possible equivalent for other VCS) with a different name ?
• or become the default git mode when the git directory is available locally ? (We already sync with the currently checked out HEAD each time)
• or be a change in the local/rsync mode that filters files when it detects a git (or other VCS ?) system ?

I'd be in favor of 2 from an interface point of view, keeping the current local mode behaviour. You'd still be able to target a specific branch (#master) in case it's not what you want. Then we may change back the default to git-pinning on git repos. Of course, implementation-wise, this would be more like the rsync backend.

Last, but not least, we'll need to properly and clearly explain this at the correct places to be sure not to add to the confusion.

[dbuenzli]

Le mardi, 18 novembre 2014 à 02:13, Louis Gesbert a écrit :

I'd be in favor of 2 from an interface point of view, keeping the current local mode behaviour. You'd still be able to target a specific branch (#master) in case it's not what you want. Then we may change back the default to git-pinning on git repos.

That seems quite sensitive to me. We get the good default (at least IMHO) but can still switch to a more stringent mode. And yes to default git-pinningon git repos, almost every time I add a pin I need to it twice because I forget the -k git.

Best,

Daniel