Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mercurial 4.0 Sprint Notes

groups.google.com

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Mercurial 4.0 Sprint Notes

#121

Post by jordigh »

jjnoakes wrote: post #120
jordigh wrote: post #119

Earlier quoted context omitted.

Phases catch this problem early before `git push`. You don't want to run into the problem too late. Then you'll be faced with the decision to throw out your work because you accidentally rewrote something that should not have been rewritten. Or you'll have to decide at the last minute that you really did mean to make problems for everyone else. Btw, with Mercurial Evolve, there's no need to force-push, as Evolve will…

Ok so it has nothing to do with immutability, it's just one warns earlier than the other. Thanks for clarifying.

It is about immutability. No Mercurial command (histedit, rebase, uncommit, amend) will allow you to change an immutable (public) commit unless you first force it back into the draft phase.

You can say that because you can always force public commits into drafts that they're not really immutable, but that's a bit of a perversion of what Mercurial's phase system is intended to do.

Re: Mercurial 4.0 Sprint Notes

#122

Post by jjnoakes »

jordigh wrote: post #121
jjnoakes wrote: post #120

Earlier quoted context omitted.

Ok so it has nothing to do with immutability, it's just one warns earlier than the other. Thanks for clarifying.

It is about immutability. No Mercurial command (histedit, rebase, uncommit, amend) will allow you to change an immutable (public) commit unless you first force it back into the draft phase. You can say that because you can always force public commits into drafts that they're not really immutable, but that's a bit of a perversion of what Mercurial's phase system is intended to do.

And no git command lets you change what public history looks like unless you --force the push.

So the check is in a different place. That doesn't seem to me to imply that Mercurial's history is "immutable" and git's is "mutable", especially since those words have precise meanings, and even WITH the --force, git doesn't change anything in the history, it just writes out a new history and updates the branch ref to point to the new history.

The only thing mutated (in both systems) is the ref to the branch head, right? So aside from warnings and errors being in different places (both before publish time), what is the difference between the two that leads you to argue that one is immutable and one isn't?

Re: Mercurial 4.0 Sprint Notes

#123

Post by marcinkuzminski »

jjnoakes wrote: post #122
jordigh wrote: post #121

Earlier quoted context omitted.

It is about immutability. No Mercurial command (histedit, rebase, uncommit, amend) will allow you to change an immutable (public) commit unless you first force it back into the draft phase. You can say that because you can always force public commits into drafts that they're not really immutable, but that's a bit of a perversion of what Mercurial's phase system is intended to do.

And no git command lets you change what public history looks like unless you --force the push. So the check is in a different place. That doesn't seem to me to imply that Mercurial's history is "immutable" and git's is "mutable", especially since those words have precise meanings, and even WITH the --force, git doesn't change anything in the history, it just writes out a new history and updates the branch ref to poin…

I think what Mercurial brings here is that even if you have a repo and you do a force-push you keep all the heads. Thus it's almost like a history of changes.

I think if you do a code-review and you get the final state of the repo to check, you can nicely tell how it was evolved/squashed/re-ordered.

I find that workflow much more useful than just rewriting history like in git (i know about reflog)

Re: Mercurial 4.0 Sprint Notes

#124

Post by arunc »

awinder wrote: post #9
the_duke wrote: post #6

I had no idea Google and FB were dabbling with Mercurial. I checked it out years ago, but pretty much settled on Git. What are the advantages?

If you have a ton of files inside of one gigantic repo, the work facebook is doing on mercurial might help you out. If you live in a saner world though, you'll probably benefit more from git's superior cli & tooling

Mercurial CLI is safe by all means! I have never lost a commit in hg. Git CLI is an abomination and is a nightmare to deal with. As a colleague of mine said once, "It is easy to develop programs than to use version control them using git".

Re: Mercurial 4.0 Sprint Notes

#125

Post by arunc »

glandium wrote: post #70
steveklabnik wrote: post #2

Relevant quote: > Facebook is writing a Mercurial server in Rust. It will be distributed and > will support pluggable key-value stores for storage (meaning that we could > move hg.mozilla.org to be backed by Amazon S3 or some such). The primary > author also has aspirations for supporting the Git wire protocol on the > server and enabling sub-directories to be git cloned independently of a > large repo. This means yo…

It's interesting they're doing this in Rust. I would have expected them to do it in D.

Warp [0], which was a huge marketing win for DLang is not maintained anymore. Not sure if it is being used at all. Will there be any D projects in Facebook?

[0] https://github.com/facebookarchive/warp

Re: Mercurial 4.0 Sprint Notes

#126

Post by cyphar »

jjnoakes wrote: post #114
cyphar wrote: post #104

Earlier quoted context omitted.

> but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent. It's 100% branch coverage, with 100% fault coverage as well. If there is an "issue lurking that a safer language would prevent" I would honestly be shocked. SQLite is not a good project to mention rewriting, because it is an incredible technical acheivement in terms of how well test…

> SQLite is not a good project to mention rewriting Which, as I said, is not what I'm doing. I'm only disagreeing with the premise that 100% test coverage means 0% chance of an unsafe bug existing in the code base (for any code base, not just for SQLite).

Personally, I consider 100% branch coverage to mean an effectively 0% chance of an unsafe bug existing in the code base. Does Rust have 100% branch coverage in their compiler? So how can you be absolutely sure their compiler doesn't have bugs when doing borrow checking and other tomfoolery? 100% branch coverage is an _insanely_ high standard and you can't compare it to any other project unless that project also has 100% branch coverage or similar.

Re: Mercurial 4.0 Sprint Notes

#127

Post by z3t4 »

agentgt wrote: post #111
z3t4 wrote: post #44

Earlier quoted context omitted.

I think its insane not to have dependencies and third party code in your scm. Although it seems facebook plan to move those to a package manager due to performance problems and libs touching ten thousand files in a path release.

Yes but the question is where do you stop. Are you going to check in GNU Make and the compilers as well? How about whole operating systems? I also would say "only check in what you change" is a simpler rule than "check in all dependencies needed". I understand company source code needs to be different because of security reasons and convenience but should it really be that much different than any OSS project (which I…

It all depends. Google might want to keep track of the full stack, whereas your average small software company will quickly adapt when their platform pulls the rug.

Re: Mercurial 4.0 Sprint Notes

#128

Post by RandomOpinion »

agentgt wrote: post #113
RandomOpinion wrote: post #75

Earlier quoted context omitted.

To add my 2 cents, immutable history is more of an annoyance than anything. If someone checks in something by mistake that absolutely must be removed (e.g. something that contains a password), it is a considerable undertaking to actually remove that commit from the repository.

It is not hard once you know how to do it is just not readily documented (ie histedit and force push). BTW if you checked in a password... you really should now go change that password :)

I know better than to check in passwords, thank you very much. Regrettably, some of my colleagues do not.
Post reply on HN