+ git switch is documented as "EXPERIMENTAL"
+ git --help lists git switch but not git checkout as an important command
This is a documentation inconsistency. It can't be both the canonical interface to use and experimental at the same time.
When you checkout a specific commit and are now in detached HEAD state, you are by default given the message
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -A much better response would be, "Thanks for pointing that out! I have filed an issue." One can't simultaneously through shade for not being community-spirited while expecting other people to do all the work.
In any case, the suggestion of submitting a patch when you notice a problem doesn’t deserve downvotes. That’s not throwing shade, at all.
If you do that work, I'm glad to try to help you see where their approach falls short in terms of sincerely encouraging contribution.
I'm not being coy, as if I really know what you think, but I'm asking anyway just to be frustrating. I mean, I have an idea, but I also didn't want to make assumptions about your intent, when it's just as easy to ask you to elaborate. After all, it's your point that it was incorrect, so I just wanted to know why.
Any way, you said there are "legitimate ways to suggest submitting a patch, but this isn't one" (I'm paraphrasing). To me that didn't really make sense, because that implies one of the wrong ways to suggest submitting a patch is to suggest submitting a patch.
> If that's really the case, then take a little time and explain exactly what impact you think that comment would have had on the person they were replying to
In my mind, it seems like the effect that it would have on them is to suggest to them to submit a patch. Alternatively, it might also have no effect, because they might not care enough to do anything about it, or just be busy, which is also ok. They don't have to listen to any advice, and it was given in good faith, without malice.
I can also imagine a situation where it is technically possible for someone to attribute all sort of weird malice to "so submit a patch" that wasn't actually there. After all, people can feel however they want. However, in my opinion it's quite rude to assume about someone without knowing them that they're such a fragile creature as to invent malcontent where there is, in my eyes, obviously none.
So going back to when I said "I have an idea", I meant that yeah I can imagine, after this back and fourth, that maybe you would assume something like this about someone else - that they can't hear "so submit a patch" without taking it en every wrong way possible - but I didn't want to make that assumption without at least giving you the opportunity to explain yourself.
Ok, on to exploring other ways to encourage them to submit a patch. You could say, "Do you know you can submit a patch?", "Feel free to submit a patch", "This looks like a documentation bug, would you submit a patch?". All of these also seem fine to me.
> If you do that work, I'm glad to try to help you see where their approach falls short in terms of sincerely encouraging contribution.
What I don't like about this, personally, is that you're convinced their suggestion wasn't sincere, as if there has to be an ulterior motive. As if believing that a programmer on a startup forum is capable of fixing a documentation bug is so crazy, there can be no other explanation than really they were trying to humiliate the other person.
Any way, I do believe that you're trying to be helpful and it's not really that big of a deal so no worries. Hope you can believe me when I say I'm being sincere as well. Basically, a lot of people have different ways of encouraging each other, and there are a lot of different styles of encouragement that people appreciate. It doesn't mean that one you don't agree with is wrong. When I read "so submit a patch", my mind didn't immediately go negative, and I hope the recipient of that didn't either.
If I wanted to actually invite somebody to contribute to an open-source project, I'd start with positive reinforcement. "Great point! That's definitely an issue with the docs." I'd then first tell them how to let the right people know about the problem. "You can file an issue here Be sure to categorize it as X, mentioning Y, and Z." Then I would explain that if they wanted to get involved in the project, they could try submitting a patch, giving them at least a few sentences of instruction on what files to look at, where to find the contributor guidelines, etc. In sum, if I'm asking somebody to do work, I'd encourage them and do a little work myself to show that I'm trying to support them.
And it's not just me. The "submit a patch" bit is a cliche bit of jerkiness, so much so that there are whole discussions of it. For example this: https://softwareengineering.stackexchange.com/questions/6874...
And this: https://softwareengineering.stackexchange.com/questions/8323...
And it's a long-standing problem in open source. This, for example, is more than 10 years old: https://xenoterracide.com/post/dont-say-patches-welcome/
So if that reply truly seems fine to you, please understand that if it ever was, it has been ruined by a long history of people acting like that to be dismissive or jerky. That rudeness is something I can almost excuse in someone actually working on an open-source project, as they can get a raw deal. But I think there's no place at all for it in a forum like this.
This means, here's my problem, someone else fix it for me. Since it has not been fixed for YEARS, maybe not the best alternative if you want to get it fixed.
The Git project has no issue tracker though.