Re: Git cheat sheet

Re: Git cheat sheet

[Rene Herman]

On 08/29/2007 09:48 AM, Zack Rusin wrote:

> I took a short break from being insanely handsome (which takes a lot of my 
> time - gorgeous doesn't just happen) and based on similar work for Mercurial 
> created a little SVG cheat sheet for Git.

[ ... ]

> Sample png's are here:
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.png

Yes, well, screw those, it's pictures of _you_ we want!

Rene.

Git cheat sheet

[Zack Rusin]

Hey, 

I took a short break from being insanely handsome (which takes a lot of my 
time - gorgeous doesn't just happen) and based on similar work for Mercurial 
created a little SVG cheat sheet for Git. I'm not sure if it's going to be 
useful for anyone else (the target audience was composed of engineers who 
agreed to move to and work from Norway so you know right of the bat that 
historically they already made some bad decisions), but the times when I do 
art are so rare that I feel the need to share.

The thing that I took from the Mercurial sheet, besides the idea, is the 
flow-chart (people dig icecream and flow-charts, the first one is really hard 
to get into a SVG rendering so I went with the second) so the license is the 
same as of the Mercurial sheet which was Creative Commons.
There's likely a few errors in it and if you have any suggestions or if you 
sport latex pants and a fancy green hairdo that goes with those pants (which 
equals the fact that you're an artist) and would like to pimp the sheet out, 
it would be my pleasure to help you. 

The SVG is at:
http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg
Sample png's are here:
http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.png

with much (platonic) love,
z

Re: Git cheat sheet

[Junio C Hamano]

Zack Rusin <zack@kde.org> writes:

> http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg

Nice drawing and no typo.  Very nicely done.

Some minor nits (-), improvement suggestions (+), and
corrections (*).

- Recommended form for diff between 1 and 2 is "git diff $id1
  $id2", not dotted form "$id1..$id2"

+ "git log -p $file" gives a false impression that it is about a
  single file.  Better written as "git log -p $file $dir/ec/tory/"
  to suggest both usage.

- Although they do the same thing ("annotate" is there only for
  backward compatibility) "git blame" is recommended over "git
  annotate", if only because that's the command name more often
  talked about in the community.  If you are going to list only
  one, blame is the name to keep.

+ To start from a particular revision, use "git blame $version $file".

- "git reset --hard HEAD"; you do not have to write HEAD there.

- "Revert" has a specific meaning to git but people from
  different background interpret the word differently.  Both
  "git revert HEAD" and "git revert $id" are about creating a
  new commit to reverse the effect of the named commit.

* "git pull $branch1 $branch2" is wrong.  If you are merging
  branch1 into branch2, you need to be on branch2 (i.e. have
  done "git checkout branch2") and then say "git merge branch1".

+ "git commit" is not about publishing at all.  A major point
  about distributed SCMs is that unlike centralized systems, the
  act of committing is separate from the act of publishing.
  IOW, you can make commits without having to worry about
  publishing that to the public, and that allows you to more
  freely experiment.

+ A new section "Making Progress" and include commit, merge and
  rebase there, perhaps?

Re: Git cheat sheet

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Zack Rusin <zack@kde.org> writes:
>
>> http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg
>
> Nice drawing 

True!

> and no typo.

Except for the blue closing parenthesis for (git-config --help), while
the opening one is black ;-).

> + "git commit" is not about publishing at all.

It does not publish in itself, but it's mostly necessary in order to
publish. For a short summary, I think it's OK to have it in the
publishing section, as long as it's just before "format-patch" and
"push".

otherwise, about the suggested flow on the top right, I'd move
"commit" to the left. Most of the time, "commit" comes before pull or
fetch. It normally comes before "revert", but after "reset" (revert
creates a new commit, you want to do it from a clean tree, so either
reset or commit before).

-- 
Matthieu

Re: Git cheat sheet

[Nguyen Thai Ngoc Duy]

Great.

I would like to translate it into Vietnamese (with xml2po). Can you
please do me a favor making "Git Cheat Sheet" at the top left a
continuous string?  Also it would be great if the text "the curves
indicate..."  is a continuous paragraph. I have no idea if it can be
achieved with inkscape/svg though.

Thank you.

On 8/29/07, Zack Rusin <zack@kde.org> wrote:
> Hey,
>
> I took a short break from being insanely handsome (which takes a lot of my
> time - gorgeous doesn't just happen) and based on similar work for Mercurial
> created a little SVG cheat sheet for Git. I'm not sure if it's going to be
> useful for anyone else (the target audience was composed of engineers who
> agreed to move to and work from Norway so you know right of the bat that
> historically they already made some bad decisions), but the times when I do
> art are so rare that I feel the need to share.
>
> The thing that I took from the Mercurial sheet, besides the idea, is the
> flow-chart (people dig icecream and flow-charts, the first one is really hard
> to get into a SVG rendering so I went with the second) so the license is the
> same as of the Mercurial sheet which was Creative Commons.
> There's likely a few errors in it and if you have any suggestions or if you
> sport latex pants and a fancy green hairdo that goes with those pants (which
> equals the fact that you're an artist) and would like to pimp the sheet out,
> it would be my pleasure to help you.
>
> The SVG is at:
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg
> Sample png's are here:
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.png
>
> with much (platonic) love,
> z
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Duy

Re: Git cheat sheet

[Karl Hasselström]

On 2007-08-29 01:11:07 -0700, Junio C Hamano wrote:

> - "git reset --hard HEAD"; you do not have to write HEAD there.

There should also probably be a warning about any local changes being
irretrievably lost. (The existing warning is kind of vague.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Git cheat sheet

[Zack Rusin]

Thanks a lot for the comments.

On Wednesday 29 August 2007 04:11:07 am Junio C Hamano wrote:
> - Recommended form for diff between 1 and 2 is "git diff $id1
>   $id2", not dotted form "$id1..$id2"

Fixed. 

> + "git log -p $file" gives a false impression that it is about a
>   single file.  Better written as "git log -p $file $dir/ec/tory/"
>   to suggest both usage.

Fixed.


> - Although they do the same thing ("annotate" is there only for
>   backward compatibility) "git blame" is recommended over "git
>   annotate", if only because that's the command name more often
>   talked about in the community.  If you are going to list only
>   one, blame is the name to keep.

Fixed.

> + To start from a particular revision, use "git blame $version $file".

I'm not quite sure where to squeeze it though :)

> - "git reset --hard HEAD"; you do not have to write HEAD there.

The reason I left HEAD in there was because I wanted to let people know they 
can reset to any id, but come to think of it, I failed at that (and only at 
that, everything else in my life is a success... cough, cough) so I removed 
HEAD.

> - "Revert" has a specific meaning to git but people from
>   different background interpret the word differently.  Both
>   "git revert HEAD" and "git revert $id" are about creating a
>   new commit to reverse the effect of the named commit.

I added a note to let people know it creates a new commit.

> * "git pull $branch1 $branch2" is wrong.  If you are merging
>   branch1 into branch2, you need to be on branch2 (i.e. have
>   done "git checkout branch2") and then say "git merge branch1".

Ah, thanks! Fixed. 

> + "git commit" is not about publishing at all.  A major point
>   about distributed SCMs is that unlike centralized systems, the
>   act of committing is separate from the act of publishing.
>   IOW, you can make commits without having to worry about
>   publishing that to the public, and that allows you to more
>   freely experiment.

The reason I put it in publishing was because if I added another section I'd 
have to resize the font to about 2pt to fit it all which in turn would imply 
that everyone trying to read the sheet would be crosseyed (and given my 
strong support for beauty in the community, I just couldn't do that). 

> + A new section "Making Progress" and include commit, merge and
>   rebase there, perhaps?

Yeah, lack of rebase in the sheet bothers me a bit, since it's quite 
important. Maybe I could remove the "useful commands" section and put 
something in there...

Also I think that it's very important to specify what a "cheat sheet" is for. 
It's not a replacement for a tutorial. I don't think it's reasonable to 
expect anyone to print this sheet without reading any tutorials/documentation 
and be riding the Git wave. It nicely complements the tutorial, especially in 
the beginning phases of learning something new. 
So what I wanted to have on this sheet is list of thingies (technical term) 
people will use on a daily basis. In cases they need a specific permutation 
of them they can always look at the documentation.
So in my opinion (and that's a wicked good opinion) the scenario we should be 
aiming at with a cheat sheet is:
1) a person hears about Git in an online dating forum
2) a person takes a deep breath and changes pants
3) a person reads the tutorial
4) a person prints a cheat sheet and begins using Git

While I think 1 and 2 will change and are fairly optional, I think 3 
absolutely has to come before 4. 
Basically I wanted this to be a road-sign that would point people in the right 
direction (and I know that people from Brooklyn, are all confused right now 
because every roadsign they've ever seen points the wrong direction, but they 
can trust me, outside Brooklyn roadsigns actually point in the right 
direction).

I'm not sure if I should put the sheet in some more visible place, so for now 
the updated svg and png's are at:
http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg
http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.png

z

Re: Git cheat sheet

[Dan Chokola]

On 8/29/07, Zack Rusin <zack@kde.org> wrote:
> Thanks a lot for the comments.
>

One more. You might want to add git apply to the "Change" part of the
command sequence.

-- 
Dan Chokola

Re: Git cheat sheet

[Matthieu Moy]

Zack Rusin <zack@kde.org> writes:

>> + A new section "Making Progress" and include commit, merge and
>>   rebase there, perhaps?
>
> Yeah, lack of rebase in the sheet bothers me a bit, since it's quite 
> important. Maybe I could remove the "useful commands" section and put 
> something in there...

But be carefull with rebase: it's easy to shoot yourself in the foot
with it (try rebasing a branch you've already published, and which
people already branched from if you want to see ;-) ). Putting it on a
"cheat sheet" increase the risk of seeing people using it without
knowing about the risk.

> I'm not sure if I should put the sheet in some more visible place, so for now 
> the updated svg and png's are at:

Just linking to them from the git wiki would be nice already.

-- 
Matthieu

Re: Git cheat sheet

[Bernt Hansen]

Junio C Hamano <gitster@pobox.com> writes:

> Zack Rusin <zack@kde.org> writes:
>
>> http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg
>
> Nice drawing and no typo.  Very nicely done.
>

One typo:

Title "To view the merge conclicts" under Resolve Merge Conflicts.

Nice job :)

-Bernt

Re: Git cheat sheet

[Bernt Hansen]

Junio C Hamano <gitster@pobox.com> writes:

> Zack Rusin <zack@kde.org> writes:
>
>> http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg
>
> Nice drawing and no typo.  Very nicely done.
>

One typo:

Title "To view the merge conclicts" under Resolve Merge Conflicts.

Nice job :)

-Bernt

Re: Git cheat sheet

[Dan Zwell]

Zack Rusin wrote:
> Hey, 
> 
> I took a short break from being insanely handsome (which takes a lot of my 
> time - gorgeous doesn't just happen) and based on similar work for Mercurial 
> created a little SVG cheat sheet for Git.
...
> The SVG is at:
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet.svg
> Sample png's are here:
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-large.png
> 

I noticed that the cheat sheet listed the options "--theirs", "--ours", 
and "--base" for git-diff. These aren't in git-diff's manpage. A little 
grep-fu showed me that these are options of git-diff-files, but 
shouldn't they be documented with the porcelain, if the porcelain 
accepts them as options? (I normally use a text editor to view and 
resolve conflicts, but the presence of these options on a cheat sheet 
indicates that they are somewhat important.)

Thanks,
Dan