Comment by jeffhuys | Hacker News Reader

Comment by jeffhuys | Hacker News Reader

> Here's an example of a confusing error in Git that you won't encounter in Aya:

> > ! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://github.com/Mohamedjcali/aya'

> > hint: Updates were rejected because the remote contains work that you do not

> > hint: have locally. This is usually caused by another repository pushing to > > hint: the same ref. If you want to integrate the remote changes, use

> > hint: 'git pull' before pushing again.

> > hint: See the 'Note about fast-forwards' in 'git push --help' for details.

1. So you don’t see it in Aya, why? Because it just doesn’t check, or because there’s a more sophisticated way to fix discrepancies like this in large codebases?

2. I really don’t understand how this error can be confusing. The only times I’ve seen someone be confused by this is because they didn’t actually read the error, but got an unexpected message and immediately gets their senior (me) to read it for them…

I don’t think it is confusing, but I think it could be a lot better.

“This is usually caused by another repository pushing to the same ref”: I think the command could check what happened on the remote, and mention something like

“After you got the version you worked on from the server, John and Mary made 8 changes to it. You’ll have to make sure your changes work with theirs by getting those changes”

, with a fallback to a more generic message if the command couldn’t determine with certainty that that is what happened, but that will be rare. The command could also detect when you’re trying to overwrite your own changes and suggest “git push —force-with-lease” (is there even a third option as to why you’d get this message?)

“See the 'Note about fast-forwards' in 'git push --help' for details.”: why is there still no easier way to look up that info than via a command _and_ a search? For example “git push —-help-fast-forwards”?

If it’s a single command, users cloud select and execute it and read the relevant help section.

Now, they have to do “git push —help”, likely (depending on how their shell is set up) losing sight of the ”See the 'Note about fast-forwards'” phrase, so they’ll have to remember what to search for.

> Now, they have to do “git push —help”, likely (depending on how their shell is set up) losing sight of the ”See the 'Note about fast-forwards'” phrase, so they’ll have to remember what to search for.

I am not sure we should be worrying too much about developers who forget 2 words in the span of a few seconds. In fact this whole comment reads like we should change Git to cater to the some of the worst theoretical developers I've ever heard of.

Its not an enormous annoyance, but every little thing helps.

The way I see it, when developers do a git push, they often are in a flow where they have a few more steps to do in their head. Things like messaging a coworker about the push, starting a build or checking out whether the commit worked in their continuous integration system, deploying stuff, using the new code in a different project, etc.

In my view, (almost) everything we can do to make such unexpected interruptions go smoother is worth the effort.

We need something better than git

Why?

Because it was designed by Linus to solve his problems, not ours.

It seems to solve the problems of developers all around the world. Could you try to be more specific in why you think it doesn't solve others' problems?

Too many foot guns.

Such as?

https://www.youtube.com/watch?v=CDeG4S-mJts&pp=ygUQSGl0bGVyI...

nah, you just need to use trunk based development.

Only the enlightened sage can see this

I think there are valid complaints about the number of git commands / flags and the quality of the docs not helping users understand them, but in my experience _most_ developers who complain about git both have never used any other VCS (including other DVCS systems) and have no mental model for what git does at all. The latter is usually the bigger problem, because it’s just not that complicated, but it prevents devs from either working things out on their own or asking a reasonable question. I agree with the parent post here - there’s nothing confusing about the error message presented as an example of “why git is bad” here.

Reply on news.ycombinator.com