191–200 of 219 posts
Prior to this I tried cgit (I really like how it looks) and gitolite. I even bought a book on gitolite configuration and couldn’t figure that out.
Oh well.
On topic, it’s great that Mercurial users have an alternative that’s not Github.
Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.
Java OpenJDK development has been on Mercurial, and ponders moving to Git. In typical OpenJDK-fashion, the process is thoroughly examined and discussed. More information in for example * https://openjdk.java.net/jeps/357 * https://github.com/openjdk/skara * http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-2019... .
Not strictly a Mercurial issue, but using the platform that your audience is already familiar with has a lot to recommend it.
Earlier quoted context omitted.
Are you going to say there is not even a distributed no-SQL cluster behind this? Well, I can understand the UI part, but there are limits...
Local config for static stuff and postgres yes-SQL. I assume it doesn't scale extremely easily but seems to work good enough for now.
YesSQL scales just fine to enterprises like VCS repo hosting. All you have to do is shard correctly (along the lines where you least need the power of SQL, preferably).
Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
Technically I think Mercurial would be better for engineering wise in the long term. Mercurial has a single implementation (Git has 5), and they greatly discourage anyone from implementing a second. This gives them a single source of truth for the implementation. Mercurial has better hooks in place. If a company (such as Google or Facebook) wants to change the behavior of an action, they can override or hook into a s…
I don't see why. I've seen companies switch from Mercurial to Git even though many employees loved Mercurial -- the driver was the fact the new employees were much more likely to prefer Git or not even know what Mercurial is. Mindshare matters.
> Mercurial has a single implementation (Git has 5),
Eh? I very much like that there are multiple Git implementations. Besides choice, this means there are more people who really understand its guts and can support it and its implementations.
> and they greatly discourage anyone from implementing a second.
That's not a good thing.
> This gives them a single source of truth for the implementation.
That gives them too much power to make changes the users might not like.
> Mercurial has better hooks in place.
Sounds like one of the ways in which Git implementations might differentiate from each other.
> It had better windows support than Git did for a long time. I believe it is still better because you don't rely on MinGW or some other Linux abstraction layer (though it uses python).
MSFT is doing amazing work on Git on Windows, making it scale in ways no other distributed VCS is likely to any time soon without adopting similar ideas. If you want Windows support, then Git is going to rock your boat more than Mercurial soon if not already.
Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
We're currently migrating all of our mercurial repos to git. The migration is trivial and retains the full history. After working with mercurial for the last four years, I don't think it offers anything that git doesn't. I've found that mercurial works fine, though simple things like lightweight branching require extensions and goofy workflows (the evolve extension, topics). Integration with third-party tools and ser…
Serious questions... What does mercurial offer that git doesn’t? Is the transition to git difficult for projects currently housed in a mercurial repository?
There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient th…
There are extensions that cover more advanced cases, too, such as creating/reviewing Github PRs, reviewing the commit graph, etc.
I literally forgot about Mercurial. It’s been years since I’ve even heard it mentioned. Are there any strong arguments for using it over Git these days? Is this just about supporting legacy code bases. I’m sure there must be a way to migrate to Git [and maintain history]. I’m not trolling, I would love to hear from someone who prefers Mercurial over Git as to how it benefits them.
Mercurial simply stayed my secret tool for version control, without anyone noticing.
- the command line is unsurprising and coherent - the UX in the terminal is nice (with tweakdefaults=true, you have colored word diffs, and nice curses interface for commit, uncommit, amend, --interactive) - integrated web ui via "hg serve" - compatible with git. There are margin for improvement here: hg-git can do everything but you have to be an advanced user. - advanced workflows are not only possible, but easier and safer, due to non destructive history editing - TortoiseHg is a honest GUI. Most advanced workflows are even easier there. Works on windows, so it's a good way of introducing less advanced users to version control.
They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS? There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future.
It's written in Python so as soon as they have enough users it will be as slow as any webpage with tons of JS. Thankfully, that CPU load won't be on the client side... so it's still an improvement
Earlier quoted context omitted.
There are a few good things about it compared to git (and a few bad ones). One I like is that it has an excellent GUI that is cross platform, called TortoiseHg. I know hackers can be a bit snobbish about GUIs but I really think a GUI is essential for version control: flicking through the revision graph in one pane while looking at the modified files in another and a file's changes in a third is much more efficient th…
Finding a decent GUI is definitely the biggest pain point in switching to git for us. It's not just that git GUIs are lacking generally, it's that there's fragmentation - the best ones on one OS don't necessarily work on other OSs. Tortoisehg was so universal that it practically was mercurial, for the purposes of many users. We are scientists and wanting to attract contributions to our code from other scientists and…