bug

bug

[Luke Knoble]

Howdy,

I've found an issue in which I'm using this command:

git clone --recurse-submodules ssh://git@someurl:9999/someproject/repoX.git

git clones the repo successfully if I dont pass “git clone” any flags,
but gives me this error when I use “--recurse-submodules” and git
attempts to clone a single submodule:

git@someurl: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
fatal: clone of
'ssh://git@someurl:9999/someproject/submodule_repo.git' into submodule
path 'C:/someproject/submodule_repo' failed

The obvious answer is that my permissions are bad, but I can clone the
submodule repo directly without issue.. This command succeeds:

git clone --recurse-submodules
ssh://git@someurl:9999/someproject/submodule_repo.git

what gives git?

Re: [BUG] SSH permission error doing `git clone --recurse-submodules <SSH url>` (was: "bug")

[Philippe Blain]

Hi Luke,

> Le 26 juin 2020 à 17:11, Luke Knoble <lupeknoble@gmail.com> a écrit :
> 
> Howdy,
> 
> I've found an issue in which I'm using this command:
> 
> git clone --recurse-submodules ssh://git@someurl:9999/someproject/repoX.git

Which version of Git ?

> 
> git clones the repo successfully if I dont pass “git clone” any flags,

Does `git submodules update --init` then works ?
Can you share `.gitmodules` ? (is the submodules recorded with an HTTP
or SSH url in `.gitmodules` ?)

> but gives me this error when I use “--recurse-submodules” and git
> attempts to clone a single submodule:
> 
> git@someurl: Permission denied (publickey).
> fatal: Could not read from remote repository.
> Please make sure you have the correct access rights
> and the repository exists.
> fatal: clone of
> 'ssh://git@someurl:9999/someproject/submodule_repo.git' into submodule
> path 'C:/someproject/submodule_repo' failed
> 
> The obvious answer is that my permissions are bad, but I can clone the
> submodule repo directly without issue.. This command succeeds:
> 
> git clone --recurse-submodules
> ssh://git@someurl:9999/someproject/submodule_repo.git

Interesting. Could you retry your commands, prefixing them with `GIT_TRACE2=1 GIT_SSH_COMMAND="ssh -vvv"` ?

Philippe.

BUG

[Alex Marginean]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

Hey,

Github has changed the way they name branches, so now instead of the
`master` branch there is the `main` branch however, I'm having some
trouble with the naming

**Steps to replicate my problem**

1. Create a new Github repository and make sure the default branch is `main`
2. Add something to the repo, a `README.md` file should be enough
3. Instead of cloning the repo make a new directory with your repo's
name `mkdir <repo_name>` and change the directory to it `cd
<repo_name>`
4. `git init`
5. Add the remote repo with `git remote add origin <repo_link>`
6. Pull the `main` branch from the remote repo with `git pull origin main`.

After the step number 6. instead of my branch changing to `main` my
current branch is changed to `master` which has every file and change
of the branch `main`. This is a real problem because if I try to push
changes to `main` although my current branch shows up as `master` it
creates another branch called `master` on Github and the `main`
remains unchanged. Yeah sure I can `git checkout main` after that and
make my changes there but I'm not sure why it defaults to `master` and
copies `main` from Github into local branch `master`.

P.S. If you were to use `git fetch origin` instead of `git pull origin
<branch_name> and then manually change branch to `main` with `git
checkout main` it would work. Also, if you were to clone the Github
repo using `git clone <link>` you will get the correct current branch
that is `main`.

Sincerely,
Alex

[-- Attachment #2: git-bugreport-2020-11-04-1731.txt --]
[-- Type: text/plain, Size: 2639 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

Github has changed the way they name branches, so now instead of the `master` branch there is the `main` branch however, I'm having some trouble with the naming

1. Create a new Github repository and make sure the default branch is `main`
2. Add something to the repo, a `README.md` file should be enough
3. Instead of cloning the repo make a new directory with your repo's name `mkdir <repo_name>` and change the directory to it `cd <repo_name>`
4. `git init`
5. Add the remote repo with `git remote add origin <repo_link>`
6. Pull the `main` branch from the remote repo with `git pull origin main`.

What did you expect to happen? (Expected behavior)

After step 6. I expected to be switched to a branch called `main` that would include every file and change from the `main` branch on the origin. 

What happened instead? (Actual behavior)

After the step number 6. instead of my branch changing to `main` my current branch is changed to `master` which has every file and change of the branch `main`. This is a real problem because if I try to push changes to `main` although my current branch shows up as `master` it creates another branch called `master` on Github and the `main` remains unchanged. Yeah sure I can `git checkout main` after that and make my changes there but I'm not sure why it defaults to `master` and copies `main` from Github into local branch `master`.

What's different between what you expected and what actually happened?

The name of the branch and the duplication of the `main` branch to a branch called `master`.

Anything else you want to add:

P.S. If you were to use `git fetch origin` instead of `git pull origin <branch_name> and then manually change branch to `main` with `git checkout main` it would work. Also, if you were to clone the Github repo using `git clone <link>` you will get the correct current branch that is `main`.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.29.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.0 (clang-1200.0.32.21)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh


[Enabled Hooks]
not run from a git repository - no hooks to show

RE: BUG

[Randall S. Becker]

On November 4, 2020 11:10 AM, Alex Marginean wrote:
> Github has changed the way they name branches, so now instead of the
> `master` branch there is the `main` branch however, I'm having some trouble
> with the naming
> 
> **Steps to replicate my problem**
> 
> 1. Create a new Github repository and make sure the default branch is `main`
> 2. Add something to the repo, a `README.md` file should be enough 3.
> Instead of cloning the repo make a new directory with your repo's name
> `mkdir <repo_name>` and change the directory to it `cd <repo_name>` 4. `git
> init` 5. Add the remote repo with `git remote add origin <repo_link>` 6. Pull
> the `main` branch from the remote repo with `git pull origin main`.

Use git init --initial-branch=main

This assumes a recent version of git.

> 
> After the step number 6. instead of my branch changing to `main` my current
> branch is changed to `master` which has every file and change of the branch
> `main`. This is a real problem because if I try to push changes to `main`
> although my current branch shows up as `master` it creates another branch
> called `master` on Github and the `main` remains unchanged. Yeah sure I can
> `git checkout main` after that and make my changes there but I'm not sure
> why it defaults to `master` and copies `main` from Github into local branch
> `master`.
> 
> P.S. If you were to use `git fetch origin` instead of `git pull origin
> <branch_name> and then manually change branch to `main` with `git
> checkout main` it would work. Also, if you were to clone the Github repo
> using `git clone <link>` you will get the correct current branch that is `main`.

Regards,
Randall
-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: BUG

[Randall S. Becker]

On November 4, 2020 12:03 PM, I wrote:
> To: 'Alex Marginean' <alexmarginean16@gmail.com>; 'git@vger.kernel.org'
> <git@vger.kernel.org>
> Subject: RE: BUG
> 
> On November 4, 2020 11:10 AM, Alex Marginean wrote:
> > Github has changed the way they name branches, so now instead of the
> > `master` branch there is the `main` branch however, I'm having some
> > trouble with the naming
> >
> > **Steps to replicate my problem**
> >
> > 1. Create a new Github repository and make sure the default branch is
> > `main` 2. Add something to the repo, a `README.md` file should be enough
> 3.
> > Instead of cloning the repo make a new directory with your repo's name
> > `mkdir <repo_name>` and change the directory to it `cd <repo_name>` 4.
> > `git init` 5. Add the remote repo with `git remote add origin
> > <repo_link>` 6. Pull the `main` branch from the remote repo with `git pull
> origin main`.
> 
> Use git init --initial-branch=main

You could also use git branch -m master main after the git init if your version of git is too old.

> 
> This assumes a recent version of git.
> 
> >
> > After the step number 6. instead of my branch changing to `main` my
> > current branch is changed to `master` which has every file and change
> > of the branch `main`. This is a real problem because if I try to push
> > changes to `main` although my current branch shows up as `master` it
> > creates another branch called `master` on Github and the `main`
> > remains unchanged. Yeah sure I can `git checkout main` after that and
> > make my changes there but I'm not sure why it defaults to `master` and
> > copies `main` from Github into local branch `master`.
> >
> > P.S. If you were to use `git fetch origin` instead of `git pull origin
> > <branch_name> and then manually change branch to `main` with `git
> > checkout main` it would work. Also, if you were to clone the Github
> > repo using `git clone <link>` you will get the correct current branch that is
> `main`.
> 
> Regards,
> Randall
> -- Brief whoami:
>  NonStop developer since approximately 211288444200000000  UNIX
> developer since approximately 421664400
> -- In my real life, I talk too much.

Bug

[Mike Hawes]

To whom this may concern,

I found a bug in git while trying to push my website.

I redid the process and it happened again.

I also tried it on another computer and it happened again.

I was wondering how to claim a bug?

Thank you,


Michael Hawes

Re: Bug

[Santiago Torres]

Hi, Michael.

It would be helpful to get more context on what triggered this bug. I'm
not a 'core' dev, so there may be a better way to send this. In general,
you want to state the following:

0) Information about your git installation, host system, etc.
1) Information about your repo (was it GitHub? local? self-hosted?)
2) What did you do? (git push origin master? git push?)
3) What happened instead of working? (the error message would be
   helpful.

Hope this helps.

Cheers!
-Santiago.

On Tue, Sep 13, 2016 at 01:18:52PM -0400, Mike Hawes wrote:
> To whom this may concern,
> 
> I found a bug in git while trying to push my website.
> 
> I redid the process and it happened again.
> 
> I also tried it on another computer and it happened again.
> 
> I was wondering how to claim a bug?
> 
> Thank you,
> 
> 
> Michael Hawes

Re: Bug

[Dennis Kaarsemaker]

On Tue, 2016-09-13 at 13:18 -0400, Mike Hawes wrote:
> To whom this may concern,
>
> I found a bug in git while trying to push my website.
> I redid the process and it happened again.
> I also tried it on another computer and it happened again.
> I was wondering how to claim a bug?

Hi Mike,

When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work".  "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken".  It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.

Please remember to always state

 - what you wanted to achieve;

 - what you did (the version of git and the command sequence to reproduce
   the behavior);

 - what you saw happen (X above);

 - what you expected to see (Y above); and

 - how the last two are different.

See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.

(The above was shamelessly copied from the "A note from the maintainer" mails)

D.