undefined | Better HN

0 pointsbmitc5y ago0 comments

> Once you wrap your mind around what commits, heads and remotes are and learn to rebase you get an incredibly simple and fine-grained control.

> Git is like a chef's knife: extremely powerful tool that's dangerous in untrained hands.

Although, this is all part of the problem with Git. The problem is that it exposes this fine-grained control and knife's edge to the user by default. There isn't some simpler model that people can work with.

I cut my teeth on source-code control with Perforce. Of course, Perforce has many complex features, including stuff like workspaces, which as far as I can tell, Git doesn't have something like that. Anyway, despite its complex feature set, Perforce can be explained in a few minutes. You have some code in the repository. If you want to work on it, you check it out and it gets added to a changelist. If you want exclusive change rights, you can lock it to prevent others. If you want others to see what you're working on, you can shelve your changes without submitting so that they can inspect. When you're done, you submit your changelist. All of this can be done via excellent visual tooling or the command line. I highlighted things with italics because these are the right words for the actions in how Perforce calls them. It's intuitive.

For Git, it isn't that simple. You must first explain a wide swath of concepts. I've explained Git to people, even using the GitHub Desktop app. It is very confusing and intimidating to people, and rightfully so. It confuses me, and I did some pretty advanced things with Perforce (and thus source-code control) before. And there's no default visual tooling. Git also has many names for things that are confusing. Also, Git was invented for a very specific purpose: Linux kernel development. The vast majority of development does not need the same complexity that such a niche development process needs.

When I recently wanted to do something in Git, I just could not figure it out. Probably simple for a Git expert, which is something I am not, but after searching many forum posts, I gave up because every answer was different and caveated in different ways and wasn't working for me. I installed GitKraken and solved my problem in seconds via a single right-click. Maybe I'm an idiot and I don't understand Git that well; both are likely true. But I am able to understand other complex things, so something is amiss. I think the primary issue is that Git requires me to study it just to use it in basic ways. I have an allergy to overly complex things, and so it's just a constant struggle for me. I tend to use visual tools for merging, diffing, managing commits, etc. so that I stay away from the Git CLI, which exposes the complexity in a non-usable way.

Lastly, Git is very narrow minded when it comes to things it controls. It assumes everything should be text.

0 comments

7 comments · 2 top-level

tsimionescu5y ago· 5 in thread

Absolutely agree! Coming from P4 to Git, Git is just constantly getting in the way.

I need to make more decisions because of its limitations (single repo or one repo per module? Or maybe use submodules somehow? With P4, we had a single repo with all of the code of the entire organization).

Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?

If I want to checkout a new branch while I have work in progress, do I commit it and later amend or revert, or do I stash it? Or do I rely on autostash?

Do I push directly to main, or do I rely on pull requests? Should those merge or squash commits?

I understand that all of these options and concepts make sense for distributed orgs, like the Linux kernel dev community and many other opensource projects. But I don't understand why so many traditional organizations are adopting Git. Its model is way too complex for the way normal orgs work (1 centralized server as the source of truth for the whole project), and it has serious limitations for anything which isn't pure code and isn't carefully curated.

PaulDavisThe1st5y ago

>Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?

From my perspective, these are policy decisions that need to be made by some "management-ish" level. Git provides the mechanism to do all of them. It's up to you/your organization to decide how to work.

In the open source project that I run (20 years, 75+ developers over time, 400-500k LOC) we all have a clear understanding of (e.g.) whether to merge or rebase. On the odd occasions that there's a lack of clarity, it's normally a great sign that it doesn't matter.

The fact the you would be asking those questions suggests to me that the necessary policy-level decisions have not been made (or have not been made clear).

tsimionescu5y ago

I'm not saying this is a decision every dev has to make. I am complaining about having to make these decisions as a team or team lead. Having choices is only nice if there are important use cases where each choice is useful, and if the difference is big enough. Otherwise, the choices are just adding complexity and buyer's remorse.

For most unitary organizations, some of the options that git gives you make no sense at all. That doesn't mean git should change, it means that it's not a great tool for unitary organizations.

Note that some of the choices (e.g. stash vs commit) are choices that each dev has to make individually, and some are pure incidental complexity.

1 more reply

bmitcOP5y ago

Those are hard decisions to make in organically developed organizations like companies.

Part of the problem is that Git, to make it manageable, requires all of these types of concerns and decisions to be addressed, and secondly, it has somehow become the only standard that people have even heard of. There isn't even a decision about which system to use anymore.

Having used both, I still prefer Perforce over Git. And if it were up to me, I would take a step back and investigate other offerings like Plastic SCM. But trying to make these decisions is nearly impossible now that Git is treated as a given.

1 more reply

f1refly5y ago

Coming from p4 to git, I thanked the heavens for not having to use this piece of garbage anymore! File locks? Multiple changelists? God forbid that one colleague who checked out some file went on vacation, neverending fun talking to admins of the server to do something about that! Rebasing commits? Own branches? Own repos? Nope!

tsimionescu5y ago

I miss multiple changelists so much! I very often am working on a longer feature when I also get some small bug, and it's so nice to organize that into a separate changelist.

Also, file locks are awesome if you're working with binary files (a thing that P4, unlike Git, can actually do), or even when doing a big refactoring that you know will cause conflicts with any other change. Otherwise, at least on our server, we very rarely used them (ignoring the temporary lock just as you're submitting code).

I'm not sure what you mean about rebasing. The basic P4 workflow is equivalent to `git pull --rebase`. In fact, it's pretty hard NOT to rebase in P4.

Also, why is your own branch useful actually? Nevermind your own repo? You can always just keep multiple copies of the code if you really want to.

Also, with P4 you don't have to cleanup your whole working set just to switch branch - it's just a `cd` away!

Of course, different strokes for different folks and all that.

yawaramin5y ago

I feel like I'm back in the aughties reading this post :-) These arguments were all made back in the day, substituting in CVS or Subversion or what have you for Perforce. And yet time marched on and millions of people found that, yes, they could indeed use git. Especially with all the UIs that have sprung up around it. That's the thing really–you don't need to be an expert git CLI user to get value from git. You just need to find one or more UIs that do what you need.

j / k navigate · click thread line to collapse

0 comments

7 comments · 2 top-level

tsimionescu5y ago· 5 in thread

Absolutely agree! Coming from P4 to Git, Git is just constantly getting in the way.

Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?

If I want to checkout a new branch while I have work in progress, do I commit it and later amend or revert, or do I stash it? Or do I rely on autostash?

Do I push directly to main, or do I rely on pull requests? Should those merge or squash commits?

PaulDavisThe1st5y ago

>Should I rebase or merge? Or squash commits? Should I cherry pick onto a new branch?

The fact the you would be asking those questions suggests to me that the necessary policy-level decisions have not been made (or have not been made clear).

tsimionescu5y ago

For most unitary organizations, some of the options that git gives you make no sense at all. That doesn't mean git should change, it means that it's not a great tool for unitary organizations.

Note that some of the choices (e.g. stash vs commit) are choices that each dev has to make individually, and some are pure incidental complexity.

1 more reply

bmitcOP5y ago

Those are hard decisions to make in organically developed organizations like companies.

1 more reply

f1refly5y ago

tsimionescu5y ago

I miss multiple changelists so much! I very often am working on a longer feature when I also get some small bug, and it's so nice to organize that into a separate changelist.

I'm not sure what you mean about rebasing. The basic P4 workflow is equivalent to `git pull --rebase`. In fact, it's pretty hard NOT to rebase in P4.

Also, why is your own branch useful actually? Nevermind your own repo? You can always just keep multiple copies of the code if you really want to.

Also, with P4 you don't have to cleanup your whole working set just to switch branch - it's just a `cd` away!

Of course, different strokes for different folks and all that.

yawaramin5y ago

j / k navigate · click thread line to collapse