On 06Apr2016 18:49, derek martin <inva...@pizzashack.org> wrote:
On Tue, Apr 05, 2016 at 11:04:59AM -0700, David Champion wrote:
OK - that's a good track to have. The thing that made me think otherwise
was the removal of hg-related components. Kevin has the final say now
but we've never discussed moving to git, and I don't see what doing
so would accomplish particularly other than allow/make people use one
hosting system instead of another.
The one thing I see is that git is far more popular than Mercurial,
which means that many more developers know it. Personally, I use
neither, but I'd be a lot more inclined to learn git as I can see
doing so would have far greater value to me. I say this to provide an
example, not because I think that what I think matters more than what
others do (though, clearly, it does). =8^)
Just to this: I'm a Mercurial person. I think git's command line sucks - it is
incredibly noisy (lots of goofy options, etc). They're pretty much feature
equivalent, but hg has a great deal builtin (or supplied as extensions, which
are shipped as standard but disabled until the user flips a config). Git seems
to have an unruly heap of extra commands on the side.
Disclaimer: my git experience is quite limited (because I run from it in pain
every time I go near it) but that will be changing quite soon - starting a job
where git is the tool.
I think choosing git vs hg should not be a "what is more popular" decision,
_especially_ for projects (versus users individually). IMO opinion hg is
superior. Also, there's a robust hg-git extension that will talk to git
repositories using hg.
IMO the reason git is more popular is that (a) the linux kernel uses it and
everybody is a Linus fan (myself less so) and (b) everybody thinks "git is more
popular, use git".
Summary: casting a vote against "git is far more popular than Mercurial" as a
good criterion for choosing or changing.
Having said all that, I _strongly_ recommend learning hg or git. A DVCS is
incredibly useful - you can work offline, you can branch/fork freely, merging
is easier etc etc. Just a superior way to manage code across the board.
For example, my public code is here (almost entirely):
https://bitbucket.org/cameron_simpson/css/commits/all
but I don't work off that - I publish to that. I can work offline - my primary
is on my laptop, and I can code and commit offline (such as on a train - I have
semiregular 4+ hour train trips and being able to work or read and reply to
email is excellent).
[ BTW, I'm a microcommitter - the merge lines are where you see the macro
commits, on the whole. ]
You can also see there that I have feature branches where I can hack on one
subproject or another without breaking the main tree.
Recommendation #2 is to learn _one_ of hg or git first, and then commit to
learning the other. Why? Because they have terminology differences (for which I
blame Linus, frankly). Pull vs fetch (swapped), branches vs bookmarks (a branch
in Mercurial is a permanent named thing, and bookmarks are ephemeral
conveniences - in git "branches" are emphemeral conveniences), etc. So get one
straight in your head before the other. (And you don't need to "name" a
branch/fork - you can just clone and work in the clone, it is trivial).
But I ramble.
Cheers,
Cameron Simpson <c...@zip.com.au>
