Points for Git?

[PeterX]

I just came up with the idea that I should withdraw from git for developing and publishing, and shift to publishing release tar-balls.

Maybe I am thinking to naive? Do you have any point for using git?

Greetings
Peter

[smcameron]

git bisect has more than once saved me a lot of time debugging.

For open source stuff, it can occasionally be important to know who wrote what part of the code, git can help with this (git annotate).

git annotate also can help when you're reading your old code and wondering why you did something. Look up the relevant commit(s) and read the commit message(s), and if you don't suck at making commits, more than likely it will tell you why you did it.

If you ever need to revert certain features, git will generally make this a lot easier and safer than manually reverting.

If you want to encourage other people to collaborate with you, a git repo will be 1000x more attractive than a tarball full of source code.

If you're lackadaisical about grooming your commits and just commit heaps of crap willy nilly with crappy commit messages and different stuff all mixed together in the same commits and never collaborate with others, then git might not buy you much. OTOH, the linux kernel was developed using tarball releases, patches, and an email list for years before bitkeeper and then git were eventually used, so it's not impossible to skip version control, even in a big, higly collaborative project, but I wouldn't recommend it.

[drummyfish]

Have you considered Darcs? https://hub.darcs.net/

[PeterX]

Thanks, smcameron for the useful answer.

And thanks, Drummyfish, for the darcs link.

Greetings
Peter

[ffaf]

Why not? Many older software is still released as tarballs and everything is fine.
There are benefits in using git (as nicely illustrated by smcameron) but also costs (yet another tool in the toolchain).

With tarballs I open the folder, make some change, `tar` it and *bam*, into the ftp it goes: there is less friction than any VCS (even Darcs, which has superb user experience). Same with hosting: when possible I prefer to host things myself: any hosting (even a crummy shared one) will handle a tarball.

I suspect there are good reasons not to use tarballs:
• when you are frequently collaborating with friends/colleagues on the same portion of a codebase (branches, darcs cherrypicking)
• when you need to debug deeply nested/integrated systems (bisect)
• when your software need some special setup to get up and running for compilation (submodules)

I realise for my last 3 games I could have done without a VCS just fine.

[PeterX]

Why not? Many older software is still released as tarballs and everything is fine.
There are benefits in using git (as nicely illustrated by smcameron) but also costs (yet another tool in the toolchain).

With tarballs I open the folder, make some change, `tar` it and *bam*, into the ftp it goes: there is less friction than any VCS (even Darcs, which has superb user experience). Same with hosting: when possible I prefer to host things myself: any hosting (even a crummy shared one) will handle a tarball.

I suspect there are good reasons not to use tarballs:
• when you are frequently collaborating with friends/colleagues on the same portion of a codebase (branches, darcs cherrypicking)
• when you need to debug deeply nested/integrated systems (bisect)
• when your software need some special setup to get up and running for compilation (submodules)

I realise for my last 3 games I could have done without a VCS just fine.

Yeah, all true!

Since I (a) have a relative easy code structure and (b) am in the state where it is too early for co-programmers, I won't use A VCS.

Greetings
Peter

[Julius]

Hmm, that is actually a somewhat interesting topic, although I don't think developing (with more than one person) on tarballs is a good idea.

But I really don't like the overly complicated way of how staging and PRs are managed in git. Sure it probably makes sense in some large code bases (like the Linux kernel), but I would rather have something simple that allows easy collaboration between coders but also other contributors like artists (who do contribute scripts and shaders etc.). In my experience git is a significant barrier for getting non-coders to use a shared repository.

Would darcs be better suited for something like that? Any other suggestions?

Edit: hmm darcs seems to be a largely abandoned code-base?

[smcameron]

With tarballs I open the folder, make some change, `tar` it and *bam*, into the ftp it goes: there is less friction than any VCS

This strikes me as a matter of opinion rather than fact. To me, your process sounds like more friction than using git rather than less friction.

FTP? low friction? I mean, come on.

Your process:

1. tar xf blah.tar.gz
2. cd blah
3. vi blah.c
4. cd ..
5. tar czf ./new new.tar.gz
6. ftp blah
7. enter username/password
8. cd wherever
9. binary
10. put new.tar.gz
11. quit

For subsequent changes repeat 2 through 11.

git process:

1. git clone blah-blah (or git pull, or skip this all together if you're working solo and have already done this step before.)
2. cd blah
3. vi blah.c
4. git add blah.c
5. git commit -m 'blah'
6. git push (only needed if you have a remote repo, on e.g. github. If you're using a local git repo only this is not needed. But for apples to apples comparison, presumably if you're using FTP, you're wanting it for distribution purposes, so presumably in the git scenario, you'd want a remote git repo for distribution purposes.)

For subsequent changes, repeat steps 3 through 6.

I don't know man, git seems lower friction to me, I think your way seems lower friction for you because it's what you know and are familiar with, not because it's inherently less friction than using a VCS.

[PeterX]

I don't know man, git seems lower friction, I think your way seems lower friction for you because it's what you know and are familiar with, not because it's inherently less friction than using a VCS.

Hehe, good point. Maybe it's simpler when using GUI tools for creating the archive and uploading it to FTP?

The whole source archive is easier to understand if it's a tarball, or am I wrong on this? But on the other hand it's harder with tarballs to undo changes that turned out to be the wrong way.

Greetings
Peter

[Julius]

Hmm anyone tried fossil's autosync: https://www.fossil-scm.org/home/doc/tru ... i#workflow ?

[PeterX]

Hmm anyone tried fossil's autosync: https://www.fossil-scm.org/home/doc/tru ... i#workflow ?

Interesting stuff. A lot of people have put a lot of good thoughts into those VCSs.

Greetings
Peter

[drummyfish]

By now I am developing alone, so I don't use git for collaboration, I don't use branches, but I still use git mainly because:

- I have a backup, both of the project and of old versions, locally on several of my computers and on the Internet. Can't stress backups enough. If I break something I can stash and get a step back. Sometimes I need to go crazy and break the project to move it forward and with git I am simply not afraid to.
- Every once in a while I find regression and with git I can locate exactly the point at which it happened.
- It synchronizes with any git hosting super easily, my stuff is on the Internet, easily accessible, viewable in browser, people can see what I'm working on, it's all backed up by the internet archive etc. Most git hostings also provide you with a link to raw plain text as well as the whole project zipped -- this is also comfy.
- There are convenient commands like "git diff" that shows you all changes in all files you've done since the previous commit. Comes in handy a lot of times.
- I like to have the development documented, even if just for motivation or making fun visualizations.
- The cost for this is basically zero, I just commit + push every once in a while with a single line in terminal.

[PeterX]

- Every once in a while I find regression and with git I can locate exactly the point at which it happened.

Someone already mentioned that and I think he said it's "git bisect" I wonder how it works (internally), because git doesn't compile it through all the versions.

Greetings
Peter

[smcameron]

I wonder how it works

It's dirt simple.

You basically tell git that revision X works and revision Y doesn't. There are some number of revisions between X and Y, maybe it's 10, maybe it's 100, maybe it's 1000, but there's a linear sequence of revisions between X and Y, and there are N revisions between X and Y, inclusive. You tell git that you want to bisect the revisions between X and Y, so it says, "alright fine, I'll checkout revision X + N / 2, and you tell me whether it works or not." It's up to you to compile it and run it and figure out whether it works or not, but the checkout is automatic and more or less instant. So you run your test, and then you tell git whether it worked or not by "git bisect good" or "git bisect bad". The instant you tell git whether it worked or not, it then checks out either revision X + N / 2 + N / 4 or X + N / 2 - N / 4. Then you compile and run and test that one. And you tell git whether it's good or bad. And then git checks out the next suspect by a similar binary search methodology. and you repeat. On the order of log(N) attempts, you isolate the problem down to the culprit commit, which is to say, at some point during this process, git tells you "the first bad commit is Q!". That is, presuming it's a straightforward bug not exhibiting non-deterministic, random behavior due to race conditions or what have you that prevent your tests from being properly diagnostic.

At the core of it, git bisect simply automates the process of checking out suspect revisions for you to test in an optimal sequence to provide the most information at each step about where the bug originated, assuming the bug exhibits deterministic behavior. (I think there's even a way to provide automated tests in this process, which would be handy if N is very large, and if the test is not too hard to automate, but I've never tried that particular feature.)

[Ntech]

Git is not a publishing tool, it's version control. If you just want to organize your code, you can do that without git. What git does is manage everything about your code's history, allow you to rollback changes, structure branches, and collaborate more effectively with others.

If you're making backups of old tarballs of prior versions, that's what git is for. If you and another developer are spending unnecessary time transferring files from your local workspace to a centralized repository, that's what git is for. If you have to manually upload files anywhere, that's what git is for. If you spend time working on source distribution, use git. While git is not necessary, if you need (or want) any aspects of VC on your code, use a VCS.

[smcameron]

Git is not a publishing tool, it's version control.

This borders on dishonesty. It's version control, but *distributed* version control, and the distributed part entails publishing. Sure, the *primary* purpose of git is not distribution, but git *does do*distribution. Particularly if you consider hosters like github or gitlab. If you want to publish *source code*, (and considering this is a forum about open source game coding ... then don't we all want to publish source code?) then there's hardly a better platform to do so than github or gitlab, or even your own private git repo, which all rely on git to do the nuts and bolts of publishing. To say "git is not a publishing tool, it's version control." is to be deliberately and extremely obtuse. You may continue to hold that wrong opinion if you must, but you'll still be wrong.

[Lyberta]

Deleted.

[bzt]

I don't think you need to choose between those because they are totally different things, therefore they're not subtitudes of each other.

- git is a version control system, nothing more. It cannot publish anything on it's own, and it does not provide tarballs nor web interface either.
- tarball is just an archive, not capable of keeping logs of changes and you cannot distribute those without a webserver / ftp server etc.

Now there are code hosting services like github, gitlab and notabug which are web frontends for git. Those can do both: they can provide you a remote git repository as well as a tarball. For example
- https://github.com/fogleman/Craft.git is for the remote repository, you can use it with "git clone" (could be a "git://" or "ssh://" url as well)
- https://github.com/fogleman/Craft is a web page which uses the repository's files as contents for the generated HTML
- https://github.com/fogleman/Craft/archive/refs/heads/master.zip is an url of a tarball that the code hosting service generates from the repo

All the additional features (web page and tarball) are provided by the code hosting service, not git. For example, you can install gitlab portal on your own webserver, there's no need to use the official gitlab.com server, and it can generate tarballs (not only zip, but classic tar.gz tarballs too.)

But you could also have a remote git repository on the server, and no code hosting engine at all, just a ca. 100 SLoC php code to generate the latest tarball. That way you can have a git and a tarball too, without the web interface.
Or you could just run git locally, run tar on your machine and upload it to a static webserver.
Or just keep local files, run tar and use a static webserver.

There are advantages and disadvantages:
local git + code hosting
Easy workflow, backup of your code, not have to worry about tarballs (they always contain the latest because they are generated)
local git + own webserver + own code hosting portal
Easy workflow, backup of your code, not have to worry about tarballs, plus no 3rd party has your code (you're running the gitlab portal on your own server)
local git + remote git + tarball generation
Easy workflow, backup of your code, not have to worry about tarballs, plus no 3rd party has your code (you're running remote git on your server), but there's no code browsing web interface for your code, only the tarball urls work
local git + local tarball generation + static webserver
No backups (!), plus you have to pay attention if you've uploaded the latest tarball or not
no git + local tarball generation + static webserver
Worst of all. No versioning, no backups (!), manual checking for latest tarballs.

Hope this answers your question.

Cheers,
bzt

[zzo38]

Version control systems are helpful for development and keeping track of history, etc, but you do not have to use git; there are other version control systems too (I use Fossil for my own projects; I think that it is much less confusing than git in many ways). Furthermore, you can use it locally, remotely, or both (I store it locally but make remote mirrors too; both are available to the public). You can still make tarball files for released versions if wanted; this is still going to be useful. Therefore, you can do both.

[freem]

tarball-based history is basically doing this "cp bla bla.old", this method even have a nick: cp.old. It's likely to result in a huge mess after versions .old.old.old (or, the windows way: (1), (2), etc).

Also, git *can* generate tarballs since years.

Anyway, git is not the only DVCS: bazzar, mercurial, fossil, pijul, darc... As for the non distributed: SVN, CVS. All those are free as in free speech and free beer.