3 ms·
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 comman
by 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 agoIts 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.