[RESEND] "EasyLogin": Simplifying Account Configuration for Git Users

[amirali-dashti]

Resend this message so to include the commit's sign

Greetings to the Git and GitGitGadget community!

I’m excited to present an idea that aims to streamline the login and account configuration process within Git. While this is not a complete pull request, it serves as a proposal for introducing a new feature: the easylogin command.

This feature introduces a simple way for users to configure their Git accounts. The core of this idea is encapsulated in a bash script, currently located at:
Documentation/config/easylogin

The command structure for easylogin is straightforward:

git easylogin <username> <email>

By executing this command, users can effortlessly update their account's username and email settings without navigating through more complex configuration steps.

I’d love to hear the community’s thoughts on this concept. Does this approach align with Git’s design philosophy? Are there potential improvements or alternative implementations you’d suggest?

Your feedback is invaluable and will guide the development of this idea into a fully functional feature. Thank you for your time and consideration!

Best regards!

cc: devtracer devoft1@gmail.com

[gitgitgadget-git]

Welcome to GitGitGadget

Hi @devtracer, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that either:

• Your Pull Request has a good description, if it consists of multiple commits, as it will be used as cover letter.
• Your Pull Request description is empty, if it consists of a single commit, as the commit message should be descriptive enough by itself.

You can CC potential reviewers by adding a footer to the PR description with the following syntax:

CC: Revi Ewer <revi.ewer@example.com>, Ill Takalook <ill.takalook@example.net>

NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description,
because it will result in a malformed CC list on the mailing list. See
example.

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

• the lines should not exceed 76 columns,
• the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
• the commit messages' body should be describing the "why?" of the change.
• Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

• Search: is:pr is:open "/allow"

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the Libera Chat IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this. Note that any reviewers CC'd via the list in the PR description will not actually be sent emails.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

[gitgitgadget-git]

There are issues in commit 163e937:
new file: Documentation/config/easylogin
Commit checks stopped - the message is too short
Commit not signed off

[amirali-dashti]

There are issues in commit 163e937:
new file: Documentation/config/easylogin

This is the easylogin code I’m proposing. Could you provide more specific feedback on what issues you’ve identified?

Commit checks stopped - the message is too short

I believe the commit message length is reasonable, but if additional details are needed, please let me know so I can expand it appropriately.

Commit not signed off

I added a cc at the end, but it seems this might not align with the required syntax. Could you guide me on how to include the correct sign-off? I’d appreciate a brief example or reference to the proper format.

[dscho]

It's not a good idea to open and close and open and close and open PRs (three in total) for the very same idea. Just force-push and re-use the original PR.

Also, you may want to use a different branch name in your fork, but it's now too late to change that unless you plan on closing this PR and open a fourth PR.

Could you provide more specific feedback on what issues you’ve identified?

You are quoting the more specific feedback below your question.

Commit checks stopped - the message is too short

I believe the commit message length is reasonable, but if additional details are needed, please let me know so I can expand it appropriately.

You will probably stop believing that this commit message length is reasonable after looking at other commits in the commit history that look nowhere near as terse.

Following the guidance in https://github.blog/2022-06-30-write-better-commits-build-better-projects/ will almost definitely improve it, in particular with a strong focus on this part:

	What you’re doing	Why you’re doing it
High-level (strategic)	Intent (what does this accomplish?)	Context (why does the code do what it does now?)
Low-level (tactical)	Implementation (what did you do to accomplish your goal?)	Justification (why is this change being made?)

Commit not signed off

I added a cc at the end, but it seems this might not align with the required syntax.

Indeed. There is even documentation specifically about the format how you sign off on patches, and a rationale why you do it: https://git-scm.com/docs/SubmittingPatches#sign-off.

In addition to all of that, when you carefully look at the already existing files in Documentation/config/, you will notice that none of them are Bash scripts. In fact, they are all AsciiDoc-formatted snippets that are intended to be included in the git-config manual page, and all of those files contain descriptions of config settings that are in the section to which the file name corresponds. There are most likely much, much more appropriate locations where to add your Bash.

And lastly, how is this Bash script a documentation for some existing Git functionality? It is not! A wiser idea, then, would be to take a step back, reflect, realize that this is not patch material at all, and instead send a regular mail describing your idea to the Git mailing list. See https://git-scm.com/community for more details.

[dscho]

@devtracer are you actually interested in contributing to the Git project? I spent a substantial amount of time providing feedback to help you on the way, but you have not responded and I am getting the impression that my time was wasted.

[amirali-dashti]

@devtracer are you actually interested in contributing to the Git project? I spent a substantial amount of time providing feedback to help you on the way, but you have not responded and I am getting the impression that my time was wasted.

Dear @dscho ,

I sincerely apologize for the delay in my response. I greatly appreciate the time and effort you dedicated to providing feedback to assist me. Please know that your insights were not taken for granted, and I deeply regret any impression to the contrary.

I had intended to send a thoughtful reply expressing my gratitude for your support, but unfortunately, university commitments caused an unexpected delay. I also hesitated as I wondered whether continuing the discussion via email might be preferable to you.

That said, I am still very much interested in contributing to the Git project and building on our discussion. My idea is to develop a TUI-based Git account manager aimed at simplifying account management for users. I am excited about this prospect and would value your continued guidance if you’re willing to provide it.

Thank you again for your patience and understanding. I look forward to hearing your thoughts.

Best regards,
@devtracer

[amirali-dashti]

Greetings, @dscho,

I hope this message finds you well. I am writing in response to your previous message to address the valuable feedback you provided and to share my thoughts on the points you raised.

It's not a good idea to open and close and open and close and open PRs (three in total) for the very same idea. Just force-push and re-use the original PR.

Also, you may want to use a different branch name in your fork, but it's now too late to change that unless you plan on closing this PR and open a fourth PR.

I appreciate your feedback. This was my very first contribution, and I am still a beginner, but I will take this as a learning opportunity and improve in the future.

You are quoting the more specific feedback below your question.

Understood, I will follow this approach moving forward.

You will probably stop believing that this commit message length is reasonable after looking at other commits in the commit history that look nowhere near as terse.

Following the guidance in https://github.blog/2022-06-30-write-better-commits-build-better-projects/ will almost definitely improve it, in particular with a strong focus on this part:

	What you’re doing	Why you’re doing it
High-level (strategic)	Intent (what does this accomplish?)	Context (why does the code do what it does now?)
Low-level (tactical)	Implementation (what did you do to accomplish your goal?)	Justification (why is this change being made?)

Oh, I see now! I mistakenly thought a brief explanation would suffice. I now understand the importance of providing more detailed explanations for my project and will strive to improve my commit messages accordingly.

Indeed. There is even documentation specifically about the format how you sign off on patches, and a rationale why you do it: https://git-scm.com/docs/SubmittingPatches#sign-off.

Thank you for clarifying! I will make sure to follow the proper method from now on.

In addition to all of that, when you carefully look at the already existing files in Documentation/config/, you will notice that none of them are Bash scripts. In fact, they are all AsciiDoc-formatted snippets that are intended to be included in the git-config manual page, and all of those files contain descriptions of config settings that are in the section to which the file name corresponds. There are most likely much, much more appropriate locations where to add your Bash.

My intention was to share the script with the development team and allow them to decide the most suitable location for it. However, I see your point and will reevaluate this approach.

And lastly, how is this Bash script a documentation for some existing Git functionality? It is not! A wiser idea, then, would be to take a step back, reflect, realize that this is not patch material at all, and instead send a regular mail describing your idea to the Git mailing list. See https://git-scm.com/community for more details.

I understand now! I will revisit the guidelines and, as mentioned in my previous reply, work on refining my idea to make it a wiser idea and more valuable. I’ll also explore the mailing list as suggested to better communicate my thoughts.

Finally, I want to sincerely thank you for the time and effort you’ve put into providing me with such thorough and constructive feedback. Your insights have been incredibly valuable, and I hope to use this knowledge to grow and contribute meaningfully to the Git project. I truly appreciate the opportunity to learn from an experienced developer like you and look forward to staying in touch with the Git team.

Best regards,
@devtracer

[amirali-dashti]

Upon reviewing the source code of the Git project, I found that it is written in C. Therefore, I will utilize C and its TUI to develop the account manager. Additionally, I plan to create a folder within the backend code to include this account manager. What are your thoughts on this approach? Does it seem appropriate?

[dscho]

@devtracer it might make sense to first send an email to the Git mailing list stating your intent. There may already be something like that out there, and you may also face some push-back against integrating this into Git proper. In both cases, I would like to prevent you from spending too much time on it before learning about such obstacles.

[amirali-dashti]

@devtracer it might make sense to first send an email to the Git mailing list stating your intent. There may already be something like that out there, and you may also face some push-back against integrating this into Git proper. In both cases, I would like to prevent you from spending too much time on it before learning about such obstacles.

@dscho Ok, I see. Thanks for pointing that out! I searched through the link you provided in the previous message and found this

git-mentoring@googlegroups.com

This mailing list is targeted to new contributors and was created as a place to post questions and receive answers outside of the public eye of the main list. Veteran contributors who are especially interested in helping mentor newcomers are present on the list. In order to avoid search indexers, group membership is required to view messages; anyone can join and no approval is required.

Should I send an email to git-mentoring@googlegroups.com, or would git@vger.kernel.org be more appropriate for this?

[dscho]

@devtracer git-mentoring seems to be all but dead. So I would recommend sending to git@vger.kernel.org (and be prepared to ping in weekly cadences if nobody replies, which happens quite frequently for such emails).

[amirali-dashti]

@devtracer git-mentoring seems to be all but dead. So I would recommend sending to git@vger.kernel.org (and be prepared to ping in weekly cadences if nobody replies, which happens quite frequently for such emails).

@dscho Thank you for your recommendations and assistance. I truly appreciate it and am very grateful for your support in helping others. I will share the results with you through this thread.

Best wishes,
@devtracer