Episode: 2162
Title: HPR2162: Review/Criticism of Hipp's "Git: Just Say No"
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2162/hpr2162.mp3
Transcribed: 2025-10-18 15:06:36

---

This is HPR episode 2,162 entitled Reviewsash Criticism on Hip-Hip, just say no, it is hosted
by Clackit and is about 21 minutes long, a summary in which I take a IRC rant for the
O and look at what's really wrong with it.
This episode of HPR is brought to you by an honesthost.com, get 15% discount on all shared
hosting with the offer code HPR15, that's HPR15, better web hosting that's honest and fair
at an honesthost.com.
Hi, I'm Clackit and this is an ambient recording on my way to work.
I haven't recorded the podcast in over one year now and I'm trying to reprioritize
due less surfing while walking and do more talking while walking.
I've been hanging out on all cast planet on free note lately and that's been a great inspiration.
I just made a rant this morning there about something someone else posted and I figured hey,
if I'm going to write all this stuff on IRC I'd better record an episode instead so here we go.
Now, someone posted a link to Richard Hipp, get just say no, Richard Hipp is the creator of Fossil,
which is another version control system and while he was careful not to mention Fossil because
he wanted to focus on Git, I'm probably going to mention it a bit because several of his
criticisms against Git are of course based on his own experience with version control
which is based on his own version control system. So he made a top list of 10 enhancements
that Git needs to do in order to become more useful to users. So I'm just going to ramp these
off pretty quickly and then I will go into submodules and subtrees at the end which was
something that we also talked about on IRC this morning and so let's just get started.
Number one, show descendants of a check-in. So here was going into how to make it more useful.
You could create a relational database on the side of Git, not replace the Git model,
but create some auxiliary data that you can do look ups in and that would allow you to, for
example, see all commits made between certain dates or see all descendants of a particular commit.
So he wanted to see, okay, I made this commit which introduced this feature and then what
have people done with the codes since then. So this happened and then what corrections
have people made or what branches have they forked off this particular commit.
And he was showing an example that if I have this SQL model I can actually find out what's
the first ever commit to the Git repository itself. And it takes only 3 milliseconds and if I do it
using Git it will take a whole second and I'm thinking so what's the problem if you can
take what is probably the oldest Git project, Git itself. It's possible that the Linux kernel
got into Git earlier I would have to check that but certainly one of the two oldest Git projects
is Git itself. It's over 10 years old it has definitely seen a lot of activity and even though
the model is that you only know the latest commits directly and they have to trace their
parentage all the way back to find the first commit. It still takes just a second to do that. I
don't think that's a big problem in usability. And he was talking about, oh finding commits
around a certain date. I'll do that all the time. I do Git log a pretty format one line and then
I put that into less and I just grab for whatever date I'm looking for. So I don't think that's
a valid criticism. Number two simplified mental model yes. The data format is quite simple
but the way it transfers into version control and the way the commands have been
designed around the version control is definitely not optimal.
So I would like to branch into a discussion of the Gitless project here but I haven't looked at it
so that'll have to be another episode. There's lots of fodder for further episodes here.
But I think it's pretty uncontroversial to say that Git's commands are inconsistent.
There are many steps from work tree to published branch. There's the Git index which almost no other
version control system has and I'm saying that is a negative thing. Even though Linux probably
thinks it's a good thing and I actually use it but I can understand how it makes things complicated
when you're trying to get the hang of this. So you have your work tree, you have your Git index,
you have your local branch, you have your local replica of the upstream branch and then you have
the actual upstream branch and then a repo on another server. So 0.2 definitely valid criticism but
he's not unique in making that criticism and you could fix this without giving up Git so I don't
think it fits into the Git just so you know sort of shelf. Number three remember branch history.
He says this is a big feature that people complain about a lot. I have never felt the need to know
branch history. If it's code it's code and it's in there. If you do merges and you name your branches
you can see in the merge commit which branch it came from. I've been working a lot in Bazaar before
and it has branch naming and you can see which branch commits came from but I never felt that this
was super valuable information. So I guess number three for some people but I haven't seen it
as a big issue. Number four is multiple checkouts from the same repo. I haven't checked when his
presentation is from but I use Git work tree at work and it works great. The only problem I have
with Git work tree people have been calling it a hack but I think it came in over two years ago
and now it's definitely not a hack. It's a rock solid I use it and the only problem I have is
we have build scripts that depend on the Git on disk structure to handle dependencies and stuff
like that and they screw up when they see my unorthodox Git setup but I would say that's a
problem with our build scripts and not with Git work tree as a feature and I'll get back to
dependencies on on disk formats at the end. Slice checkouts and clowns. So here he's talking about
how in subversion you can have the whole world in a subversion repo and you can choose to just
observe part of the world. I want to check out this sub directory and I want to work on that and
do commits and that's trivial to do in subversion. Git has this feature now I haven't tried to use it
but I know it's in there I don't know if you can make it fetch just parts of trees or if you
still have to fetch complete commits but it should be doable if enough people want it it's going
to be fixed. So once again I don't know when this video was made.
Six check out and commit against the remote repo. Yeah sure like I said before I've been working
in Bazaar and it got this feature after being out there for a couple of years that you could make
dependent checkout that didn't have a local repo. I guess that would simplify things for people but
I think for me I have never felt that oh I wish I could at least latency to every command.
If you do a shallow clone then you just download the latest commit
and then when you're working on that commit you're looking around the tree everything is local you
can commit to it you can push it. I don't think being able to do it without even having one commit
downloaded would add a lot of value. Apart from maybe the thing we mentioned in point one that
point two that there's a lot of steps from a remote branch to the local tree and this would
remove even one more step in the cases where you know that you're absolutely not going to go
offline you're on the local network with the server and so on. But I don't feel like it's a super
big issue not worth saying that this is an enhancement that goes into Git or otherwise you need to
stay away from Git. And I have to admit I was listening to this last night I was lying down in
bed put on the headphones turn on the YouTube video so from this point on I actually didn't pay
attention so I'm just going to do the points real quick. Seven a busy box version of Git
I'm guessing Git has a sprawling architecture with binaries all over the place
maybe he wants it to all to go into one binary and I'm guessing that's what fossil dust there's
probably just one fossil command and this makes for really easy deployment and so on but I don't
know Git is made out of Unix philosophy whole cloth there's parts of Git written in C there's parts
of Git written in Pearl and it all just fits together through the shell model and pipelines and
all that I think it works pretty well eight all comes the HTTP HTTPS well Git does have HTTP and
HTTPS and it's a good place to to have interoperability with with everything but I think
having an SS agent interface just like subversion did before or still does but I don't use it
being able to just SS agent run the Git command there that's a pretty good model and it's something
that many commands would actually benefit from having available so it does have they should be
interface that works but I don't see why it should have only that the other way works really well
and you still want to be able to handle local repositories so you still have
all that cloning and fetching between local repositories functionality available in Git
and then adding the SS agent interface to be able to do that remotely that's that's not really a big
nine Git all command I'm just gonna skip that I don't know what that's about 10 Git serve command
I understand that fossil has a built-in HTTP server and it's probably awesome
Git has Git serve and it sucks so there's a lot of caveats there and do's and don'ts
and I would just say yeah okay don't use Git serve because it sucks use goggles
goggles easy to deploy and it has all kinds of neat features
so that's my quick review of this git just say no video if anyone else has seen the whole video
and has more comments I would be happy to hear them and then finally in IRC we were talking about
Git submodules and Git subtrees we use Git submodules at work for internal dependencies I have
this Git repo here and it depends on code that is in this that Git repo over there
and it works and basically if you want to have data in one place refer to data in another place
there's basically two ways you can do it you can do it by reference or you can do it by value
Git submodules does it by reference there's a magic blob of type submodule that says
this here is a reference to another Git repo with this commit
if you do it by value that's Git subtrees it doesn't have any
particular manifestation in the local repo it's just a directory that you handle normally you do
commits to it and so on but then the subtree tool allows you to treat that sub directory as a
sort of repo that you can clone into an actual repo and you can do work in the subtree clone
and then you can merge that back into the big repo if you want to
so both ways probably work and I can see situations where people will use them
but I think in probably all situations it's better to not rely on your
version control system for managing dependencies at all do proper packaging do binary deliveries
with versioning have some kind of dependency manager pull things in put them in some
known place and have your build script fetch things from there source code integration is a really
bad idea I've been using in my previous work clear case and if if people say that Git is not really
a versioning system it's a timeline and objects and trees storage system with a versioning
system built on top and clear case is a file version storage with commits bolted on top
and there's basically no one in a company that uses clear case that understands what it really does
and when I started working at this place I found a great guide to clear case for I think it was
for CVS users and it explained what actually happens under the hood in clear case and people
who were doing work daily in clear case they were using these
ready made commands and frameworks and stuff that had been produced locally in that company
and they had no idea what was going on under the hood I asked people around so what does it do
this or what does it do that and it quickly became clear that I was the only one in the department
that had even tried to figure out what clear case actually does so whenever I run into an issue with
Git like wow the Git repo is pretty well compressed but I have to check it out to access these files
what if I could do a virtual file system on top of it okay no now I'm trying to do clear case and
Git again don't go there and we get some modules you're doing something that is pretty common in
clear case or at least that's what we did in the place I was working that you have your thing
that you're working on and then you have dependencies and other things and then you have in clear
case you have filters so it's like show me according to some expression a version of this
directory and they have clear case includes checked in to clear case so you're checking out one
part of clear case and it has defines of what other parts of clear case should look like if you're
coming from this directory and you have a specific version there's magical environment variables
that tell the system where you're coming from and you're actually working in a virtual file system
you could do this with Git and you would be wrong in doing so so if you run into problems like
oh I had to check out this big thing and I actually don't need it it's all source code that is
used by some other part of my repository maybe you should just have a smaller repository and
make the other thing compile and have some binary blob put somewhere outside the
versioning system that your build system can take care of putting in there don't put too much
into one repo I know there's people who really like the one big repo thing and I get where they're
coming from too and I'm not going to say that Google doesn't know what they're doing but you really
need to have good ways of working and good ways of handling these huge repositories if you're
going to have one big repo and I think drawing boundaries between different products within your
company or within whatever team you're working in can be a good way to enforce discipline and
actually know what you're doing the one drawback with dependency management and and versioning
of binary deliverables it becomes difficult to do non backward compatible changes
but then I'd say okay then stop doing non backward compatible changes I know sometimes you have
to do them but in many cases there are good ways to stay away from them and so that's all I have
to say about Git from this time and I hope I'll be recording again soon
you've been listening to hecka public radio at hecka public radio dot org we are a community podcast
network that releases shows every weekday Monday through Friday today's show like all our shows
was contributed by an hbr listener like yourself if you ever thought of recording a podcast
then click on our contributing to find out how easy it really is hecka public radio was found
by the digital dog pound and the infonomican computer club and it's part of the binary revolution
at binrev.com if you have comments on today's show please email the host directly leave a comment
on the website or record a follow-up episode yourself unless otherwise status today's show is
released on the creative comments attribution share a light 3.0 license