Aya: A minimalist version control system with fewer than 6 commands
github.com
github.com
> > ! [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…
“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.
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.
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.
It is human to make mistakes and we usually change priorities.
Software that relies on simple building structures but can provide various functionality to give options and ways to revert mistakes are the best. Git is one of them.
This seems rather alpha.
Also, versioning with only numbers and dots seems a little basic or prescriptive to me, at least comparability with semver would make a little more sense to me.