Re: di-git-ally managing love letters - a Git presentation

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 4, 2009, 14:51 UTC
Message-ID: <m3oct46oji.fsf@localhost.localdomain>
In-Reply-To: <d16b1c80906040441n7ad549eay83a6ccfd5db09fb3@mail.gmail.com>

Shakthi Kannan <shakthimaan@gmail.com> writes:

Show 6 quoted lines

> I have tried to make a basic presentation on Git, that covers some
> basic commands. Please find it here:
> http://shakthimaan.com/downloads/glv/presentations/di-git-ally-managing-love-letters.pdf
> 
> The LaTeX beamer sources are available at:
> http://shakthimaan.com/downloads/glv/presentations/di-git-ally-managing-love-letters.tar.bz2

Why don't you use git to manage LaTeX sources, using for example one of free git hosting sites (repo.or.cz, GitHub, Gitorious)?

I liked the presentation, especially visualisation of status of working area, index and object database (repository).

A few comments:
 * For which git version do you write your presentation?  Modern
   git (which might mean just released version, and perhaps even
   yet-to-be-released version) has:
     - git config --global --edit   #; for Windows users
     - git log --oneline == git log --pretty=oneline --abbrev-commit

 * Nitpick: git index (also known as staging area) does not contain
   objects itself.  They are put in objects database.  The index 
   contains references to those objects (so they can be found).

 * Suggestion: When showing "git diff", "git diff --cached" and 
   "git diff HEAD" output you might want to show which parts
   in the diagram below you compare.

 * Why there is no diagram / graph for tagging?

 * Nitpick: you have spelled 'git-format-patch' by mistake
   instead of modern 'git format-patch'.

>
> I start with git init, add, commit;

 * I wonder which of workflows is more common: starting with empty
   repository, or starting with some set of files.  You can do
   "git init" in existing directory.  But perhaps starting with
   clean state is easier to describe, as you can just "git add .",
   while you might want to add only subset of files (using for
   example ignore rules) in project import workflow.

> show how to use rm with -f and --cached options;

 * I would personally use "git rm -f <file>", but it might be easier
   tu add '-f' at the end of line.

> then go on to show reset HEAD (alternative to using --cached?);

 * I would guess that this usage ("git reset HEAD <file>") is quite
   rare, and would make more sense if there would be some committed
   version of <file>; then it wouldn't be equivalent to 
   "git rm --cached <file>".

> proceed further to show reset --soft

 * I think that actual usage of "git reset --soft" is pretty pretty
   rare since we have "git commit --amend".

> and --hard options.

 * "git reset --hard <revision>" is actually pretty useful.

Show 10 quoted lines

> Finally, branching, merging, rebase and clone. It is not meant to be a
> comprehensive list of git commands, but, some essential ones to get
> people started with (I hope).
> 
> I would appreciate feedback, suggestions on the same. If you feel the
> commands are to be used differently, or in a different workflow
> perhaps, or if you find something that needs to be added, removed or
> fixed, please let me know.
> 
> Kindly ignore the nouns used.

I don't know if presentation is not too long. On the other hand it doesn't cover situations such as non fast-formard merge...

-- 
Jakub Narebski
Poland
ShadeHawk on #git