7 ms·

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

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

davidw 13y ago
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 http://1.0.0.127.IN -ADDR.ARPA --stats -v
- beaumartinez 13y ago
  Attribution— https://twitter.com/gitHater/status/169978106227068928 https://twitter.com/gitHater/status/169978106227068928
- rbonvall 13y ago
  I think it would be git checkout --ping (Checkout already does too much; one more doesn't hurt).
- sanderjd 13y ago
  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`.
jgraham 13y ago
Comparing hg branches to git branches in this context isn't super-useful; the right comparison is to hg bookmarks. In this case the semantics seem to be (based on reading the documentation so I might be wrong): hg push [dest] -- Push all local bookmarks that match a remote bookmark hg push -B [dest] -- Push a specific local bookmark to a remote To me those semantics don't seem particularly simple or flexible. In fact it seems quite like the semantics git is moving away from but with the restriction that local names and remote names always have to match, which means that you have to be very careful naming your local bookmarks to avoid clashes.
trurl42 13y ago
I guess 'simple' means "don't try to be too smart". Pushing only the current branch by default is a good thing, I think. If you are using a more centralized setup you can change the configuration of push.default to 'matching'.
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
krig 13y ago
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.
- egork8n 13y ago
  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 the changeset. Head is a changeset (that have no successors). Phase is information about whether it is safe to modify changeset. Mercurial is indeed a lot simpler.
  - Skinney 13y ago
    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.
    - jgraham 13y ago
      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.
js2 13y ago
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.
marincounty 13y ago
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.
- bronson 13y ago
  Just curious, where is this highbrow "if you don't know GIT you shouldn't be programming" bullshit you speak of?
  - recursive 13y ago
    Here's a similar one. https://news.ycombinator.com/item?id=7385563 https://news.ycombinator.com/item?id=7385563

davidw 13y ago

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 http://1.0.0.127.IN -ADDR.ARPA --stats -v

beaumartinez 13y ago
Attribution— https://twitter.com/gitHater/status/169978106227068928 https://twitter.com/gitHater/status/169978106227068928
rbonvall 13y ago
I think it would be git checkout --ping (Checkout already does too much; one more doesn't hurt).
sanderjd 13y ago
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`.

jgraham 13y ago

Comparing hg branches to git branches in this context isn't super-useful; the right comparison is to hg bookmarks. In this case the semantics seem to be (based on reading the documentation so I might be wrong): hg push [dest] -- Push all local bookmarks that match a remote bookmark hg push -B [dest] -- Push a specific local bookmark to a remote To me those semantics don't seem particularly simple or flexible. In fact it seems quite like the semantics git is moving away from but with the restriction that local names and remote names always have to match, which means that you have to be very careful naming your local bookmarks to avoid clashes.

trurl42 13y ago

I guess 'simple' means "don't try to be too smart". Pushing only the current branch by default is a good thing, I think. If you are using a more centralized setup you can change the configuration of push.default to 'matching'.

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

krig 13y ago

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.

egork8n 13y ago
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 the changeset. Head is a changeset (that have no successors). Phase is information about whether it is safe to modify changeset. Mercurial is indeed a lot simpler.
- Skinney 13y ago
  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.
  - jgraham 13y ago
    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.

js2 13y ago

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.

marincounty 13y ago

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.

bronson 13y ago
Just curious, where is this highbrow "if you don't know GIT you shouldn't be programming" bullshit you speak of?
- recursive 13y ago
  Here's a similar one. https://news.ycombinator.com/item?id=7385563 https://news.ycombinator.com/item?id=7385563