Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shit – An implementation of Git using POSIX shell

git.sr.ht

Post reply on HN
Print view View original

121–130 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#121

Post by buck4roo »

im3w1l wrote: post #43
ddevault wrote: post #29

Earlier quoted context omitted.

You'll use git a hundred times a day, every day, for the rest of your career. It's easily worth the hour it'll take to learn it properly.

It's not a given you will use it for the rest of your career. As two examples, neither Google nor Facebook use git.

I'd add that folks should not be forcing the use of git, even within an organization that uses it.

Mercurial works great, has a sane CLI and can both manipulate and interoperate with git repos.

Many of the tools mentioned, at their core, are manipulating the same DAG data structures.

Re: Shit – An implementation of Git using POSIX shell

#123

Post by reagent_finder »

edflsafoiewq wrote: post #116
na85 wrote: post #101

Earlier quoted context omitted.

I don't think it's asking to have one's hand held to complain about git's poor interface. There's no reason other than lazy design to have a tool where to show all remotes it's $ git remote -v But to show all branches it's $ git branch -a It's like it's been purposefully designed to be obtuse.

It seems like you've made this example obtuse. `git remote` and `git branch` list the remotes and branches respectively. Adding -v makes both of these verbose. It will additionally show what each branch/remote is "pointing at". Adding -a to `git branch` shows remote tracking branches in additional to local branches. This not normally interesting so the default is to list only local branches.

...yes, remote tracking branches are interesting as well, I don't know a situation where they wouldn't be.

There's plenty of weirdness in Git, but honestly my main complaint is that the interface is awful and the documentation makes Dostoyevski look modern and sleek.

Re: Shit – An implementation of Git using POSIX shell

#124

Post by reagent_finder »

aspaceman wrote: post #106
na85 wrote: post #101

Earlier quoted context omitted.

I don't think it's asking to have one's hand held to complain about git's poor interface. There's no reason other than lazy design to have a tool where to show all remotes it's $ git remote -v But to show all branches it's $ git branch -a It's like it's been purposefully designed to be obtuse.

We're all talking about learning the internals of git and how it works, not it's poorly formed command lines. Pointing out how shitty the interface can be doesn't mean you shouldn't learn how your tools work.

You say potato, I say potato. If the interface is clunky, you will learn by heart some switches and pass them on as cargo cult.

Re: Shit – An implementation of Git using POSIX shell

#125

Post by whalesalad »

ddevault wrote: post #22

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

Even with the self deprecating nature of this effort and project: you continue to produce a lot of open source contributions. I see your work and blog all over the place. You’re a machine!

So what’s your secret?

Re: Shit – An implementation of Git using POSIX shell

#127

Post by blub »

ddevault wrote: post #22

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

If it's so hard to learn about this tool and so easy to learn about it the wrong way, that's a pretty obvious hint that there's something wrong with the tool.

Having to learn about the internals is a giveaway that the tool suffers from poor encapsulation.

To me git is definitely one of those tools where one should satisfice and not learn it deeply, because it's not worth the effort. One can successfully stick to a simple workflow and ignore anything git astronauts come up with, like git flow if they want to keep their sanity and focus on what matters - creating quality software. And almost any team has some git fetishist which will be thrilled to help when things go south. And if they don't, it's probably for the better.

Re: Shit – An implementation of Git using POSIX shell

#128

Post by thih9 »

wkjagt wrote: post #52
ddevault wrote: post #22

Hiya HN. I was ranting on Mastodon earlier today because I feel like people learn git the wrong way - from the outside in, instead of the inside out. I reasoned that git internals are pretty simple and easy to understand, and that the supposedly obtuse interface makes a lot more sense when you approach it with an understanding of the fundamentals in hand. I said that the internals were so simple that you could implem…

> instead of the inside out Now the name makes even more sense. I first read it as sh/git, but reading it as something that starts inside and slowly works its way out is now my preferred explanation of the name.

This comment looks like an offtopic pun to me and feels distracting.

Re: Shit – An implementation of Git using POSIX shell

#129

Post by IcePic »

anoncake wrote: post #62
na85 wrote: post #46

Earlier quoted context omitted.

>The conclusion I draw from this is that you can only really use Git if you understand how Git works. I say this as someone who uses git regularly, and who prefers it to all other version control systems I have tried: A tool that breaks the principle of encapsulation by forcing you to grok its internals if you are to have any hope of understanding its arcane and inconsistent usage syntax is frankly not a very good to…

Using Vim requires you to understand how the data it operates on is structured. The same applies to Git. Plain text is just a lot simpler than a VCS repository.

But you can use your awesome vim skill to feed text into a OpenOffice document, and while the OOo internals are probably 100x more complicated than vim, the user interface for "text on my screen" stays the same, and transition is smooth, even though the internals underneath is vastly different. If git requires 'everyone' to know the internals before they can use it, as opposed to rcs,cvs,svn,perforce users who can more easily flip around between those for most basic usages, then its on git for having a complicated shell around a complicated set of internals.

It would have been nice if there was a simpler shell around the complex machinery for those (us?) who don't want to do crazy stuff, who don't need to be able to do crazy stuff and who could settle for only the simple 90% of the tooling like we do with the alternatives, but are forced to use git for external reasons.

Re: Shit – An implementation of Git using POSIX shell

#130

Post by wruza »

anoncake wrote: post #62
na85 wrote: post #46

Earlier quoted context omitted.

>The conclusion I draw from this is that you can only really use Git if you understand how Git works. I say this as someone who uses git regularly, and who prefers it to all other version control systems I have tried: A tool that breaks the principle of encapsulation by forcing you to grok its internals if you are to have any hope of understanding its arcane and inconsistent usage syntax is frankly not a very good to…

Using Vim requires you to understand how the data it operates on is structured. The same applies to Git. Plain text is just a lot simpler than a VCS repository.

Plain text is internally ropes-something, indented with meters of vimscript, colored with a syntax model that is okay to change, hard to create from scratch, etc. it’s all hidden from a regular user who uses a subset of all features.

But if you ignore the non-ms movement, shortcuts and advanced transforms, it is still a text editor that everyone may use. You can’t put your text (text, not a current mode!) into a state that looks okay but requires a vim guru to continue or start over because something is broken in the model. That’s different from git issues where working copy looks okay, but the branch and merge are broken in subtle ways.

>Plain text is just a lot simpler than a VCS repository.

Than a Git repository, not a VCS one. Not saying that VCS = plain text, but much simpler models exist for merging teh codes.

Post reply on HN