but git is definitely no harder to learn
than anything else. I browsed through the mecurial tutorial
yesterday - and as well as being significantly less powerful than git,
it's no easier.
Mercurial is easier to learn, because it has better docs and slightly
simpler command line (all those -a, -p, ... options which one always
forgets to add). I tried it.
In fact, I did the experiment about month ago. I wanted to give a try
to distributed vc tool. I started from GIT, played a bit with it, and
abandoned it because a) I did not know whether I am expected to use git,
or cg, b) While reading docs many times I had the feeling that something
strange and unclear is going behind the hood.
Then I took mercurial and in a few hours I felt I know all the important
things.
(I can't believe this one - if you want to branch a mercurial repository
you have to have another complete checkout. Erm... the checkout takes
up more space than the repository - why do I need another copy? Anyway,
git is no harder than Mercurial here)
AFAIK you are wrong, they are able to link some files while cloning, so
you loose space only if you switch machine or filesystem. Also, recent
mercurial has initial within-repo branches support. But I am not really
the best person to conduct git-vs-hg discussion.
"(Note for Windows users: Mercurial is missing a merge program" - that
Windows support isn't looking quite so hot now.
Mercurial on windows works well with kdiff3 or tortoisemerge, you must
only install one of them.
quoted
c) Lack of reasonable subproject support (plus detailed permission
model).
Mercurial has no native subproject support either - it requires a
plugin, git's is in development.
As I said, I am not conducting hg-vs-git discussion. I just happened
to introduce and manage VC system in corporate environment, so I am able
to point that this is important feature.
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 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.
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...
Let me retype it: I am not complaining. GIT developers are not forced to
think about win users, or about corporate needs. But if they are, it is
reasonable to know the problems.
On 4/19/07, Marcin Kasperski [off-list ref] wrote:
Let me retype it: I am not complaining. GIT developers are not forced to
think about win users, or about corporate needs. But if they are, it is
reasonable to know the problems.
Windows (and, by extension, most corporate) users are used to both:
complain and suffer. What they cannot imagine is _doing_ something.
It just does not fit in their heads.
A user feels the need to restrict access to some trees in a git repository?
He'll start looking, asking, and maybe even raving about the missing
feature on some official channel. What never occurs to him is just
implementing it. And he'll be outraged if you suggest it (and, yes, it was
tried. The person felt insulted and is sulking till this day)
Besides, it looks like we need them: the stupid, lazy and numerous
windows users. I sometimes ask myself what for did I try to explain
merging and distributed workflow to my peers? The most reasonable
answer so far: so they don't bother me with their stupid work flow.
Don't like it though: people don't like to be called stupid (or anything
they do), and I happen to like most of them anyway.
And I start coding workarounds (the recent is git-remote, why the
hell must it be coded in perl?)
On Thursday 2007 April 19 12:59, Marcin Kasperski wrote:
quoted
but git is definitely no harder to learn
than anything else. I browsed through the mecurial tutorial
yesterday - and as well as being significantly less powerful than git,
it's no easier.
Mercurial is easier to learn, because it has better docs and slightly
simpler command line (all those -a, -p, ... options which one always
forgets to add). I tried it.
In fact, I did the experiment about month ago. I wanted to give a try
to distributed vc tool. I started from GIT, played a bit with it, and
abandoned it because a) I did not know whether I am expected to use git,
or cg, b) While reading docs many times I had the feeling that something
strange and unclear is going behind the hood.
In terms of normal operation, there aren't many switches one actually needs to
remember. The only one I can think of is "-a" for commit - however, that's
just to make it work like mercurial - a seasoned git user won't use many
switches. My daily grind consists of
git add file.c
git commit
git add file.c
git commit
git add -i
git commit
(Interactive mode for git-add is a joy to use - I don't know if Mercurial has
anything similar).
Now, to your point. I think you're right. What I said was that git actually
is easier; however if you looked at some of the documentation you would
incorrectly assume that that was not the case.
quoted
(I can't believe this one - if you want to branch a mercurial repository
you have to have another complete checkout. Erm... the checkout takes
up more space than the repository - why do I need another copy? Anyway,
git is no harder than Mercurial here)
AFAIK you are wrong, they are able to link some files while cloning, so
Can't be. I'm talking about the working directory not the repository - if the
files are linked back to the originals, then it's not a separately editable
set of files is it?
you loose space only if you switch machine or filesystem. Also, recent
mercurial has initial within-repo branches support. But I am not really
the best person to conduct git-vs-hg discussion.
I'm glad that Mercurial is getting in-repo branches, they're great. I really
wouldn't want to live without them now I have them.
quoted
"(Note for Windows users: Mercurial is missing a merge program" - that
Windows support isn't looking quite so hot now.
Mercurial on windows works well with kdiff3 or tortoisemerge, you must
only install one of them.
Aren't they manual merge tools? I think "merge" is for merging automatically,
and moaning about conflicts if they turn up - /then/ you go to tortoisemerge.
As I said, I am not conducting hg-vs-git discussion. I just happened
to introduce and manage VC system in corporate environment, so I am able
to point that this is important feature.
I appreciate that - I don't want to start a fight. My point should probably
have been more directly focussed on git (which was what I wanted to do) -
it's my opinion that git is in fact easier than Mercurial; however, it's
public face is not letting people see that.
quoted
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 am not quite sure how can you forbid johny to see the code
in ./secret, while johny must checkout whole repo...
Me either - the only permissions that could have been relevant are those
needed to push to the central repository. As I said, git can cope there
without trouble.
Permissions are not only about writing.
That one is true - perhaps one day git will get partial clone support to match
it's shallow clones - then it would be possible to put permissions on the
read of a central repository. Can Mercurial do that?
quoted
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...
I'm not an expert in Windows by any means - all I did was run setup.exe and
picked git and ssh from the list. It doesn't get much easier.
Let me retype it: I am not complaining. GIT developers are not forced to
think about win users, or about corporate needs. But if they are, it is
reasonable to know the problems.
Absolutely - I certainly haven't taken anything you've written as a complaint.
If anything I find it interesting because I think it confirms what I
thought - git is not short on features or usability, it's just got a PR
problem.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Marcin Kasperski [off-list ref] wrote:
quoted
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.
quoted
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Shawn O. Pearce on 4/20/2007 12:22 AM:
quoted
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.
Please report these sorts of bugs to the cygwin list, so that the cygwin
team can be aware of them and work towards fixing them.
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.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGKLoa84KuGfSFAYARAlVwAKCL++zyeKO5iomF/gUQuRP6+N5qkgCfZpHa
3OrAwLmpJ4IbFpUiuj27jRw=
=Dyjw
-----END PGP SIGNATURE-----