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

111–120 of 128 posts

Re: Mercurial 4.0 Sprint Notes

#111

Post by agentgt »

z3t4 wrote: post #44
pierrebai wrote: post #37

Earlier quoted context omitted.

Then maybe you can answer a few questions: - Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not ready to move to external library version N but project Y needs version N? - What about release branches? If you need to intergrate a bug-fix in a sub-system, the magic mono-repo now means merging a fix is harder as it may…

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 guarantee would be pissed if you checked in all your dependencies).

> I think its insane not to have dependencies and third party code in your scm

Consequently there are some that might think the complete opposite (I wouldn't assign insanity but I would say it probably in most cases is not the right thing to do).

Re: Mercurial 4.0 Sprint Notes

#112

Post by jgalt212 »

mkj wrote: post #90
jgalt212 wrote: post #87

Earlier quoted context omitted.

> 25 years of history Why do you need to keep all 25 years of commits?

Because it's useful to figure the intent of strange-looking code that was last touched 15 years ago. (Don't know the parent's situation, but that's the case for me here. Perforce isn't too bad for that)

I heard you. But for me, sometimes it's better just to start fresh than to try to figure out the intent of some ancient history. In this case, I guess that's BDD over TDD.

Re: Mercurial 4.0 Sprint Notes

#113

Post by agentgt »

RandomOpinion wrote: post #75
lucideer wrote: post #8

Earlier quoted context omitted.

The biggest technical difference is the mostly immutable history, which is a feature or a drawback depending on who you talk to. More subjectively, most people I've chatted to about it seem to find Mercurial's interface much easier to grok / pick up as a new user than Git's (which is somewhat notorious for its quirks). There are other differences, but these stand out to me. That said, I use Git because adoption + com…

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 :)

Re: Mercurial 4.0 Sprint Notes

#114

Post by jjnoakes »

cyphar wrote: post #104
jjnoakes wrote: post #68

Earlier quoted context omitted.

I'm not advocating one way or the other, 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. Now it probably isn't worth the effort for a very well tested project like sqlite, but that doesn't validate the premise.

> 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).

Re: Mercurial 4.0 Sprint Notes

#115

Post by shoover »

johnjuuljensen wrote: post #97
marcinkuzminski wrote: post #53

Earlier quoted context omitted.

What's you best KILN feature ? I wonder if we can adopt it at RhodeCode

Kilns biggest omission, which is what made me choose Bitbucket, is the lack of branch pull requests. Kilns commit-based PRs are useless in a feature branch workflow. Bitbuckets code review implementation doesn't handle big changes gracefully though, so I primarily inspect the changes in Beyond Compare.

True. As a workaround you can bridge your feature branch workflow to Kiln reviews by using the kiln extension locally with the push command to attach the changesets to a review, as in:

    hg push --review -r [REV|BOOKMARK|BRANCH]
Theoretically. The extension seems to be broken with respect to hg 3.8 and with the Kiln API itself.

Re: Mercurial 4.0 Sprint Notes

#116

Post by gecko »

johnjuuljensen wrote: post #97
marcinkuzminski wrote: post #53

Earlier quoted context omitted.

What's you best KILN feature ? I wonder if we can adopt it at RhodeCode

Kilns biggest omission, which is what made me choose Bitbucket, is the lack of branch pull requests. Kilns commit-based PRs are useless in a feature branch workflow. Bitbuckets code review implementation doesn't handle big changes gracefully though, so I primarily inspect the changes in Beyond Compare.

What's hilarious/sad to me is that Kiln started out (as the prototype that won Django Dash) doing only pull requests. That was literally all it did. Pushing directly to a repo would instead, behind-the-scenes, make a branch repo and put your commits there. When you accepted the review, it'd automatically get merged. Kiln would even warn you if you could safely do the merge without conflicts. This was all back in 2008, and I believe predated GitHub launching entirely, but certainly predated PRs being common.

Hilariously, we concluded internally that doing things that way was too complicated/weird for people to use, while GitHub concluded the exact opposite, and the rest is what you see.

Re: Mercurial 4.0 Sprint Notes

#117

Post by jordigh »

jjnoakes wrote: post #107
lucideer wrote: post #82

Earlier quoted context omitted.

In git you can edit past commits and rebase, which completely destroys historical data and traces of the rebase. This can be very useful, e.g. for keeping a frequently-committed-to branch "clean" and informative by squashing commits, for removing accidentally committed sensitive credentials, etc. Mercurial, on the other hand, is architecturally set up in a way that considers the repo history to be a somewhat "sacred"…

I'm sorry, I still don't see the distinction. It sounds like in both systems the default is immutability, with commands to override that if necessary. And by the way, doesn't git rebase not mutate history? I believe it creates a parallel history (and updates the branch and head refs to point to the new history) but the old history still exists in git's storage and can be recovered (until you GC your storage).

In git, you `git rebase` any commit will always do whatever you tell it to do.

In Mercurial, `hg rebase` will abort if you're trying to make it do something to public commits. Public commits are commits that have been shared on a publishing server. The contrast with draft commits, which are commits that have not been shared or only shared on a non-publishing server.

If you really want to edit public commits, you have to manually force them back to the draft phase before you can rebase or rewrite them.

Re: Mercurial 4.0 Sprint Notes

#118

Post by jjnoakes »

jordigh wrote: post #117
jjnoakes wrote: post #107

Earlier quoted context omitted.

I'm sorry, I still don't see the distinction. It sounds like in both systems the default is immutability, with commands to override that if necessary. And by the way, doesn't git rebase not mutate history? I believe it creates a parallel history (and updates the branch and head refs to point to the new history) but the old history still exists in git's storage and can be recovered (until you GC your storage).

In git, you `git rebase` any commit will always do whatever you tell it to do. In Mercurial, `hg rebase` will abort if you're trying to make it do something to public commits. Public commits are commits that have been shared on a publishing server. The contrast with draft commits, which are commits that have not been shared or only shared on a non-publishing server. If you really want to edit public commits, you have…

If you "git push" after rebasing published commits, you get an error, unless you use "--force" or you pull and merge manually before hand.

So I'm still not sure the distinction you are making between which one is "immutable" and which one isn't.

Re: Mercurial 4.0 Sprint Notes

#119

Post by jordigh »

jjnoakes wrote: post #118
jordigh wrote: post #117

Earlier quoted context omitted.

In git, you `git rebase` any commit will always do whatever you tell it to do. In Mercurial, `hg rebase` will abort if you're trying to make it do something to public commits. Public commits are commits that have been shared on a publishing server. The contrast with draft commits, which are commits that have not been shared or only shared on a non-publishing server. If you really want to edit public commits, you have…

If you "git push" after rebasing published commits, you get an error, unless you use "--force" or you pull and merge manually before hand. So I'm still not sure the distinction you are making between which one is "immutable" and which one isn't.

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 propagate meta-history to other users that indicates what commits replace which ones.

Re: Mercurial 4.0 Sprint Notes

#120

Post by jjnoakes »

jordigh wrote: post #119
jjnoakes wrote: post #118

Earlier quoted context omitted.

If you "git push" after rebasing published commits, you get an error, unless you use "--force" or you pull and merge manually before hand. So I'm still not sure the distinction you are making between which one is "immutable" and which one isn't.

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.

Post reply on HN