[Vm-dev] git mavens, shortcut please?

[Jakob Reschke]

I think Ben meant to post `git add -u` (there is no "stage" command,
but you can create aliases).

Long post follows, tl;dr/toc: a book recommendation; do not rely on
svn-to-git tables forever; a possible explanation for why add is
called add; a use case for staging (for those who might see it as an
unnecessary complication); remember the "stash" command; you might
like "bisect" for bug-hunting.

What documentation have you already read except for the manpages? I
liked the book mentioned on the git Homepage:
https://git-scm.com/book/en/v2
But I don't remember how good I knew git already when I read parts of
it. I found the Git Internals chapter to be particularly enlightening,
but I understand if you do not wish to deal with the internals just to
get going with it. :-)

Although SVN to Git migration guides and "translation" tables might be
what you look for in the beginning, you should definitely adjust to
Git's vocabulary for a happier life (at least happier on condition
that you work with Git).

Regarding the "add" for "stage": imagine that you do not track files
with git, but content (that's also how its database is built like). So
you "add" changes to Git's knowledge of your content.

The really nice part about the staging, by the way, is that it allows
you to commit only part of your changes, for smaller and more focused
commits even after you "went into the flow", fixed a hundred bugs, and
added ten features along the way, including that nifty utility
function that everyone ought to have on their branches (and want to
cherry-pick)... You can even can add individual lines from changed
files instead of the whole file (git add -p/--patch). I use it all the
time in my (non-Smalltalk) projects, but SVN cannot do that. I figure
it does not help so much with Smalltalk code, but could be handy for
all that C.

Also, if you ever happen to be working on something you do not want to
commit yet (even though you commit locally), but you have to switch
branches or merge something anyway (which svn update forces on you all
the time), you should remember the "git stash" command. It basically
puts aside local changes to tracked files for later retrieval. I would
say this is a must-know because Git won't in general let you perform
destructive operations on files with uncommitted changes (merge and
checkout are probably the most common ones), so you don't accidentally
lose any changes. Git is really quite good at not letting you lose
something, but it takes time to get used to it and appreciate that it
only wants to help. And you still have to know the commands to get
stuff back after you made a wrong decision. ;-) But remember that you
won't get something back you have never "added" to Git.

For the bug spotting part in tim's story, you might find the bisect
command interesting, when you have some time to read up about it. If
you are really proficient with that, you can make it automatically
search the history for a commit that introduced a bug you just
discovered. But I guess we would need some tooling to exploit that to
its fullest.

Well, I think that's enough text for today, sorry. ;-)

2016-06-19 7:37 GMT+02:00 Phil (list) <pbpublist at gmail.com>:
>
> On Sat, 2016-06-18 at 17:41 -0700, tim Rowledge wrote:
>>
>> Actually, calling all git mavens - please, please, point the rest of
>> us to some documentation that might possibly be understood by humans.
>> Some of us have no idea at all how this works and need something in
>> style of ‘see spot download some code. See spot build it. Run it,
>> spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now
>> save the code. Now pour the custard in m’boots!' and so on.
>>
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> ...now touch these wires to your tongue!
>>
>>
>
> There's a *lot* of content out there for migrating from svn (and other
> systems) to git.  This looks like a good 'I know how to do it in svn,
> now how do I do it in git?' basics page: http://git.or.cz/course/svn.ht
> ml and here's a version that might look nicer in hard copy form: https:
> //www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/