
Giteveryday – A useful minimum set of commands for Everyday Git - ymse
https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html
======
libeclipse
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 OP is actually brilliant. It's easy to read, has
examples, compartmentalises into sections that are relevant to different
people. It's a step in the right direction.

Note: I'm not saying there aren't other pages like OP. There probably are, but
the vast majority are not.

[0] [https://github.com/tldr-pages/tldr](https://github.com/tldr-pages/tldr)

~~~
ekr
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 space on  the underlying  physical  medium,  or the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or call was interrupted by a signal handler after having written less than  count  bytes.   (See  also (7).)
    
      For  a  seekable file (i.e., one to which lseek(2) may be applied, for example, a regular file) writing takes place at the file offset, and the file offset is incremented by  the  number  of  bytes  actually written. If the file was open(2)ed with O_APPEND, the file offset is first set to the end of the file before writing.  The adjustment of the file offset and the write operation are performed as  an  atomic step.
    

I have to go through a block of text scanning for the parameter I'm interested
in. When I'm using the manpage as a reference (which is most of the time),
this is less than ideal.

MSDN indexes the documentation by parameter so you can quickly find what
you're interested in.

LE. Sample msdn link for comparison: [https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa365747\(v=vs.85\).aspx) .

~~~
qwertyuiop924
That's actually just one sentence you have to scan, so I don't totally see the
issue.

~~~
viraptor
It could still be better. It could be 0 sentences to scan it it was formatted
in a better way.

------
erikb
I love that they try to make it assessible. But I disagree with that it would
be an acceptable goal in git just to understand a subset of it. You need to
understand nearly everything, even the internals. Only then it can really
become useful to you.

The mistake the community made is putting git on the throne of version
control. It's not. It's a tool for experts that can do a lot for you if you
know how to use it. But to achieve that it pays the price of not really being
assessible.

Now that it's in its position, the best thing you can do is to learn it. There
is the git book. Read it. Annoying, I know. But that's the gameplan. Not doing
it is just dragging out the inevitable.

~~~
logicallee
This is a very useful comment.

I think the same could be said about C. It should not be put on the throne of
"programming language" \- you need to actually read and understand what it
does internally. (pointers etc) - it's not enough to learn some incantations.

So then let me ask: is there a room for x, where git:x::C:python (git is to x,
as C is to Python).

People everywhere deserve to have x. Not just right-clicking a file in Dropbox
or OS X for previous versions, but a full commandline and detailed history
including commit messages, and many other aspects of git.

In a way this is completely orthogonal to your comment, just as Python is to
C.

EDIT: I've thought more about it and I no longer agree. The "language"
presented here is a subset of C/C++ - not everything is mentioned or taught:
[https://www.arduino.cc/en/Reference/HomePage](https://www.arduino.cc/en/Reference/HomePage)

It is in fact exactly this type of simplified subset. Not even malloc and free
are mentioned... So while what you wrote is true for this audience (HN) there
is room to learn less or a subset.

~~~
nothrabannosir
Mercurial. I'm not being flippant; the UX is light years ahead in terms of
accessibility to newcomers to dvcs. With a ui like tortoisehg, even five years
ago, someone without any prior experience in any vcs at all could become
productive after a fifteen minute primer. Git does not compare.

~~~
isxek
It also makes sense, I think, considering that Git consists of small tools
interacting with each other, while Hg is written as a whole application/system
by itself, which can then be extended as needed.

------
guard-of-terra
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.

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

~~~
guard-of-terra
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
<commit> ._ for SCM.

------
user5994461
Useful commands for everyday GitHub usage:

# apt-get remove git

# apt-get install svn

Then use svn. You can receive and send code to GitHub. GitHub is fully svn
compatible =)

That can be especially handy for non-tech folks who would have an impossible
time with git.

------
captn3m0
This is my favorite documentation link I give to others when teaching git.

~~~
JdeBP
Have you considered helping to complete
[https://en.wikibooks.org/wiki/Git](https://en.wikibooks.org/wiki/Git) ?

