3 ms·

> 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

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

arresin 2y ago
We need something better than git
- pawelduda 2y ago
  Why?
  - keithalewis 2y ago
    Because it was designed by Linus to solve his problems, not ours.
    - squigz 2y ago
      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?
      - keithalewis 2y ago
        Too many foot guns.
        squigz 2y ago
        Such as?
        keithalewis 2y ago
        https://www.youtube.com/watch?v=CDeG4S-mJts&pp=ygUQSGl0bGVyIGhhdGVzIGdpdA%3D%3D#bottom-sheet https://www.youtube.com/watch?v=CDeG4S-mJts&pp=ygUQSGl0bGVyI...
- gonzo41 2y ago
  nah, you just need to use trunk based development.
  - moonlion_eth 2y ago
    Only the enlightened sage can see this
- 010101010101 2y ago
  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.
Someone 2y ago
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.
- squigz 2y ago
  > 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.
  - Someone 2y ago
    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.

arresin 2y ago

We need something better than git

pawelduda 2y ago
Why?
- keithalewis 2y ago
  Because it was designed by Linus to solve his problems, not ours.
  - squigz 2y ago
    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?
    - keithalewis 2y ago
      Too many foot guns.
      - squigz 2y ago
        Such as?
        keithalewis 2y ago
        https://www.youtube.com/watch?v=CDeG4S-mJts&pp=ygUQSGl0bGVyIGhhdGVzIGdpdA%3D%3D#bottom-sheet https://www.youtube.com/watch?v=CDeG4S-mJts&pp=ygUQSGl0bGVyI...
gonzo41 2y ago
nah, you just need to use trunk based development.
- moonlion_eth 2y ago
  Only the enlightened sage can see this
010101010101 2y ago
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.

Someone 2y ago

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.

squigz 2y ago
> 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.
- Someone 2y ago
  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.