3 ms·

> There, I fixed it. GP's point was about defaults, not what you can configure. Even being somewhat familiar with hg, I didn't know about the "pager" extension

> There, I fixed it. GP's point was about defaults, not what you can configure. Even being somewhat familiar with hg, I didn't know about the "pager" extension. > `git show` does not show a patch by default[...] It does for me, with git 1.7.9.5. > (hg has no prohibition against what git calls "detached heads", they're just anonymous branches) I have never understood why this is useful. Why not just name your heads something, anything? I wouldn't otherwise care, but I always seemed to end up with mysterious heads from who-knows-where left behind by long-ago merges.

masklinn 13y ago
> GP's point was about defaults Granted, but he then describes the difficulty of typing `hg log | less`. And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. > It does for me, with git 1.7.9.5. Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not the gist of the issue and the official documentation asserts it should. > I have never understood why this is useful. Why not just name your heads something, anything? Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?
- michael_storm 13y ago
  > And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. I don't know why that's part of the defaults discussion, but okay. > Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone? Why would you give a meaningless name? That's a red herring. Do hg users just memorize which head is which? Mercurial users seem to get hung up on detached heads a lot. They seem to be part of the Mercurial workflow in a way that I've never really understood. But git's detached heads are at least created when I expect them to be, are easily deleted, and are easily saved. Mercurial's detached heads (or whatever they're called) want me to either merge them (why would I merge commits that popped up out of nowhere?), or close them as described in http://stackoverflow.com/questions/3688263/mercurial-beheading-a-head http://stackoverflow.com/questions/3688263/mercurial-beheadi... (apparently causing these mysterious heads to be saved forever). I much prefer a DAG with labels, instead of all this state specific to Mercurial that I have to manage.
  - zobzu 13y ago
    note that if you use queues it works okay ;-)
  - ufo 13y ago
    > Do hg users just memorize which head is which? Its not that bad if its only a couple of commits deep since you can look at the commit messages for context. And if you are using a gui like tortoiseHg then reading a commit message is basically the same amount of work as reading the bookmark name. And if you really want to add a name you can add one, you just don't necessarily need to.

masklinn 13y ago

> GP's point was about defaults Granted, but he then describes the difficulty of typing `hg log | less`. And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. > It does for me, with git 1.7.9.5. Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not the gist of the issue and the official documentation asserts it should. > I have never understood why this is useful. Why not just name your heads something, anything? Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?

michael_storm 13y ago
> And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history. I don't know why that's part of the defaults discussion, but okay. > Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone? Why would you give a meaningless name? That's a red herring. Do hg users just memorize which head is which? Mercurial users seem to get hung up on detached heads a lot. They seem to be part of the Mercurial workflow in a way that I've never really understood. But git's detached heads are at least created when I expect them to be, are easily deleted, and are easily saved. Mercurial's detached heads (or whatever they're called) want me to either merge them (why would I merge commits that popped up out of nowhere?), or close them as described in http://stackoverflow.com/questions/3688263/mercurial-beheading-a-head http://stackoverflow.com/questions/3688263/mercurial-beheadi... (apparently causing these mysterious heads to be saved forever). I much prefer a DAG with labels, instead of all this state specific to Mercurial that I have to manage.
- zobzu 13y ago
  note that if you use queues it works okay ;-)
- ufo 13y ago
  > Do hg users just memorize which head is which? Its not that bad if its only a couple of commits deep since you can look at the commit messages for context. And if you are using a gui like tortoiseHg then reading a commit message is basically the same amount of work as reading the bookmark name. And if you really want to add a name you can add one, you just don't necessarily need to.