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

Git 2.0 release notes

git.kernel.org

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Git 2.0 release notes

#41

Post by klibertp »

simias wrote: post #21
exDM69 wrote: post #19

Earlier quoted context omitted.

> Is it just me or "simple semantics" is not at all simple? It's just you. It's about time we'd put "hg vs. git" to the category of flamebait topics (similar to "emacs vs. vi" etc) that should be avoided. Every time there's a git topic, someone comes and derails the whole discussion with a not-quite-apt comparison with hg. AFAIK, there are decent two-way conversion tools so you can use hg with a git repo and vice ver…

So comparing two competing tools is flamebait nowadays? I think the OP makes a valid and argumented point.

It is if there was no new development in the tools and/or the comparison just repeats what has been said thousands of times already.

This (root) comment here is a good example: it isn't in any way related to the new developments in Git, repeats very basic comparison done many times already and fails to account for deeper differences and options (like the fact that you can easily configure git to make git push do exactly what you want).

It would be good for overall discussion quality if posts such as these were kept separate from the interesting stuff.

Re: Git 2.0 release notes

#42

Post by acdha »

ygra wrote: post #40
jgraham wrote: post #39

Earlier quoted context omitted.

Also, mercurial has mq, which adds a whole extra layer of complexity. Instead of making safe commits, you continually update ("refresh") a set of patch files. Each time you refresh you lose all the history (as if you exclusively used git commit --amend for work in progress). In order to solve this someone got the idea that the patch queue itself could be versioned by creating a second repository that you would commit…

To be fair, mq is needed only for very few specialised needs (apart from strip, maybe). Most hg users can get by just fine with never enabling it at all.

For years the Hg community proclaimed it was the answer to git rebase. Might be time for a concerted doc push to get those references updated with pointers to the rebase extension instead.

Re: Git 2.0 release notes

#43

Post by sampo »

Skinney wrote: post #31
egork8n wrote: post #26

Earlier quoted context omitted.

You just need to visualize the tree, and that's it. `hg push -r .` will push checked out changeset and all its ancestors. Mercurial tracks changesets. Git guys are inventing all kings of weird entities. Local branch? Mutable branch? Do these kind of things have separate sets of semantics in the git world? In mercurial, branch is just a constant name for a group of changesets. Bookmark is just a temporary pointer to t…

All branches can change, and are mutable in that regard (altough commits can't change). Local branch == Bookmark with unpushed changesets All branches and commits/changesets are treated equal. Yeah. In mercurial you have Branches and Bookmarks. In git you just have branches. Head is the current checked out commit/changeset. Git doesn't allow you to alter commits, only branches, so every modification in Git is inheren…

> In mercurial you have Branches and Bookmarks. In git you just have branches.

I think git branches correspond more to hg bookmarks, than to hg named branches.

Re: Git 2.0 release notes

#44

Post by krig »

anton_gogolev wrote: post #32
krig wrote: post #29

Earlier quoted context omitted.

Those are all Mercurial concepts.

Well, no. These are _at most_ the names of various third-party extensions, which are not even distributed with Core. Mercurial itself has just heads, which can be named or not. Bookmarks are orthogonal to the whole thing.

Mercurial without enabling extensions such as mq is simple only in the same sense that quilt is simple compared to git. Things quickly become more complex as you try to actually use it and need to enable extensions to do what you can do with git out of the box. The big benefit that git has over mercurial is that it has a powerful and expressive (and yes, complex) core concept. Mercurial quickly becomes a mess of, yes, orthogonal concepts layered on top of each other.

Anyway, you are plain wrong.

* Branches (named and unnamed) are part of core mercurial.

* Bookmarks are part of core mercurial.

* Multiple heads are part of core mercurial.

* Phases are part of core mercurial.

* Secret changesets is part of core mercurial.

* mq is distributed with Mercurial.

* Local branches is an extension that isn't part of core mercurial, I'll give you that. However, calling it a "third-party extension" is pedantic. It's listed on the official mercurial web site, and using extensions is much more a part of every day usage of mercurial than using extensions in git, for example.

edit: formatting.

Re: Git 2.0 release notes

#45

Post by rbonvall »

davidw wrote: post #8
anton_gogolev wrote: post #7

Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where

There was a thing going around twitter lately: > If ping was designed by the git people: net-ping host --no=dns,bind --proto=TCP,rfc:492 eth0@ipv4:: http://1.0.0.127.IN -ADDR.ARPA --stats -v

I think it would be

    git checkout --ping
(Checkout already does too much; one more doesn't hurt).

Re: Git 2.0 release notes

#46

Post by anton_gogolev »

acdha wrote: post #42
ygra wrote: post #40

Earlier quoted context omitted.

To be fair, mq is needed only for very few specialised needs (apart from strip, maybe). Most hg users can get by just fine with never enabling it at all.

For years the Hg community proclaimed it was the answer to git rebase. Might be time for a concerted doc push to get those references updated with pointers to the rebase extension instead.

Answer to rebase in particular (and the whole "Git makes it simple to edit history" argument in general) is Changeset Evolution [1].

[1]: https://air.mozilla.org/changesets-evolution-with-mercurial/

Re: Git 2.0 release notes

#47

Post by kyrra »

acdha wrote: post #42
ygra wrote: post #40

Earlier quoted context omitted.

To be fair, mq is needed only for very few specialised needs (apart from strip, maybe). Most hg users can get by just fine with never enabling it at all.

For years the Hg community proclaimed it was the answer to git rebase. Might be time for a concerted doc push to get those references updated with pointers to the rebase extension instead.

Because it was the answer originally (it's wiki page appeared in 2005, rebase appeared in 2008). Then rebase became the better answer. What proclaimed answer are you referring to here? On their GitConcepts[0] page, it says "hg rebase" or "hg histedit" should be used to do "git rebase" type operations. The only time they recommend MQ is if you want the index or the "git am" type command.

And as anton_gogolev mentioned, ChangesetEvolution[1] will probably help augment HistEdit and Rebase for a number of operations. It will allow pushable history rewriting.

[0] http://mercurial.selenic.com/wiki/GitConcepts

[1] http://mercurial.selenic.com/wiki/ChangesetEvolution

Re: Git 2.0 release notes

#48

Post by matthewmacleod »

anton_gogolev wrote: post #35
matthewmacleod wrote: post #34

Earlier quoted context omitted.

My point is that Git has accumulated too much cruft and has introduced one too many concepts to be usable. Your point is totally invalid, since git is self-evidently successful, and regarded by many people as usable. The "cruft" you've pointed to consists of usable, useful features. So it would be useful to talk more about areas in which git could improve—even if that involves looking at features from Mercurial—rathe…

As much as you want IT world to be a meritocracy, it is not. Very rarely software gets popular based exclusively on its merits. With Git, it gained popularity not because it was terribly usable [1] or generally good (it was not even going to be an SCM [2]), but because it was imposed by Linus onto a pretty large number of developers - kernel hackers, not less - and then it spread from there. [1]: http://marc.info/?l=…

I'm familiar with the history of git.

I'm also aware that nothing you said actually dealt with the fact that git is not unusable. In fact, it's objectively pretty good—if it weren't, we'd all still be using SVN.

What you seem to be saying is that you prefer the UX of Mercurial. Cool, that's fine - but I'd be keen for people to invest their time in improving the experience of using git, rather than bellyaching about perceived differences which aren't really all that big.

(As an aside, I don't really agree that there's a problem with git's usability. It's a complex tool, if you want it to be. But for day-to-day distributed SCM, you'll rarely have to care about most of that.)

Re: Git 2.0 release notes

#49

Post by sanderjd »

davidw wrote: post #8
anton_gogolev wrote: post #7

Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where

There was a thing going around twitter lately: > If ping was designed by the git people: net-ping host --no=dns,bind --proto=TCP,rfc:492 eth0@ipv4:: http://1.0.0.127.IN -ADDR.ARPA --stats -v

That honestly doesn't have the truth ring of good satire for me... It seems to be making fun of the lack of sane defaults in git (maybe?), but if anything, git seems too focused on mysterious implicit configuration-controlled behavior, over explicit control.

Edit: Ah, hmm, maybe the satire is more along the lines of "a single command does too much stuff", which does ring true for commands like `checkout` and `reset`.

Re: Git 2.0 release notes

#50

Post by anton_gogolev »

matthewmacleod wrote: post #48
anton_gogolev wrote: post #35

Earlier quoted context omitted.

As much as you want IT world to be a meritocracy, it is not. Very rarely software gets popular based exclusively on its merits. With Git, it gained popularity not because it was terribly usable [1] or generally good (it was not even going to be an SCM [2]), but because it was imposed by Linus onto a pretty large number of developers - kernel hackers, not less - and then it spread from there. [1]: http://marc.info/?l=…

I'm familiar with the history of git. I'm also aware that nothing you said actually dealt with the fact that git is not unusable. In fact, it's objectively pretty good—if it weren't, we'd all still be using SVN. What you seem to be saying is that you prefer the UX of Mercurial. Cool, that's fine - but I'd be keen for people to invest their time in improving the experience of using git, rather than bellyaching about p…

There are no objective criteria to measure usability, so Git cannot possibly be "objectively pretty good", sorry.

Again, popularity has nothing to do with merit. It's a pure happenstance that Git was chosen over Mercurial for kernel development, and it all went from there.

The UX of Git cannot possibly be improved in the foreseeable future as it will be a _massive_ pile of breaking changes with people moaning all over the internet.

Post reply on HN