More Git

[wraith808]

I have a lot of projects for personal use- development and non-development work (writing and such).  I've tried multiple projects in one repo, and one repo per project.  I've seen a lot of different arguments for either, and a lot of them on both sides have referred to my pain points - shared libraries, repo overload, etc.  I was also looking at this stackoverflow question, and it brought up more questions than answers.

I was just wondering as a lot of people use Git around here, what are your personal preferences and why?  And no, I'm not looking at this point to transfer to another VCS.  I settled on Git a while ago, so that decision is made.

[Deozaan]

My answer probably won't be of much help to you, since I primarily use Mercurial (Hg) and have only dabbled with Git.

I've looked into similar options for Hg and found that it's too much of a hassle having to deal with subrepos and getting them configured correctly. So I just end up with lots of copies of the same kinds of files (libraries, or general purpose scripts that I reuse over many different projects), and I have to try to remember which project I was working on most recently when I updated shared general purpose script if I forgot to update it in my standard directory where I store my scripted tools.

It's a hassle, but from my research in Hg, it's less of a hassle doing it this way than trying to deal with subrepos.

That said, I think Git handles subrepos (aka submodules) differently and perhaps in a way that makes more sense and is easier to use than Mercurial does. The linked StackOverflow question/answer seems to suggest that that is the case.

Anyway, sorry for my mostly non-helpful response. Hopefully someone who is a lot more familiar with Git can provide you some real assistance.

[Jibz]

For my own work, I aim to have one repo per project. Here are some reasons:

• Unless the projects are very strongly connected, separate repos means you have a clear development history for each.
• Git usually means branching -- and branching all projects to work on a change in one of them is silly (even if it's cheap)
• If one of the projects becomes useful to other people, it will be easier if they can clone that alone
• If you use submodules to include a library, you know the exact version (commit) you are using. If you just include the source in multiple project repos you have no idea which changes you may have made in each of them (like Deozaan, I sometimes end up there )
• If you do not use submodules, it can be nice to have the development of the library in a repo of it's own for the three first reasons above

But it will depend on the project. Something like chapters of a book I would not put in separate repos, but a small library that I am likely to reuse in other projects I would (even if it's just a couple of files).

(Btw, I am not necessarily suggesting the use of submodules -- for some things they work well, but also have drawbacks.)

[Tuxman]

I also prefer Mercurial.

Admittedly this is becoming harder and harder with GitKraken which is really nice. 

[f0dder]

What Jibz said.

With the specific addition that it's a repo per project, not necessarily module. Creating a repo for each submodule of a Java EE project would just be insane (you often see those split in Web, EJB and EAR modules).

Heck, at work I've been dealing with a project that consists of three EAR deployments, with use a shared 'commons' library - that's split in four Git repos. While it makes sense to have three different EAR deployments, it might as well have been contained in a single Git repo. I can't think of good reasons to have it split in four, and it makes moving code around (like, factoring out code to the common library) harder (and loses history).

[Jibz]

Admittedly this is becoming harder and harder with GitKraken which is really nice. 

-Tuxman (February 01, 2016, 12:13 PM)

I looked at it the other day, and it seems quite interesting. I like that it does not call out to git-on-windows. Not sure about the license agreement, which looks more like a NDA.

[wraith808]

Admittedly this is becoming harder and harder with GitKraken which is really nice. 

-Tuxman (February 01, 2016, 12:13 PM)

I looked at it the other day, and it seems quite interesting. I like that it does not call out to git-on-windows. Not sure about the license agreement, which looks more like a NDA.

-Jibz (February 03, 2016, 10:25 AM)

That is exactly how I felt when I looked at it in closed beta.  I thought it would switch once they left closed beta.  Maybe it will become clearer when they are out of beta?  It's also not clear if it will ever be a paid app.

[f0dder]

I looked at it the other day, and it seems quite interesting.

-Jibz (February 03, 2016, 10:25 AM)

They don't have much information about the Kraken itself, and their blog spends more time talking about how they made the ZOMG ANIMATED INK BACKGROUND for the website, and they sure do use words like "disrupt" and "risk" a lot. And basing a non-web-application on Node?

Yeah, it's fine - call me a cranky old guy

[Tuxman]

And basing a non-web-application on Node?

-f0dder (February 03, 2016, 06:05 PM)

Them weirdos.

[Tuxman]

Since we talked about this, GitKraken started to be a freemium application. Gladly, the Pro features are not relevant enough for me.