-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Set initial-branch (#427) #465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@ericsciple: is there something I need to do to get this considered? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer a shorter name, and I would have much preferred a proper analysis why this change is safe (instead, I was forced to perform that analysis myself, from scratch, and I imagine that this is the problem that prevents the team from merging this PR: it just asks for too much effort on the reviewers' side).
Having said that, I would not mind this PR being merged as-is, I would merely prefer above-mentioned issues to be addressed.
@hross what do I need to do to move this forward? |
@ericsciple @TingluoHuang ping? |
@vanZeben is there something that can be done to move this along? |
Looks like this stalled. Are there other suggestions on silencing this warning? It shows up quite a few times. |
@kbrock: I can rebase and you can use my fork that has the fix. Otherwise, you could technically create an action / wrapper /step that does:
|
My opinions on this:
And remember that just like @dscho I'm not a maintainer (and not even a contributor), just a developer very interested in this PR going forward and eventually being accepted. It's been more than an year guys! (PS: @jsoref , you might mark your conversation with @dscho as resolved, it would be one less red status on the pending items summary, this might incentivize a reviewer . And maybe ping an actual (human) maintainer/reviewer, as that |
I'm happy to pick any name that a codeowner suggests. Personally I use Anyway, I'm more than happy to update this (or any of my other PRs) although I'm about to be relatively unavailable for a bit. |
I suggest you preemptively change the branch name now to something shorter, such as your |
Git now includes this at the end of the message:
It seems that setting that config value would accomplish suppressing the message in the most direct way. |
No. https://github.com/git/git/blame/v2.50.0/t/t0001-init.sh#L833-L837 requires v2.50.0 and many runners don't have that. Debian 12.8 has |
Again, it's really pointless for me to do anything to a PR to any github owned repo until a GitHub staffer shows up and says "hey, I'm willing to talk to you about this." This repository appears to be mostly abandoned. @TingluoHuang is welcome to prove me wrong. |
@jsoref the config value can be set regardless of whether the installed version supports it or not. It would then help with newer versions going forward. I suggested this as an alternative that would not require any bikeshedding over the default branch name. |
That's totally useless. And there's no point in bikeshedding. This PR works for any version of git that has the warning. It's only useful to bikeshed if there's a living maintainer. And there aren't. root@0db61f84061c:/tmp/tmp.1sO90FTg4c# git version
git version 2.39.5
root@0db61f84061c:/tmp/tmp.1sO90FTg4c# git -c advice.defaultBranchName=false init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /tmp/tmp.1sO90FTg4c/.git/ |
@jsoref using an absurdly long branch name can run into "long path" problems on Windows, especially with recursive clones. If I were a maintainer and saw the resistance against implementing obvious improvements, even if I had the time to engage I probably wouldn't unless someone forced me to. |
What resistance? Most (if not all) comments approved the PR. Any maintainer can just ignore the bikeshedding about the branch name, as many (including myself and the author) said any name is fine and should not be a blocker. |
Well, I have told you that this long name is a blocker, as it can cause issues with long paths on Windows when cloning recursively. And as I have said before, if I were a maintainer, I wouldn't appreciate it if any contributor simply tried to ignore away a valid concern like this. |
Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>
Fixes #427
Suppress noise about that git itself is changing its default branch. When
actions/checkout
is used, it will always be given a specific branch (or similar) to check things out, and thus the default branch is not used...Run actions/checkout@v2.0.0
See #465 (comment) for a proof.