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

Mercurial 2.9 released

mercurial.selenic.com

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Mercurial 2.9 released

#71

Post by jordigh »

Skinney wrote: post #46
toggle wrote: post #11

Earlier quoted context omitted.

For me, it's: 1. The queues extension. 2. A bazillion other extensions. 3. The source code is pretty reasonable -- even mortal humans can contribute and write their own extensions. I've found the queues extension to be really useful. It's like having multiple staging areas, which will later become multiple commits. I tend to change too many things, and then remember that I need to create specific commits. Queues make…

git stash? Actually, you can also just create a branch, commit your work (instead of hg qpush) and just use git rebase --interactive when you want to "finalize" your work.

The exact same workflow works pretty much the same way in hg, with shelve (stash) and histedit (rebase -i). There is even a better way nowadays with hg evolve, but it's still beta.

Re: Mercurial 2.9 released

#72

Post by jordigh »

Skinney wrote: post #47
mamcx wrote: post #22

Earlier quoted context omitted.

I consider hg far more easy to use than git, specially for the most used commands (status, fetch, push). I need to check the docs about how do the damm push each time with github. My only gripe with mercurial? That everyone else asume git.

check the docs? What is so hard to remember about "git push"?

This:

    jordi@Iris:~$ git help push | wc -l
    544
    jordi@Iris:~$ hg help push | wc -l
    50

Re: Mercurial 2.9 released

#73

Post by Skinney »

jordigh wrote: post #71
Skinney wrote: post #46

Earlier quoted context omitted.

git stash? Actually, you can also just create a branch, commit your work (instead of hg qpush) and just use git rebase --interactive when you want to "finalize" your work.

The exact same workflow works pretty much the same way in hg, with shelve (stash) and histedit (rebase -i). There is even a better way nowadays with hg evolve, but it's still beta.

Hows the backup story with Hg nowadays? Git uses an immutable storage solution, so rebasing or other commands to alter history doesn't delete anything. Hg doesn't have the same architecture, so how does undoing histedit work? Genuinly interested, not trying to start a flamewar.

Re: Mercurial 2.9 released

#74

Post by Skinney »

jordigh wrote: post #72
Skinney wrote: post #47

Earlier quoted context omitted.

check the docs? What is so hard to remember about "git push"?

This: jordi@Iris:~$ git help push | wc -l 544 jordi@Iris:~$ hg help push | wc -l 50

This is due to Git's tight integration with regards to branches and namespaced branches though isn't it? Hg push isn't aware of bookmarks as far as I know, so Git has more to explain compared to Hg, where lightweight branches are a plugin. Or am I wrong on this?

Re: Mercurial 2.9 released

#75

Post by polarix »

anton_gogolev wrote: post #52
polarix wrote: post #36

I would LOVE to use mercurial. If the concept of a backup bundle was completely removed. When I amend a commit with git, I don't put myself 20 minutes away from recovering that pre-amend commit. If hg comes up with some way to have a flat namespace like git, (ideally with a reflog) I'll be back.

That whole "back up a part of history so that you could undo stuff later" will be gone as soon as Changeset Evolution [1] is ready. An when it's ready, it will be tremendous. [1]: http://mercurial.selenic.com/wiki/ChangesetEvolution

That does indeed sound like it solves the problem. Bravo, can't wait!

Re: Mercurial 2.9 released

#76

Post by jordigh »

Skinney wrote: post #74
jordigh wrote: post #72

Earlier quoted context omitted.

This: jordi@Iris:~$ git help push | wc -l 544 jordi@Iris:~$ hg help push | wc -l 50

This is due to Git's tight integration with regards to branches and namespaced branches though isn't it? Hg push isn't aware of bookmarks as far as I know, so Git has more to explain compared to Hg, where lightweight branches are a plugin. Or am I wrong on this?

Wow. I use Mercurial so much, that I forget that some people have no idea about it at all.

No, hg bookmarks are not a plugin, although they were like four years ago. Hg push has this to say about bookmarks:

     If -B/--bookmark is used, the specified bookmarked revision, its ancestors, and the bookmark will be pushed to the remote repository.
That's all it has to say. If you do "hg help bookmarks", you'll get more options about bookmarks, but they're not immediately relevant to pushing.

Re: Mercurial 2.9 released

#77

Post by Skinney »

jordigh wrote: post #76
Skinney wrote: post #74

Earlier quoted context omitted.

This is due to Git's tight integration with regards to branches and namespaced branches though isn't it? Hg push isn't aware of bookmarks as far as I know, so Git has more to explain compared to Hg, where lightweight branches are a plugin. Or am I wrong on this?

Wow. I use Mercurial so much, that I forget that some people have no idea about it at all. No, hg bookmarks are not a plugin, although they were like four years ago. Hg push has this to say about bookmarks: If -B/--bookmark is used, the specified bookmarked revision, its ancestors, and the bookmark will be pushed to the remote repository. That's all it has to say. If you do "hg help bookmarks", you'll get more option…

It is still a plugin, it's just bundled/installed by default. I've worked with Mercurial for the better part of a year, I'm not clueless about it.

But yeah, since branches/bookmarks are an integral part of how you work with Git, you also have more options regarding branches/bookmarks in several git commands. Git allows you to push a local branch to a remote branch of a different name. This is helpfull when you're pushing to different remotes, and the some of the local branches should map to master on different remotes. But this of course requires more information to stand in git pull's documentation. There are, of course, other features as well.

Just because git push has some 'advanced' featues, doesn't make the actual push command difficult to understand though. Most of the time you just use 'git push', same as Mercurial, git just allows you to do more with git push than what Mercurial allows you to.

Re: Mercurial 2.9 released

#78

Post by tomlu »

tonfa wrote: post #59
tomlu wrote: post #35

Earlier quoted context omitted.

I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.

But then mercurial is the same, the abstraction is about file content, the diff compression is an internal detail of the storage format like packs.

Yeah for sure. Mercurial is great too.

I was thinking of SVN which does store its commits as diffs, which makes it brittle (anyone that has tried to use the svn admin tools to rewrite the repository will know what I mean).

Re: Mercurial 2.9 released

#79

Post by voidr »

ender7 wrote: post #27
pekk wrote: post #19

Earlier quoted context omitted.

What a contentless comment. One might just as well flatly claim that mercurial isn't nice for anything.

git's CLI design is byzantine and inconsistent, with terms that are both overloaded and underloaded (many commands do multiple, unrelated things while at the same time many common tasks do not have commands). It's very easy for newcomers to place their local repo into a limbo or failure state that they can't get out of without consulting a git guru. git's error messages and man pages are written for its developers, n…

For the average user, git and mercurial have similar commands, a lot of the time you could just replace `git` with `hg` and it works.

I also don't believe that mercurial has a 'cleaner UI', especially when it comes to merge.

For advanced users, git has a lot more to offer by default, you need to install a boatload of extensions on hg to achieve the same functionality.

Post reply on HN