1. 28
  1.  

  2. 10

    It makes me uncomfortable many people don’t even consider Git as a standalone software. For many it’s just an implementation detail of their Gitlab or other frontend of the month. I’m not sure what to think about it.

    1. 2

      That’s kind of what made me try to dig into Git.

      I also discovered annexes in Git, which are pretty neat (here), but which I deemed out of scope for this article.

      1. 2

        Thought it might be worth linking to the source :^)

        1. 2

          git-annex is quite cool, and an interesting alternative to Git LFS that is easier to maintain yourself (doesn’t require a custom server, and supports multiple servers rather than requiring a canonical one). That being said it makes sense you left it out of this article — it’s not actually “barebones” git, it’s a separate package that’s maintained separately (almost entirely by its original author, Joey Hess).

          1. 1

            annexes look pretty cool, I wouldn’t mind seeing an article with your workflow with that.

            1. 1

              Never seriously tried them, but I might do, and write something on that topic.

              I’m already gonna write an article on man, and writing documentation pages.

        2. 4

          I’ve been using bare git repositories for years now, mostly as a central place to keep my repos, and share them using git-daemon via the git:// protocol.

          A central git server can also act as a simple deployment tool, thanks to git hooks (especially the post-receive one). My personnal blog is deployed this way, using a simple makefile. Whenever I push commits to the server, the post-receive hook (located in /var/git/repo.git/hooks/post-receive) is executed, and basically does the following:

          git clone /var/git/blog.git /tmp/blog
          make -C /tmp/repo PREFIX=/var/www/htdocs/blog install
          rm -rf /tmp/blog
          

          All that is done with nothing else than git and ssh. I use the same mechanics to expose the git repositories as HTML, or populate my port tree for the crux distribution.

          Plain git repos are an extremely simple yet powerful tool, that is (too!) often hidden behind complex CI/CD interfaces like gitlab.

          1. 3

            Adding cgit is also a very simple and nice addition to running your own git server.

            1. 2

              Also worth mentioning as part of the git ecosystem is gitweb, which is provided by default.

              1. 1

                gitweb has a pretty unintuitive and heavy UI, but its biggest selling point is that it’s bundled within git.

                cgit is a cleaner design, but still not up to my tastes (as I’d prefer to have a “simpler” UI), and since it’s not natively provided, it’s a bit more painful to obtain it.

                I may work on some cgit-like daemon or CGI software to have a clean / simple UI to browse git repos, kinda like cgit.

                Note: all the recommendations and ideas that have been shown here and on dev.to have motivated me to start working on a part 2, which will contain concepts such as annexes, hooks, the git daemon / gitweb daemon, and some tips and tricks I found useful.

                1. 3

                  You should give fudge a try! :)

                  1. 2

                    I didn’t know about fudge, and after looking at the code, it looks like it needs a bit of rework (e.g. you are forced to use the YAML format, and the server only listens to localhost:8080 and cannot be configured), but it’s a really good start, thanks!

                    1. 2

                      I have some time to work on it over the holidays, so feel free to open issues! I picked YAML for the configuration format because I was familiar with it, though I wouldn’t mind adding support for another format.

                      1. 1

                        I guess I’ll fork it to have the first changes I’d like to have, then submit a PR so we can discuss what could be integrated right into fudge.

            2. 3

              I use Mercurial this way and this is the essence of DVCS (distributed version control systems). I also set up automatically updated mirrors for Mercurial and Git in order to backup interesting software – it is quite easy and does not require any complex software (only pure Mercurial, Git + some scripts).

              Thanks for this article. I think that it is important to maintain and cultivate basic skills and methods, because they are more than sufficient in many scenarios, and complex solutions are not only superfluous but even harmful. Unfortunately, many IT people are losing these basic skills (or never had them) and are pursuing complex solutions and pile up more and more layers of code.

              1. 3

                Another fun use case for “barebones git” is setting up a super-simple code deployment workflow between your development box (e.g. a laptop) and a home server that’s LAN-accessible.

                You simply clone the git repo on the server, and then configure the client to have the server directory as a “remote”, via an SSH string. You can now do git push server just like you would git push origin for, say, GitHub. And, of course, over a LAN, this is very fast, and less messy than using something like rsync.

                Then, you can have a private GitHub / GitLab repo be the “other” remote. Yes, this is around the time you realize that’s “all” GitHub/GitLab is (at the server level), and thus you were a fool for not starting that startup in 2008 :)

                The nice thing about this is that the server’s git repo state can stay “unpublished”, so you don’t need to worry about a clean commit history. You can push to it all day long, and you’ve got 2 copies (one on your client, and one on your server, giving you peace of mind). The “deploy” of your code to the remote server happens basically “for free”, all you need to do is run git pull or git clone on the remote server in some “deploy” directory, and this can even be automated with a commit hook.

                Then, when you’ve got something “working”, you can cleanup the commit history (e.g. via git rebase) and then push that cleaned commit to your “origin”, wherever in the cloud that may be.

                1. 2

                  And since this is for personal projects, for issue tracking, just use a flat file in the repo (TODO.md or something like that). Keep the file small, if it’s bigger than one page then probably the project is too big. “Closing” an issue is just removing the entry with the commit that fixes it, no need to add a #someid reference in the commit.

                  This actually works surprisingly well for small (1-3) teams as well.

                  1. 3

                    The todo.txt format would fit well here.

                    1. 1

                      Oh wow, that sounds like a good idea. I’m working on a personal git server project as well and I like your idea.

                    2. 2

                      Nice write-up @Artemix, just a little typo I found:

                      then try to find the repository folder group/project.git from user's gome folder.
                      

                      I expect you meant home.

                      1. 1

                        Indeed, I’ll fix that, thanks

                        Edit: fixed

                      2. 0

                        As with almost everything in git the way to run it stand alone is convoluted, complicated and of cause not properly documented on the git web site. It is amazing that people even consider using git stand alone when that is even less bearable than with the plethora of tools that have grown around it that try smoothing its edges. Compare that with howeasy and full featured fossil is and the astonishment is even greater.

                        1. 2

                          Whatever floats your goat.

                          I found fossil to be a less-intuitive / less-featured git clone that’s almost supported nowhere, so I’m sticking with git.

                          1. 1

                            Really? It’s famously difficult to be less intuitive than git, and the only thing I see it having over fossil is adoption (which doesn’t matter in a bare-bones setup). Fossil’s built-in feature list is impressive in comparison.

                            1. 2

                              Again, depends on what you’re used to work with, or how your environment is set.

                              Still has nothing to do with this topic, though.