Learning how to use SVN/Git, couple questions

[purbeast0]

i'll have to check what i use at work. i think it's just the git bash command prompt that comes with git in general on windows but i could be wrong.

at home here i use git on my osx laptop however i just use command line with gitx for commits.

in general, i use the GUI stuff (at work too) just for commits and viewing the log. i find it easier to use them for basic stuff like that instead of having to type out all of the files and messages in a command line. however, i haven't looked into it very much and am sure there is a simple way to do it command line too.

 

[TheRyuu]

Is there a good command line git for windows that will also allow him to generate ssh keypair? This is for my friend as he develops on Windows. I'm on Linux so I'll be using command line directly from the dev server itself which is where I handle all my code.

msysgit comes with openssh. You can also use puttygen to generate a key pair then convert it to openssh format (with puttygen).

 

[Red Squirrel]

Edit: Nevermind, after a while it actually goes back to the prompt. Would be nice if it gave some indication that it's actually doing something though.

--

Crap, I seem to have run into the lockup issue again.

I was just writing a quick doc and wanted to check the output of doing a clone on the full repo so I did just that:

[root@appdev src]# git clone ssh://server:444/localdata/gitrepos/aov .
Initialized empty Git repository in /network/appdev/dev/svntest/src/.git/
The authenticity of host '[server]:444 ([server]:444)' can't be established.
RSA key fingerprint is ec:4c:9b:28:47:60:b3:40:e1:ca:ce:ff:86:0d:37:0d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[server]:444,[server]:444' (RSA) to the list of known hosts.
remote: Counting objects: 5820, done.
remote: Compressing objects: 100% (3447/3447), done.
remote: Total 5820 (delta 2300), reused 5796 (delta 2293)
Receiving objects: 100% (5820/5820), 23.34 MiB | 5.90 MiB/s, done.
Resolving deltas: 100% (2300/2300), done.

And it just locks up right there. Never returns to the prompt. It looks like this is a known issue and you can ctrl+c out of it but then you end up with conflicts and it's a whole process to fix.

 

[Merad]

Is your version of git updated? I've been using it for about 4 years and have never seen it freeze.

 

[Ken g6]

I've never seen that either. But this looks like a simple way to fix it:

http://stas-blogspot.blogspot.com/2012/12/git-hangs-after-resolving-deltas.html

 

[oMega_2093]

This is for a private project and I rather control my own server. Look what became of sourceforge.

You are thinking the SVN way.

With Git, your local repository is a valid, full, standalone repository. This means that as long as you keep a local copy of the repository, the fall of Github or any other hosting service won't hurt you.

This actually happened to kernel.org...

"Remotes" can be added to your local repository, which are repositories hosted over remote servers you can push to. But there is no "central" repo. You can push to Github, push to Bitbucket, push to your production server, push to your development server... And none of those would be more valid than your local repository.

That said, Bitbucket allows private projects for free for small teams, up to 5 members, if I recall correctly.

My advice is: stop administrating a Git server and start using Git ASAP. Get started with a local repository. Use it, commit to it and branch it. You can push that repo to any remote in any moment and the whole history of commits for the branches you choose will be in the remotes of your choice.

When you are ready using Git confortably, then go with remotes and push to one. Bitbucket is fine. If you have a production Linux server then you can push to it too, and automate deployment with Git hooks.

But start doing that is an invitation to abandon in my opinion. Start simple, and then scale.

 

[Merad]

You are thinking the SVN way.

With Git, your local repository is a valid, full, standalone repository. This means that as long as you keep a local copy of the repository, the fall of Github or any other hosting service won't hurt you.

A very good point. With git, really the only reason to run your own server is if you're developing some kind of ultra confidential code that you absolutely can not or will not entrust to a third party, even if they have private repos.

For personal projects as well a lot of people don't like the idea of making their code public until it's "finished," even if they plan to make it open source. It took me a while to get over that mindset, but honestly there are millions if not billions of projects on GitHub and BitBucket by now, and frankly almost no one cares about what you're working on.

 

[SOFTengCOMPelec]

A very good point. With git, really the only reason to run your own server is if you're developing some kind of ultra confidential code that you absolutely can not or will not entrust to a third party, even if they have private repos.

For personal projects as well a lot of people don't like the idea of making their code public until it's "finished," even if they plan to make it open source. It took me a while to get over that mindset, but honestly there are millions if not billions of projects on GitHub and BitBucket by now, and frankly almost no one cares about what you're working on.

The OPs concerns, which I share and agree with, is that the website that you host your project(s) with today. Might turn into, or be taken over, by a relatively hostile/nasty company, in the future.

They may introduce forced charges, insert adverts/malware/spyware WITHOUT your permission.

They may even take control of a large, and important open source project, WITHOUT any sort of authority or permission, from the projects owners.

SourceForge have recently been accused of changing the master password for the GIMP (I think), open source project (for windows, I think). Leaving the official project leader(s), UNABLE to access/control it.
SourceForge then inserted horrible spyware/malware/adverts or other undesirable stuff, into the open source project.

Also another big example is that google recently closed down (gradually, still partly open), their program hosting service.

But I agree the OP would have been better off, learning the ropes and experimenting, with their own local git, first. Worrying about putting it on servers, later.

 

[Red Squirrel]

Is your version of git updated? I've been using it for about 4 years and have never seen it freeze.

It's whatever is updated with CentOS 6.5, but repos for CentOS tend to be behind at times. Git --version shows 1.7.1.


Also the whole point of this was making collaboration easier, so the server setup was pretty much the #1 priority. I'll learn the branching stuff later as I move along, preferably in a test repo that I setup later. For now I just need an easy way to sync the project between our dev environments for when we're both working on code at same time. The current way is that my friend sends me emails with the scripts and then I have to figure out where they go, so it's kinda cumbersome. I think I mostly got it working now though, just need for him to get himself setup to connect to my server and we'll do some testing.

 

[Merad]

The OPs concerns, which I share and agree with, is that the website that you host your project(s) with today. Might turn into, or be taken over, by a relatively hostile/nasty company, in the future.

Sure, that just happens to be a concern that's bordering on silly. Any company that you interact with could turn malicious and do nasty stuff. As has been pointed out already, with git there's zero danger of you losing your code so long as you keep a local repo up to date.

In the case of Sourceforge, projects like GIMP have ignored years of warning signs. IIRC it was 2012 or 2013 when SF started inserting adware into installers.

With a planned shutdown like Google Code, you're given numerous warnings to migrate to a new host.

Also the whole point of this was making collaboration easier, so the server setup was pretty much the #1 priority. I'll learn the branching stuff later as I move along, preferably in a test repo that I setup later. For now I just need an easy way to sync the project between our dev environments for when we're both working on code at same time. The current way is that my friend sends me emails with the scripts and then I have to figure out where they go, so it's kinda cumbersome. I think I mostly got it working now though, just need for him to get himself setup to connect to my server and we'll do some testing.

It really sounds like you're trying to fight against how git works. Git isn't a syncing tool, it's a source control tool. Normal workflow would go something like:

You put your current code in the remote repo.
You clone the repo locally, make a branch, and start working.
He clones the repo locally, makes a branch, and starts working.
You commit some changes.
He commits some changes.
You commit more changes.
You checkout your master branch and ensure that it's up to date with the remote.
You merge the work from your branch, and push to the remote.
He commits more changes.
He checks out his master and ensures it's up to date with the remote.
He merges his working branch (if you modified the same files, he will probably have to resolve merge conflicts).
He pushes to the remote.

Rinse and repeat.

If you did get set up with something like github, then you can either give him direct access to push to your repo, or you can make him fork it and submit changes to via pull request, basically meaning that you can review and approve his changes.

Edit: Also, 1.7.1 is ludicrously old. I think the current version is like 2.1 or 2.2... even git for Windows is at 1.9.4.

 

[SOFTengCOMPelec]

Sure, that just happens to be a concern that's bordering on silly. Any company that you interact with could turn malicious and do nasty stuff. As has been pointed out already, with git there's zero danger of you losing your code so long as you keep a local repo up to date.

In the case of Sourceforge, projects like GIMP have ignored years of warning signs. IIRC it was 2012 or 2013 when SF started inserting adware into installers.

With a planned shutdown like Google Code, you're given numerous warnings to migrate to a new host.

I only gave you some of the reasons, there are many more.

As an individual or organisation, you may decide to either do adverts, to help pay for things or be really nice, and have no adverts, or something, in between.

But if you use external (free) hosts, you usually CAN'T make them ad free, and if there are adverts, you WON'T get any of the money/benefits from them (usually).

You might want to have lots of statistics, to tell you about who, when, from where, how many times, your stuff is accessed/downloaded. Your own services, will allow you to fully collect that information, to your hearts, desire. Which can help you improve things in the future.

Free/external hosts, may not provide that information, and/or it was not the specific information that you were looking for.

Probably by paying for better services (hosts), you can get some/all of the above, so there are counter arguments you can make.

There can also be limitations, which can end up being a real pain.

Some people like desktop PCs, others really like laptops.

I don't think there are "right" and "wrong" answers here. Both using free/paid external hosts and/or running your own server(s). Are probably both viable options, if someone wants to go down that path.

A person can learn a lot of useful stuff, if they run their own server(s). This can significantly help their careers and/or business activities and/or leisure pursuits. Assuming that is their direction in life.

If you otherwise (job/business/hobby), have little or no involvement with computers/IT, then maybe free/paid external hosts makes a lot more sense.

There is a lot of work involved in setting up server(s), and costs involved. So there are many benefits, for the free/paid services. Even massive companies, sometimes almost exclusively use external (web etc) services, such as cloud etc. (I have been led to believe).

 

[Merad]

I only gave you some of the reasons, there are many more.

Er... OP is talking about a small personal project with 2 devs that isn't public. Basically everything you listed doesn't apply.

 

[SOFTengCOMPelec]

Er... OP is talking about a small personal project with 2 devs that isn't public. Basically everything you listed doesn't apply.

You have failed to change my mind. I still think, the OP is right.

It's a bit like taking trains/buses and taxis everywhere versus buying a car.

The public transport (free/paid hosting), has many advantages and almost zero initial cost.

But there are many advantages to owning a car, even if there is far more work and cost involved.

If you really want to get into how to install and maintain git on a server, you really need to do it for real, rather than use a free, pre-made service.

If you want to learn how to drive, taking trains everywhere, will not help very much.

 

[SOFTengCOMPelec]

It's whatever is updated with CentOS 6.5, but repos for CentOS tend to be behind at times. Git --version shows 1.7.1.


Also the whole point of this was making collaboration easier, so the server setup was pretty much the #1 priority. I'll learn the branching stuff later as I move along, preferably in a test repo that I setup later. For now I just need an easy way to sync the project between our dev environments for when we're both working on code at same time. The current way is that my friend sends me emails with the scripts and then I have to figure out where they go, so it's kinda cumbersome. I think I mostly got it working now though, just need for him to get himself setup to connect to my server and we'll do some testing.

One of the nice features of git, is that you can install open sourced projects, locally, even though you have got nothing to do with their project(s). Some other source control systems, DON'T let you do this, without permission from the project owners and/or they don't even have that ability.

By doing that (actually in the case I am describing, it was not actually git, but another one, but the concept is still the same. But I think there was a git version available as well). I was able to read through some of the huge range of commits with comments, which was very educational.
The huge amount of work, put into some of these open sourced projects, is mind boggling.

There can be like, thousands and thousands of commits, and you can search for a number of different words, and find a number of matches. It really gives an insider view of that project. Especially the WHY they did things the way they did.

It is also another way, you can mess around/practice and learn about git.

 

[Merad]

If you really want to get into how to install and maintain git on a server, you really need to do it for real, rather than use a free, pre-made service.

If you want to learn how to drive, taking trains everywhere, will not help very much.

Do whatever pleases you, but the overwhelming majority of git users are interested in coding, not administering servers.

 

[SOFTengCOMPelec]

Do whatever pleases you, but the overwhelming majority of git users are interested in coding, not administering servers.

I agree.
Also git seems to have gained a fair degree of popularity. Is free (I remember the days when version control software was somewhat expensive), and a good tool to learn how to use. Especially if you are into the programming and/or web creation, stuff.