[pcr910303]

> In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use.

IMHO progressive disclosure is important, because if you want something to be widespread, beginners should be able to use SourceHut with little guidance.

> I don't believe that users are not capable of learning new things.

Well, for the users to learn git terminology, one has to start using git — and one of the biggest reasons is to start using git is to clone popular projects or cooperating between different people. If SourceHut is hostile (I’m not saying that it’s currently hostile, but I think it may improve) for people who don’t what a ‘ref’ is, people have to start using GitHub — and the newcomers of SourceHut becomes the very small portion of people who are already an ‘git expert’ and is interested in emailing patches.

If SourceHut wants to make the email patches/other workflows that SourceHut encourages mainstream, I think it’s crucial for git newcomers to be able to use it. It’s a losing game otherwise.

[ddevault]

But your suggestion relies on them knowing what "branches" are - an equally tenuous proposition for a new programmer, I think. Recall that at one point, you didn't know how to use GitHub, either. Pull requests? Cloning? What do these words mean, out of context? New users on GitHub struggle a lot, too, something I know from firsthand experience dealing with new programmers on my GitHub projects all the time.

I would prefer to solve these problems by fostering a culture of mentorship, and being responsive to questions. This is what I do on GitHub, too.

[mikekchar]

Just to support your philosophy a little bit, most git users are very surprised to learn that a "branch" is a single commit. When they need to do something where this distinction matters, in my experience they are usually stymied. Using a precise model where it doesn't sweep the details under the carpet is good for me. However, I suspect that it will limit adoption to a certain extent. Pretending that something is the way you wish it to be is pretty common in the world ;-) Refusing to use tools that show you truths that you do not wish to acknowledge is similarly common, I think. Still I appreciate the precision and if you are targeting users like me, I certainly won't complain!

[umvi]

A branch is more accurately a text pointer pointing to a single commit

[TeMPOraL]

And this is a crucial point. To understand git, you need to understand data structures strung from pointers. Branch then being a [pointer to a] single commit makes perfect sense, just like a linked list being a pointer to the first element makes perfect sense.

[rswail]

You could even call it a "reference", or a "ref" for short :)

[pcr910303]

I agree with that PRs are a foreign concept — but branchs and cloning is text that almost always appear on introductory git tutorials which make them friendlier than the other terms.

I actually just realized that if SourceHut has a site (like git-send-email.io) that explains git that uses the terms ‘ref’ and etc... (so that a git newcomer can build a proper fit mental model), this problem goes away. Not sure if explaining it easily would be possible though.

[mb7733]

I agree with all of this and it's worth pointing out that unlike "ref" which some posters are claiming is too obscure, "pull request" is not even a term within git itself.

As someone who was quite familiar with git before using GitHub, GH's use of that term was the only confusing thing. (It is only not a request for others to `pull` your branch to inspect the changes, it's also a request to merge it into some other branch.)

A term like "ref" is at least part of the standard git terminology, and used in important commands that everyone should know like "reflog".

[toohotatopic]

Thank you for that attitude.