5 ms·

> 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

by exDM69 13y ago

> 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 versa. There should be no need to argue because you can pick the one you like and use it.

simias 13y ago
So comparing two competing tools is flamebait nowadays? I think the OP makes a valid and argumented point.
- exDM69 13y ago
  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 but discussion threads like this don't really provide anything of value.
  - anton_gogolev 13y ago
    > ...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 everything to where you cloned from" in Mercurial. My point is that Git has accumulated too much cruft and has introduced one too many concepts to be usable.
    - Skinney 13y ago
      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
    - matthewmacleod 13y ago
      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".
      - anton_gogolev 13y ago
        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 http://marc.info/?l=git&m=111377572329534 [2]: http://marc.info/?l=linux-kernel&m=111288700902396 http://marc.info/?l=linux-kernel&m=111288700902396
        matthewmacleod 13y ago
        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.)
- klibertp 13y ago
  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.
VeejayRampay 13y ago
Also, hasn't git won already? I mean, I'm sure Mercurial is a great tool and all, but git is massive and widespread now, there's no going back and sharing of the pie until a new generation of VCS that completely changes the game emerges I think.

by exDM69 13y ago

simias 13y ago

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

exDM69 13y ago
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 but discussion threads like this don't really provide anything of value.
- anton_gogolev 13y ago
  > ...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 everything to where you cloned from" in Mercurial. My point is that Git has accumulated too much cruft and has introduced one too many concepts to be usable.
  - Skinney 13y ago
    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
  - matthewmacleod 13y ago
    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".
    - anton_gogolev 13y ago
      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 http://marc.info/?l=git&m=111377572329534 [2]: http://marc.info/?l=linux-kernel&m=111288700902396 http://marc.info/?l=linux-kernel&m=111288700902396
      - matthewmacleod 13y ago
        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.)
klibertp 13y ago
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.

VeejayRampay 13y ago

Also, hasn't git won already? I mean, I'm sure Mercurial is a great tool and all, but git is massive and widespread now, there's no going back and sharing of the pie until a new generation of VCS that completely changes the game emerges I think.