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

31–40 of 93 posts

Re: Git 2.0 release notes

#31

Post by Skinney »

egork8n wrote: post #26
krig wrote: post #23

Earlier quoted context omitted.

When you say "the currently checked out branch", do you mean the current branch, bookmark, head, local branch or mutable branch? Or maybe you are referring to the current phase, or a secret changeset? "Mercurial is so much simpler than git" is only true for one reason: You prefer mercurial and dislike git, and so you look for flaws in git while glossing over flaws in mercurial.

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 inherently safe.

Re: Git 2.0 release notes

#32

Post by anton_gogolev »

krig wrote: post #29
anton_gogolev wrote: post #28

Earlier quoted context omitted.

Or maybe it is Git that has introduced all kinds of crazy concepts that you're now struggling to keep in mind? Local branches? Remote tracking branches? Mutable branches? Really?

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.

Re: Git 2.0 release notes

#33

Post by Skinney »

anton_gogolev wrote: post #27
exDM69 wrote: post #22

Earlier quoted context omitted.

I would agree with you if there had been an actual comparison and some arguments for or against one or the other. Now there wasn't. E.g. "git push", similarly to "hg push" - without any extra arguments - do roughly the same thing, "push to the default location". When was the last time you ever saw anything useful or insightful in comments about git vs. hg? There have been a few enlightening blog posts on the subject…

> ...if there had been an actual comparison and some arguments for or against one or the other. What kind of comparison are you after? To be more scientific, let's take "git push where" and "hg push where". Now count the number of ifs and buts that you have to keep in mind when using Git (am I pushing to the same remote? is the branch "set to integrate"? does the remote has this branch name?) versus plain "push every…

What?

Git push by default pushes to where you cloned from. If you want to push to a different remote, you say so: "git push another-remote". If the remote doesn't have that branch, you create it, same as you would with bookmarks in mercurial.

git push == push all branches to origin hg push == push all changesets to origin

Re: Git 2.0 release notes

#34

Post by matthewmacleod »

anton_gogolev wrote: post #27
exDM69 wrote: post #22

Earlier quoted context omitted.

I would agree with you if there had been an actual comparison and some arguments for or against one or the other. Now there wasn't. E.g. "git push", similarly to "hg push" - without any extra arguments - do roughly the same thing, "push to the default location". When was the last time you ever saw anything useful or insightful in comments about git vs. hg? There have been a few enlightening blog posts on the subject…

> ...if there had been an actual comparison and some arguments for or against one or the other. What kind of comparison are you after? To be more scientific, let's take "git push where" and "hg push where". Now count the number of ifs and buts that you have to keep in mind when using Git (am I pushing to the same remote? is the branch "set to integrate"? does the remote has this branch name?) versus plain "push every…

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—rather than engaging in vague and abstract descriptions of "cruft".

Re: Git 2.0 release notes

#35

Post by anton_gogolev »

matthewmacleod wrote: post #34
anton_gogolev wrote: post #27

Earlier quoted context omitted.

> ...if there had been an actual comparison and some arguments for or against one or the other. What kind of comparison are you after? To be more scientific, let's take "git push where" and "hg push where". Now count the number of ifs and buts that you have to keep in mind when using Git (am I pushing to the same remote? is the branch "set to integrate"? does the remote has this branch name?) versus plain "push every…

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=git&m=111377572329534 [2]: http://marc.info/?l=linux-kernel&m=111288700902396

Re: Git 2.0 release notes

#36

Post by giulianob »

krig wrote: post #29
anton_gogolev wrote: post #28

Earlier quoted context omitted.

Or maybe it is Git that has introduced all kinds of crazy concepts that you're now struggling to keep in mind? Local branches? Remote tracking branches? Mutable branches? Really?

Those are all Mercurial concepts.

Not all Git concepts exist in Mercurial. See more here: http://mercurial.selenic.com/wiki/GitConcepts

Re: Git 2.0 release notes

#37

Post by js2 »

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

Perhaps "dwim" would be a better description of simple, but it arose from much feedback and debate on the git mailing list. Its behavior is now what it is believed most git newcomers expect.

Re: Git 2.0 release notes

#38

Post by marincounty »

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

No it's not you. It's overly complicated. This is what has always irked me about computing--making something seem more difficult than needed. I'm not asking for for an Apple solution, just cut the bull shit--high brow--If you don't know GIT you shouldn't be programming. It's a repository. I shouldn't need a git pocket guide. I want things fast and efficient. I don't like to spend daylight hours figuring out things; life is too short. In reality, I don't even like sitting in front of a computing devise, but society now requires it.

Re: Git 2.0 release notes

#39

Post by jgraham »

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…

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 each revision of the patches to. Unsurprisingly it turns out that two repos are not better than one and doing "simple" things (moving a patch queue between two clones of the same remote) requires fiddly manual operations.

Mercurial has some neat features, but this idea that it's always easy to use and git is always hard to use simply isn't true.

Re: Git 2.0 release notes

#40

Post by ygra »

jgraham wrote: post #39
Skinney wrote: post #31

Earlier quoted context omitted.

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…

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.
Post reply on HN