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

221–230 of 235 posts

Re: Shit – An implementation of Git using POSIX shell

#221

Post by touisteur »

huherto wrote: post #189
JoeAltmaier wrote: post #181

Earlier quoted context omitted.

Its part of a bigger issue - source control tools have wildly different fundamental models. Moving to git from anything else will be confusing, because users jump to conclusion about what commands and operations are doing. Its different from other tools in important ways.

I moved from SCCS to RCS to CVS to Subversion to Git. Moving to Git was the more difficult step for me. I prefer it now. For a while I had to move back to Subversion and I hated it.

Can't use svn for the life of me, though I used it for 10 years before trying git for a real dvcs need (remote team for a while)...

Just the idea pains me. Missing git add -p, cherry-pick & rebase -i so much I immediately put git-svn on if I have to go back...

Also, it makes telecommuting easier, asynchronous team work so much simpler...

I think the key 'abstraction' that people don't understand is cherry-pick. I can't explain clearly in fine details /how/ it works, but it is the base of so much of git's power...

Re: Shit – An implementation of Git using POSIX shell

#222

Post by Ace17 »

wyclif wrote: post #220
blub wrote: post #127

Earlier quoted context omitted.

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 si…

Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this: Coworker: "I really hate Git, it's so hard to understand what's going on internally." Git guy: "Did you read the documentation?" Coworker: "Nope." Git guy: "Did you read Git - book?" Coworker: "Nope." Git guy: "Did you read Scott Chacon's 'Pro Git'?" Coworker: "Nope." Git guy: "..."

The likelihood for this conversation to occur, in a way, also depends on the tool itself, and tells us something about it.

As a matter of fact, git is hard to use.

The question is: keeping the same level of functionality, could it have been made easy to use?

Re: Shit – An implementation of Git using POSIX shell

#223

Post by Const-me »

viraptor wrote: post #162
Const-me wrote: post #137

Earlier quoted context omitted.

> Hosting videos with short response time in any region Clouds are indeed selling that, but I think that's false advertisement. At least from here (western Balkans) it looks this way.

Not sure what you mean by false advertisement. Australia-Netherlands (common European pop) connection is often >300ms from a home connection. Home in Australia to Sydney pop is likely <10ms. It makes a massive difference with many small resources, or restarted transfers. That's just physics at some point.

> Not sure what you mean by false advertisement.

Here, the roundtrip latency is ~14ms within the country (e.g. from here to capital city), and 40ms to the closest AWS or GCP datacenters (both are in Frankfurt).

Re: Shit – An implementation of Git using POSIX shell

#224

Post by bigyanshr »

bigyanshr wrote: post #122

What's wrong with people nowadays? Couldn't they come with a better name ?

I don't care about the negative/down votes, but this is literally shit. Imagine the communication:

* Here in our project we use shit, and it's very good. * do "shit pull" / "shit pop" * Sorry, I don't have shit in my machine.

But, again, english is a funny language.

Re: Shit – An implementation of Git using POSIX shell

#225

Post by p_l »

Ace17 wrote: post #222
wyclif wrote: post #220

Earlier quoted context omitted.

Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this: Coworker: "I really hate Git, it's so hard to understand what's going on internally." Git guy: "Did you read the documentation?" Coworker: "Nope." Git guy: "Did you read Git - book?" Coworker: "Nope." Git guy: "Did you read Scott Chacon's 'Pro Git'?" Coworker: "Nope." Git guy: "..."

The likelihood for this conversation to occur, in a way, also depends on the tool itself, and tells us something about it. As a matter of fact, git is hard to use. The question is: keeping the same level of functionality, could it have been made easy to use?

It also speaks about the quality of users as a whole - we somehow forgot to RTFM at all or lead people to documentations, simultaneously accepting lack of documentation in a vicious cycle.

Re: Shit – An implementation of Git using POSIX shell

#226

Post by na85 »

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.

>We're all talking about learning the internals of git and how it works, not it's poorly formed command lines.

But the argument is being put forward that to understand the command lines you have to understand the internals.

Re: Shit – An implementation of Git using POSIX shell

#227

Post by Hello71 »

acqq wrote: post #216
Hello71 wrote: post #203

Earlier quoted context omitted.

what the fuck? I specified POSIX alternatives to non-POSIX uses in the code. only one feature, brace expansion, is not POSIX, so I specifically did not recommend its use.

Th specific part that I understood as your argument for non-POSIX solutions: "'for x in $y; do printf "$a%s$b" "$x"; done' is equivalent to 'printf "$a%s$b" $y' (assuming neither a nor b contain format specifiers). similarly, 'for i in {1..100}; do printf "$a"; done' is equivalent to 'printf "$a%s.0" {1..100}'. unfortunately, brace expansion is not POSIX, but these are both significantly more efficient (both in code…

'for x in $y; do printf "$a%s$b" "$x"; done' is used in the code already. I am proposing that it be changed to 'printf "$a%s$b" $y', which is also POSIX compliant, shorter (even including a comment), and faster. I included the part about brace expansion as a side note, not proposing that it be used.

Re: Shit – An implementation of Git using POSIX shell

#228

Post by Nullabillity »

jasode wrote: post #161
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…

>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. Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git commands (the "porcelain"). Yes, I know that git is a DAG (Directed Acyclic Gr…

> In databases & SQL, I can "INSERT INTO x" without learning the "internals" of b-trees[2].

True, but it is very helpful when designing your indexes.

Re: Shit – An implementation of Git using POSIX shell

#229

Post by amenod »

Ace17 wrote: post #222
wyclif wrote: post #220

Earlier quoted context omitted.

Almost everybody I've ever worked with who complained about Git has a conversation with a coworker that goes something like this: Coworker: "I really hate Git, it's so hard to understand what's going on internally." Git guy: "Did you read the documentation?" Coworker: "Nope." Git guy: "Did you read Git - book?" Coworker: "Nope." Git guy: "Did you read Scott Chacon's 'Pro Git'?" Coworker: "Nope." Git guy: "..."

The likelihood for this conversation to occur, in a way, also depends on the tool itself, and tells us something about it. As a matter of fact, git is hard to use. The question is: keeping the same level of functionality, could it have been made easy to use?

And the answer is: yes, absolutely. Mercurial is a whole level better. Unfortunately git won - because of GitHub, not on technical merit.

Re: Shit – An implementation of Git using POSIX shell

#230

Post by acqq »

Hello71 wrote: post #227
acqq wrote: post #216

Earlier quoted context omitted.

Th specific part that I understood as your argument for non-POSIX solutions: "'for x in $y; do printf "$a%s$b" "$x"; done' is equivalent to 'printf "$a%s$b" $y' (assuming neither a nor b contain format specifiers). similarly, 'for i in {1..100}; do printf "$a"; done' is equivalent to 'printf "$a%s.0" {1..100}'. unfortunately, brace expansion is not POSIX, but these are both significantly more efficient (both in code…

'for x in $y; do printf "$a%s$b" "$x"; done' is used in the code already. I am proposing that it be changed to 'printf "$a%s$b" $y', which is also POSIX compliant, shorter (even including a comment), and faster. I included the part about brace expansion as a side note, not proposing that it be used.

> 'printf "$a%s$b" $y', which is also POSIX compliant, shorter

Yes, indeed, thanks for pointing that, it's documented:

"The format operand shall be reused as often as necessary to satisfy the argument operands."

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/p...

Post reply on HN