Marcin Kasperski <Marcin.Kasperski@xxxxxxxxx> wrote: > > As for permissions, well Shawn has often spoken of his hook scripts that > > implement very strong permissions (and he has done so again in this > > thread). I just posted it as a contrib patch. Maybe Junio will be willing to carry it around in his tree. If not, gmane now has it. :-) > I am not quite sure how can you forbid johny to see the code > in ./secret, while johny must checkout whole repo... > > Permissions are not only about writing. Indeed. But subsetting a repository by path like that is ugly in any DVCS. Which is why most don't do it. Probably better to subset by repository, aka the subproject support. Because odds are that if you are hiding a directory (johny cannot see ./secret) then you probably also need to hide all commit messages of all commits that affected ./secret too. And if those commits were to also modify stuff in ./public, then that starts to get really iffy. Better to just make a very clear distinction at the repository level. > > Depends what you want - I installed cygwin > > This is really not an option for typical windows user. Believe me. > Maybe it could be, if cygwin managed to create normal setup program > one day... Yea. I've had a number of Git users get burned by the git-merge-recursive script changing to git-merge-recursive.exe, and Cygwin's installer left git-merge-recursive in the directory when upgrading, but deleted some of the supporting Python modules. So they were unable to execute a merge. Better, one user succeeded in doing a `git merge -s ours foo`, completely tossing away the work of 20+ users over 3 months, because their HEAD was very old and their merge-recursive was utterly broken... They did not mean to do an ours style merge, it just happened that merge-recursive didn't do squat... because it was the old Python version, partially installed... I found out about the breakage only after those 20+ users managed to cram another 80 or so commits onto the top of that bad merge. Which meant that I couldn't just rewind the tree to redo the merge. I actually had to redo the merge as a new commit ontop of the bad history. Without losing any of the new changes. Ick. Thankfully just the week before I taught merge-recursive how to take trees (and not commits), allowing me to use it to carry the changes through whilest ignoring the bad merge base history. So anyway, my Git-on-Cygwin installer is now: ...on the master system... make clean && make prefix=/usr/local/git && rm -rf /usr/local/git && make install prefix=/usr/local/git && tar jcf update-git.tar.bz2 /usr/local/git ...and on other systems... cd / && rm -rf /usr/local/git && tar jxf update-git.tar.bz2 because dammit, that works, all of the time. Unlike Cygwin's setup.exe. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html