openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: New computer
Date Wed, 30 Oct 2019 20:04:33 GMT

On 10/30/19 11:01 AM, Damjan Jovanovic wrote:
> On Wed, Oct 30, 2019 at 6:16 PM Patricia Shanahan <> 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
>>> (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:
>> 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
> 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:
> The free online book, "Pro Git":
> A detailed guide to various Git options, written for the Wine project but
> generally useful:
> 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.

Thank you Damjen. I too am looking for some "learning git" pointers.

-- Kay

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message