Re: GIT vs Other: Need argument

["Shawn O. Pearce" <spearce@spearce.org>]

Marcin Kasperski <Marcin.Kasperski@softax.pl> 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.