Live data from Hacker News

Giteveryday – A useful minimum set of commands for Everyday Git

kernel.org

21–30 of 53 posts

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#21
post #13

Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…

I’ve been using Linux for years too, and I learned more useful things about Bash with `man bash` than anything I could find on the web.

For a while I had a printout of the bash manpage, neatly bound. It's something like 60 pages. Nroff actually produces great print output, which hardly anyone ever uses it for these days.

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#22

Both merge and rebase, but no cherry-pick. Goodbye then, I guess. I've seen a dozen of those tools wishing to "simplify" git and they all fail my workflow, which is pretty common I guess, team git with central server and source control. What I use: git push with target git fetch git checkout git cherry-pick git reflog git log, status, diff obviously.

Why git cherry-pick rather than just fast-forward or rebase? Doesn't that introduce a whole bunch of duplicate commits?

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#23
post #3

Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…

One place where the MSDN docs is way ahead of the manpages is the documentation of function paramters. For instance, here's the ouput of man 2 write . ssize_t write(int fd, const void *buf, size_t count); DESCRIPTION write() writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. The number of bytes written may be less than count if, for example, there is insufficient s…

One of the things that never ceases to amaze me is how slow MSDN is. It feels faster to look something up on stackoverflow, even if it's not as well organised.

Version-specificness on MSDN is often a little odd. I do Windows CE and for some reason Google returns hits from the Wince5 docs more often than the rest, and it's not straightforward to get to the docs for a different version. Sometimes this is important.

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#24
post #21
post #13

Earlier quoted context omitted.

I’ve been using Linux for years too, and I learned more useful things about Bash with `man bash` than anything I could find on the web.

For a while I had a printout of the bash manpage, neatly bound. It's something like 60 pages. Nroff actually produces great print output, which hardly anyone ever uses it for these days.

I don't think anything matches paper in terms of annotatability. I print things put all the time to just mark them up with red pen.

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#25

Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…

Thanks for that link to the TLDR project, looks kinda interesting.

The fact that project exists though suggests to me there is a problem with the man page system in general.

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#26
post #8

Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…

> One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. On the other hand, when I was first introduced to Linux ~20 years ago, I didn't have an "always-on" Internet connection and web sites weren't that popular. Probably 90% of what I learned in the first few years or so came from the man pages and a locally downloaded copy of the guides and howto's from TLDP [0]. I might also mention…

Same here; I was constrained to what was on my stack of floppies comprising my Slackware dist

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#27

Both merge and rebase, but no cherry-pick. Goodbye then, I guess. I've seen a dozen of those tools wishing to "simplify" git and they all fail my workflow, which is pretty common I guess, team git with central server and source control. What I use: git push with target git fetch git checkout git cherry-pick git reflog git log, status, diff obviously.

The difference between rebase and cherry pick is very very slim, rebase is in a sense just a convenience frontend for cherry-pick..

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#28
post #22

Both merge and rebase, but no cherry-pick. Goodbye then, I guess. I've seen a dozen of those tools wishing to "simplify" git and they all fail my workflow, which is pretty common I guess, team git with central server and source control. What I use: git push with target git fetch git checkout git cherry-pick git reflog git log, status, diff obviously.

Why git cherry-pick rather than just fast-forward or rebase? Doesn't that introduce a whole bunch of duplicate commits?

I don't care about any commits that are not under code review. If I have fifty duplicate commits on different branches in my local, that's okay with me.

Fast-forward doesn't work usually, and rebase is confusing compared to cherry-pick.

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#29
post #27

Both merge and rebase, but no cherry-pick. Goodbye then, I guess. I've seen a dozen of those tools wishing to "simplify" git and they all fail my workflow, which is pretty common I guess, team git with central server and source control. What I use: git push with target git fetch git checkout git cherry-pick git reflog git log, status, diff obviously.

The difference between rebase and cherry pick is very very slim, rebase is in a sense just a convenience frontend for cherry-pick..

For rebase I can never figure out what should go in all its parameters. It has defaults sure, that are impossible to figure out either.

With cherry-pick you have no parameters and no defaults, it's basically cp . for SCM.

Re: Giteveryday – A useful minimum set of commands for Everyday Git

#30

Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…

Wow, a man page that is actually readable and understandable... just like any other man page.

I've been using Linux for years, and never once have I seriously looked at replacements for man pages. In your average man page, I can look up even the most obscure option and know exactly how to use it and what it actually does. With a detailed enough man page, I don't even need to look anywhere else much of the time. It irritates me when I have to lookup documentation which isn't written in a similar format. (Say, LaTeX.)

I don't see any appeal in "tldr pages" or "bro pages", and frankly, I get rather annoyed when every once in a while I see HN posts promoting projects like that which basically reinvent the square wheel instead of solving the real problems of man pages (which I'd say there are two: lack of hyperlinks and poor searchability).

Post reply on HN