How to use git

[Fred Wright]

On Sat, 20 Aug 2016, Ian Wadham wrote:
> On 20/08/2016, at 1:24 PM, Lawrence Velázquez wrote:

> > We'll actually be using svn2git for the migration, so in a very real sense we have you (collectively) to thank :)
> >
> > https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git

That was broken for a while, though it seems to be back now.

There are multiple articles kicking around on possible migration issues,
e.g.:

Migrating from Subversion to Git and the Lessons Learned | Dr Dobb's
http://www.drdobbs.com/architecture-and-design/migrating-from-subversion-to-git-and-the/240009175

Don't do svn-to-git repository conversions with git-svn! | Armed and ...
http://esr.ibiblio.org/?p=6778

> I don't know if this applies to Macports, but KDE did a lot of splitting of SVN
> "module" repositories into individual project repositories on git.  For example,
> the KDE Games module on SVN went from one repository to about 40 repositories:
> one for each game and library.  This was to limit the overheads, for developers,
> of cloning git repositories in their local machines, but it made building "everything"
> (i.e. collections of repositories) a little harder.

Given that git has the ability to make "shallow" clones (with the --depth
argument), this doesn't seem like a very good reason to split things up
and make nontrivial cloning *more* hassle.

Disclaimer:  I've never bothered using this feature myself, since I have
plenty of disk space and a fast net connection. :-)

Git also has a "submodule" feature, but it was added as an afterthought
and in the one project I've contributed to that uses it (OSXFUSE), it's
been more trouble than it's worth.

On Sat, 20 Aug 2016, Brandon Allbery wrote:

> On Sat, Aug 20, 2016 at 11:44 PM, Ian Wadham <iandw.au at gmail.com> wrote:
>
> > Fork the repo??
>
>
> github expects you to do this, yes. I don't actually recommend it because
> keeping up to date with the original repo's a PITA (and *not* automated in
> any way. https://help.github.com/articles/syncing-a-fork/ is annoyingly

Umm, the whole merging aspect is something you need to do regardless of
whether you're pulling from "origin" or "upstream", so this isn't a good
argument against using a fork.  It gets more complicated with multiple
branches, but again the merging part is the same whether you're using a
fork or not, and the only difference is whether you also need to push the
merged branches to the fork.

Meanwhile, the whole pull request mechanism is designed around the forked
repo model, so anyone without direct commit access should be strongly
encouraged to use a fork.  And even for someone *with* direct commit
access, a fork provides a backed-up sandbox for changes that aren't ready
for the main repo (even in a branch).

There's a slight difference in whether you need to specify "upstream" in
the "fetch" or "pull" (since you don't normally want to make "upstream"
the default remote), but that's pretty minor.

> manual). You lose the ability to maintain your clone with github's web
> interface, but that's not much of a loss really. (Or you can do their thing
> in reverse: clone the repo, add github as an additional upstream, create a
> new empty repo (not a fork) via their web interface, push to github
> periodically as a backup.)

You *can* do that, but it doesn't really simplify anything, so it's mainly
only useful in cases where the main repo isn't hosted on GitHub (and hence
where "fork" is meaningless).


BTW, it's worth mentioning that "fetch" doesn't touch the working
directory or index at all, so it can safely be done at any time.  Then
after fetching, all the fetched commits are available locally for
examination, diffing, etc.

Fred Wright