501–510 of 543 posts
Earlier quoted context omitted.
I'm sort of amazed that git and mercurial haven't built something like that yet. Makes me a little sad that Facebook created a new scm instead of expanding mercurial to include features like this.
just type `hg serve` and that will spin-up a web UI like this one: https://www.mercurial-scm.org/repo/hg/graph/tip , seems to have been included since 2005 :)
Hi Hacker News! Author of the Sapling blog post here. I'm happy to answer any questions you might have.
Earlier quoted context omitted.
Still not quite the same, because absorb splits up your working directory changes into all relevant commits, as deduced by diff context.
Staged or unstaged? Sounds interesting, will give it a try. Thanks for the details.
Staged changes, excluding renames.
So git-fixup and git-absorb will now happily live together for the moment on my box.
Made a good first impression, thanks again for the reference.
This serves a very weird niche. Reading through the docs, this seems just as complex to operate as git, but designed with less decentralized operations in mind. Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? Because GitHub pull requests are terrible? None of this makes any sense to me. > Local branch names are optional. As are they in git, just hang out with a detached HEAD.…
> Why not just use mercurial if you want to use mercurial? Why invent this... monstrosity? But this is mercurial. Or rather, it's mercurial rebased on top of the git data store, and it's a fork with breaking changes so it has a different name. I do agree that the requirement to be online gives me pause. But I guess I don't know how much of a problem that would be in practice, since there's a mystery subset of functio…
Same.
Earlier quoted context omitted.
Technically the mercurial pre and post hooks are mostly still there, but I'm not certain we want to support them long term. The existing hook design has some problems. I'd be curious about your use case, since we don't actually use hooks internally all that much.
Not the OP, but I've worked on a bunch of projects which use https://pre-commit.com/ that ties into git pre-commit hooks (or https://typicode.github.io/husky/#/ is another) usually to run linters and validators, speeding up the feedback loop (otherwise it's annoying to push changes to a PR and then get a CI failure minutes later for trivial linting issue)
Earlier quoted context omitted.
> and there are still those of us who actually use Mercurial I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...
Yeah, we should give a shout-out to the octobus folks for making heptapod, a Gitlab fork bringing support for mercurial repos. That brings at least one mainstream hosting option for hg repos.
hg init
git init --bare
Earlier quoted context omitted.
> and/or have giant amounts of binaries in their repos. Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems. Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the…
In fairness, there is git LFS, which is a well-maintained solution to do this. It's not fantastic, but it does exist.
A bit like submodules, LFS has its own warts that seem to multiply when you add more people to the mix. Working with git LFS has been the _only_ time the solution to my problem has been "nuke and clone again", in almost 15 years using source control.
Last time I used git LFS, it didn't support ssh cloning at all, and the issue had been open for years at that time.
Earlier quoted context omitted.
The simple reason is that Mercurial and git were way too slow for large repos, and FB wanted a monorepo for productivity reasons. It's cheaper to fund this project than reduce engineering productivity by even 1% at the scale of FB. Google did exactly the same thing, but hasn't open-sourced their tools. Projects to drive incremental productivity make not a lot of sense for small companies, but become immensely valuabl…
Just as "inventing your own source control system" is a hobby, "being a very large engineering organization" is a hobby. FB and Google started with infinite money spigots and used it to hire a lot of people who make a lot of commits; if you laid them off, or if you canceled half the remaining Google products they haven't already canceled, not all that much would change.