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.
