3 ms·

For anyone that thinks Git is too complicated, consider using Mercurial. Anyone that wants to use TYOOL 2016 age DVCS features should also switch. Like changin

by gcp 10y ago

For anyone that thinks Git is too complicated, consider using Mercurial. Anyone that wants to use TYOOL 2016 age DVCS features should also switch. Like changing history yet still keeping a record of the original one (hg evolve). Git completely owned all other DVCS with good branching. 10 years ago. But now it's time to move on to better tools.

dmitry-k 10y ago
At RhodeCode (https://rhodecode.com https://rhodecode.com) we believe it's up to a team to decide, which version control better fits their needs and preferences. Some companies even have Git, Mercurial, and SVN, working all together under centralized repository management.
- glandium 10y ago
  I, personally, believe it's up to a user to decide which version control system works best for them. Both git and mercurial can talk to "non-native" remote servers. IIRC mercurial can talk to subversion and git (with hg-git). Git can talk to subversion, cvs, perforce, mercurial (there are multiple tools for the latter, and I'm the author of one of them), bzr, and maybe others. If things don't work smoothly in any of those cross-VCS configurations, my belief is that issues should be filed and fixed.
  - dmitry-k 10y ago
    Agree. However, large enterprises usually have common compliance/access control policies, something not easily implemented across multiple VCS (unless there's a full-fledged internal development team dedicated to that). Working in a big firm adds overhead, yet has certain benefits (resources, etc.). That's a whole different topic though.
glandium 10y ago
The usefulness of hg evolve is debatable. It can be useful locally, as much as the reflog can be useful in git, but as soon as you push to the upstream repository, you lose that precious history if you haven't pushed it priorly. Worse yet, the reference to that history is still there in what you pushed, despite being nowhere to be found except in your local clone, making it useless to others.
- develop7 10y ago
  That's true in case you've created some changesets, played with them locally and pushed them upstream. But, say you've played with changesets already available upstream, the unmodified changesets do not go away.

by gcp 10y ago

dmitry-k 10y ago

At RhodeCode (https://rhodecode.com https://rhodecode.com) we believe it's up to a team to decide, which version control better fits their needs and preferences. Some companies even have Git, Mercurial, and SVN, working all together under centralized repository management.

glandium 10y ago
I, personally, believe it's up to a user to decide which version control system works best for them. Both git and mercurial can talk to "non-native" remote servers. IIRC mercurial can talk to subversion and git (with hg-git). Git can talk to subversion, cvs, perforce, mercurial (there are multiple tools for the latter, and I'm the author of one of them), bzr, and maybe others. If things don't work smoothly in any of those cross-VCS configurations, my belief is that issues should be filed and fixed.
- dmitry-k 10y ago
  Agree. However, large enterprises usually have common compliance/access control policies, something not easily implemented across multiple VCS (unless there's a full-fledged internal development team dedicated to that). Working in a big firm adds overhead, yet has certain benefits (resources, etc.). That's a whole different topic though.

glandium 10y ago

The usefulness of hg evolve is debatable. It can be useful locally, as much as the reflog can be useful in git, but as soon as you push to the upstream repository, you lose that precious history if you haven't pushed it priorly. Worse yet, the reference to that history is still there in what you pushed, despite being nowhere to be found except in your local clone, making it useless to others.

develop7 10y ago
That's true in case you've created some changesets, played with them locally and pushed them upstream. But, say you've played with changesets already available upstream, the unmodified changesets do not go away.