On Wed, Oct 30, 2019 at 6:16 PM Patricia Shanahan <p...@acm.org> wrote:
On 10/30/2019 8:13 AM, Damjan Jovanovic wrote:
What do you already know? SVN?
RCS, SCCS, and SVN.
I personally did:
git clone https://gitbox.apache.org/repos/asf/openoffice.git
(ie. not GitHub)
which I think used my Apache credentials. If you prefer to clone from
GitHub, and want to link your Apache and GitHub credentials, you can
apparently do it on:
https://gitbox.apache.org/
Any guidance on how to decide which I am likely to prefer?
It doesn't really matter which you start with, because they're each other's
mirrors, and in Git you can always change your local repository's "remote".
For example if you cloned GitHub, and want to switch to GitBox, you don't
need to clone the GitBox link, you can simply do:
git remote set-url origin https://gitbox.apache.org/repos/asf/openoffice.git
With GitHub, you can accept GitHub pull requests from other contributors,
even in your web browser, so it might be a better choice in that regard. I
can't say I personally approve of the GitHub lock-in for that feature
though.
As for how you use Git, if you are interested, I can give you some links,
and my own "Git for SVN users" crash course.
Links would be useful. For me when learning programming languages, "for
dummies" courses work better than conversion courses. The "for dummies"
type of course helps me get into the right mindset for the language. I
don't know whether SVN to Git will be different.
Ok sure:
Graph theory explanations of how branches and Git operations work:
https://eagain.net/articles/git-for-computer-scientists/
The free online book, "Pro Git":
https://git-scm.com/book/en/v2
A detailed guide to various Git options, written for the Wine project but
generally useful:
https://wiki.winehq.org/Git_Wine_Tutorial
I'll try sum it up for you. For SVN users, Git's terminology is straight
from hell. "svn checkout X" checks out a working copy from repository X,
but "git checkout X" switches the current branch to X (among other things).
Git's equivalent is "git clone" (except that the entire repository with
full history and all branches is cloned, not just a working copy.) An SVN
revision is a commit in Git.
Everything you commit is only committed locally, and can be undone. You
have to "git push" to send your commits upstream.
The main branch of a project is usually called "master", but in AOO ours is
called "trunk" since we imported from SVN. The branch you are on at the
moment is given by "git branch", which lists all the local branches and
stars the current one. "git status" also shows your current branch and
files changed.
Remote branches can be shown with "git remote show origin". If you "git
checkout" with their name, eg. "git checkout AOO418", it will make a local
branch by that name and switch to it. You can also make a local branch
remote (somehow).
You make new local branches with "git branch <name>", eg. "git branch
temp". (It's instantaneous: it doesn't have to copy history or anything
like that). You can "git checkout temp" to switch to it, "git branch -D
temp" to delete it. A "detached head" is when you "git checkout" something
that's not a branch (as you can "git checkout" any commit or tag, not just
a branch). If you are just looking around, that's not a problem, but if you
"git commit" on a detached head, that commit isn't referenced from
anywhere, and if you checkout anything else, you will lose that work. If
you don't want to lose it, you can "git branch myWork" to attach a branch
to that new commit, so you can get back to it later (with "git checkout
myWork").
There are 2 important ways of working with branches, merging and rebasing.
Both are only local, until you "git push". Merging in Git is similar to
merging in SVN, changes in one branch get merged into another, but rebasing
is amazing. With rebasing you can rearrange commits and branches to your
liking, split commits, merge commits, reorder commits, delete commits,
change commit messages, reposition an old branch so it starts at a newer
commit (and deal with outdated code locally in that branch before merging
or pushing it), etc. "git rebase -i HEAD~3" opens a text editor with the
last 3 commits, one per line, describing changes you can make by placing a
keyword at the beginning of its line. If you commit by mistake, do that and
you can drop the bad commit. Of course with great power comes great
responsibility, and rebasing should only really be done locally before you
push, as rebasing commits that were already pushed can mess up other
people's changes to them.
When changes are made upstream by other contributors, you can "git pull"
them, but I prefer the more incremental "git fetch" which fetches changes
without merging them, and then a rebase of my work to come after the latest
changes - that way I know those changes still apply, even if I don't push
them yet. ("git pull" does a "git fetch" and then a merge, not a rebase.)
Undoing uncommitted changes to a file, "svn revert", is confusingly "git
checkout -- path/to/file" (yes, you both switch branches and undo
uncommitted changes with the same command. Don't know who had that bright
idea.).
Like in SVN, new files have to be "git add"ed. There's also "git rm", "git
mv" etc.
"git commit" will only commit what's been staged. You either have to stage
every changed file with "git add" (not just new files) and then "git
commit", or "git add" any new files and then "git commit -a" which will
include changes to non-new files.
"git log" is very summarized. "git log --name-status" also lists the files
changes in each commit. You can append a path to that to query history only
that file or directory. You can "git show" a commit id (that long
hexadecimal string you see in the git log) to see a diff of the code
changes for that commit.
There is a vast number of commands and options. Start with the basics: add,
commit, branch, checkout, log, show, status, push, pull. Git commands do
explain things quite well, if you take the time to read their output, for
example if a rebase or merge fails, it tells you what commands to run to
fix it and continue, or lets you abort and roll back, the scary "detached
head" message tells you how to make a branch, "git status" tells you what
you can do for files in each state (eg. to "git add" the untracked files).
The man pages for "git merge" and "git rebase" draw nice pictures of what
happens to branches and commits.
Feel free to ask if you have any questions.
