difficulty creating PR #377

New Issue

progman · 2021-07-07T08:02:21Z

progman commented

2021-07-07 08:02:21 +00:00

hi.

I have user X owning repo A and user Y owning
repo B. X and Y are both gitea created users.
the aim is for X to create a PR on B.
I do 'tea login add ..Y ...'
then I initiate the PR creation from a clone of A.
it succeeds but the PR is created against A/X!
to close this PR I have to do another 'tea login add' for X!

why is the PR created on the source repo and not the target repo?

hi. I have user X owning repo A and user Y owning repo B. X and Y are both gitea created users. the aim is for X to create a PR on B. I do 'tea login add ..Y ...' then I initiate the PR creation from a clone of A. it succeeds but the PR is created against A/X! to close this PR I have to do another 'tea login add' for X! why is the PR created on the source repo and not the target repo?

progman commented

2021-07-07 14:08:53 +00:00

I think I could really use an example of use.
From the tea homepage example for 'tea pulls ...'
I think now that the local repo in $PWD, --repo, --remote are ways to specify the repo to open the PR against.
but that leaves how to specify the source repo and branch to be merged.
so what's left? only these options!:

--head value                   Set head branch (default is current one)
--base value, -b value         Set base branch (default is default branch)

... no mention of the donor repo name!
... is 'base' referring to the target branch?
... is 'head' referring to the donor branch?

I think I could really use an example of use. From the tea homepage example for 'tea pulls ...' I think now that the local repo in $PWD, --repo, --remote are ways to specify the repo to open the PR against. but that leaves how to specify the source repo and branch to be merged. so what's left? only these options!: ``` --head value Set head branch (default is current one) --base value, -b value Set base branch (default is default branch) ``` ... no mention of the donor repo name! ... is 'base' referring to the target branch? ... is 'head' referring to the donor branch?

noerw commented

2021-07-08 07:55:55 +00:00

Hi, yeah the docs need some improvements (a PR for that would be very welcome :)

I think now that the local repo in $PWD, --repo, --remote are ways to specify the repo to open the PR against.

Right:

--repo is used to specify the repo you want to create the PR in. This is autoselected when you are in a local git dir, where the master branch has a gitea remote configured.
--remote is used to select another gitea repo based on a different remote in the local repo

why is the PR created on the source repo and not the target repo?

Because you cloned X's fork, so the remote of main/master branch points to the fork A, not source B. So (as described above for --repo), the fork is selected by tea. Two ways to fix this:

set the remote to upstream in your git repo:

git remote add upstream git@mygitea.com:Y/B
git branch --set-upstream-to=upstream master

set the right repo ad hoc. --head can be omitted, if you currently have that branch checked out.
```
tea pr create --repo Y/B --head X:mybranch
```

Setting main branch remote to the upstream repo as in (1) generally helps a lot with defaults in tea.

... is 'base' referring to the target branch?
... is 'head' referring to the donor branch?

Yes. Note a major omission from the docs:
If head branch comes from a different repo, you can specify that by prefixing the branch name with the username (--head X:mybranch)

To close this PR I have to do another 'tea login add' for X!

When you want to create a PR as X in user Y's repo, you should only need one login for X, no need for login Y.

Hi, yeah the docs need some improvements (a PR for that would be very welcome :) > I think now that the local repo in $PWD, --repo, --remote are ways to specify the repo to open the PR against. Right: - `--repo` is used to specify the repo you want to create the PR in. This is autoselected when you are in a local git dir, where the `master` branch has a gitea remote configured. - `--remote` is used to select another gitea repo based on a different remote in the local repo --- > why is the PR created on the source repo and not the target repo? Because you cloned X's fork, so the remote of `main`/`master` branch points to the fork A, not source B. So (as described above for `--repo`), the fork is selected by tea. Two ways to fix this: 1. set the remote to upstream in your git repo: ``` git remote add upstream git@mygitea.com:Y/B git branch --set-upstream-to=upstream master ``` 2. set the right repo ad hoc. `--head` can be omitted, if you currently have that branch checked out. ``` tea pr create --repo Y/B --head X:mybranch ``` Setting main branch remote to the upstream repo as in (1) generally helps a lot with defaults in tea. --- > ... is 'base' referring to the target branch? > ... is 'head' referring to the donor branch? Yes. Note a major omission from the docs: If head branch comes from a different repo, you can specify that by prefixing the branch name with the username (`--head X:mybranch`) --- > To close this PR I have to do another 'tea login add' for X! When you want to create a PR as X in user Y's repo, you should only need one login for X, no need for login Y.

noerw added the

kind/docs

kind

question

labels 2021-07-08 07:58:30 +00:00

progman commented

2021-07-08 13:03:36 +00:00

Hi,
thanks for the rapid response!

1. set the remote to upstream in your git repo:

   git remote add upstream git@mygitea.com:Y/B
   git branch --set-upstream-to=upstream master

If I do

git remote add upstream http://localhost:3000/Y/B
git branch --set-upstream-to=upstream master

I get

error: the requested upstream branch 'upstream' does not exist

I'm not intending to track an upstream branch with 'mybranch' - I do want 'mybranch' to fast-forward
master on Y/B.

2. set the right repo ad hoc. --head can be omitted, if you currently have that branch checked out.

tea pr create --repo Y/B --head X:mybranch

I get:

Local repository required: Execute from a repo dir, or specify a path with --repo.

..with my current directory the clone of the fork of the target repo and with 'mybranch' the current one.
I have tried --base Y:master and --base master also, with same result.

Hi, thanks for the rapid response! ``` 1. set the remote to upstream in your git repo: git remote add upstream git@mygitea.com:Y/B git branch --set-upstream-to=upstream master ``` If I do ``` git remote add upstream http://localhost:3000/Y/B git branch --set-upstream-to=upstream master ``` I get ``` error: the requested upstream branch 'upstream' does not exist ``` I'm not intending to track an upstream branch with 'mybranch' - I do want 'mybranch' to fast-forward master on Y/B. ``` 2. set the right repo ad hoc. --head can be omitted, if you currently have that branch checked out. tea pr create --repo Y/B --head X:mybranch ``` I get: ``` Local repository required: Execute from a repo dir, or specify a path with --repo. ``` ..with my current directory the clone of the fork of the target repo and with 'mybranch' the current one. I have tried --base Y:master and --base master also, with same result.

noerw commented

2021-07-08 20:16:53 +00:00

Sorry I should have tested the commands I gave you ;)
For (1), the correct command is

git remote add upstream http://localhost:3000/Y/B
git fetch upstream
git branch --set-upstream-to=upstream/master master

For (2) I can confirm the errors, this should work & is a bug (#378).
aside: tea really needs a testsuite so regressions like these don't happen all the time. (and we probably should simplify the flags a bit, as usability doesn't grow with more flags #379 ;)

I'm not intending to track an upstream branch with 'mybranch' - I do want 'mybranch' to fast-forward master on Y/B.

Sure, but tea determines the default gitea repo based on the remote the local master branch is tracking, that's why we want a different upstream for master for pull requests.

Sorry I should have tested the commands I gave you ;) For (1), the correct command is ``` git remote add upstream http://localhost:3000/Y/B git fetch upstream git branch --set-upstream-to=upstream/master master ``` For (2) I can confirm the errors, this should work & is a bug (#378). aside: tea really needs a testsuite so regressions like these don't happen all the time. (and we probably should simplify the flags a bit, as usability doesn't grow with more flags #379 ;) > I'm not intending to track an upstream branch with 'mybranch' - I do want 'mybranch' to fast-forward master on Y/B. Sure, but tea determines the default gitea repo based on the remote the local `master` branch is tracking, that's why we want a different upstream for master for pull requests.

noerw referenced this issue

2021-07-08 20:20:17 +00:00

--repo flag skips reading the local repo #378

progman commented

2021-07-10 03:06:41 +00:00

Hi,
with revised commands for 1. followed by

tea pr c -t mypr

I get

Error: Could not create PR from X:mybranch to Y:master: 404 Not Found

'mybranch' had been pushed to the X gitea repo
from a clone.
I cannot otherwise guess what it cannot find!

Hi, with revised commands for 1. followed by ``` tea pr c -t mypr ``` I get ``` Error: Could not create PR from X:mybranch to Y:master: 404 Not Found ``` 'mybranch' had been pushed to the X gitea repo from a clone. I cannot otherwise guess what it cannot find!

noerw commented

2021-07-10 10:16:33 +00:00

It probably fails to look up the base repo.
What does tea open do when called in the repo dir? It should open http://localhost:3000/Y/B. If that gives a 404, your upstream remote url should be different.

It probably fails to look up the base repo. What does `tea open` do when called in the repo dir? It should open http://localhost:3000/Y/B. If that gives a 404, your upstream remote url should be different.

progman commented

2021-07-10 17:27:11 +00:00

it complains about
http://http/localhost:3000/Y/B
while the remote appears in .git/config
as
http://localhost:3000/Y/B

if I change it to
localhost:3000/Y/B
the output becomes:
http://http/localhost:3000/3000/Y !

it complains about ```http://http/localhost:3000/Y/B``` while the remote appears in .git/config as ```http://localhost:3000/Y/B``` if I change it to ```localhost:3000/Y/B``` the output becomes: ```http://http/localhost:3000/3000/Y``` !

👀 1

noerw commented

2021-07-10 18:06:25 +00:00

This is really odd, and I can't reproduce it.
Can you post the (sanitized!) content of your ~/.config/tea/config.yml? (tea login edit)
Thanks for your patience :)

I assume you have http/localhost:3000 as login url instead of http://localhost:3000 in config.yml

This is really odd, and I can't reproduce it. Can you post the (sanitized!) content of your `~/.config/tea/config.yml`? (`tea login edit`) Thanks for your patience :) I assume you have `http/localhost:3000` as login url instead of `http://localhost:3000` in config.yml

progman commented

2021-07-10 23:44:25 +00:00

logins:
- name: locd
  url: http://localhost:3000
  token: ...
  default: false
  ssh_host: localhost
  ssh_key: /home/dev/.ssh/id_rsa
  insecure: false
  user: dev
  created: 1625880070

I assume you have http/localhost:3000 as host instead of http://localhost:3000

I don't know what you mean - tea seems to me
as if it is munging a perfectly fine remote
string into something screwy.

Thanks for your patience :)

hold on, it's probably my having done something dumb! ...

``` logins: - name: locd url: http://localhost:3000 token: ... default: false ssh_host: localhost ssh_key: /home/dev/.ssh/id_rsa insecure: false user: dev created: 1625880070 ``` >I assume you have http/localhost:3000 as host instead of http://localhost:3000 I don't know what you mean - tea seems to me as if it is munging a perfectly fine remote string into something screwy. >Thanks for your patience :) hold on, it's probably my having done something dumb! ...

progman commented

2021-07-13 09:51:22 +00:00

I'm not suggesting waiting on a full confession!
Only that often one's issues turn out to be self-inflicted.

does my config.yaml yield any clues?

I'm not suggesting waiting on a full confession! Only that often one's issues turn out to be self-inflicted. does my config.yaml yield any clues?

noerw commented

2021-07-13 10:39:32 +00:00

That config looks totally fine. I'm a bit stumped how tea came to generate these broken URLs, given that the inputs (login url, remote url) seem to be well formed.

I didn't ask so far what tea version you used? (as I can't reproduce with 0.7.0 and current master branch..)

That config looks totally fine. I'm a bit stumped how tea came to generate these broken URLs, given that the inputs (login url, remote url) seem to be well formed. I didn't ask so far what tea version you used? (as I can't reproduce with 0.7.0 and current master branch..)

progman commented

2021-07-14 09:20:32 +00:00

I'm using 0.7.0

progman commented

2021-07-14 15:50:38 +00:00

I've created a B here then, since not possible to fork a repo from one's own account, cloned it locally
then pushed it to an empty repo A on here.
the .git/config in the local copy of A (is this now any different from a clone of a fork?) is:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = https://gitea.com/progman/A
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = upstream
        merge = refs/heads/master
[branch "mybranch"]
        remote = origin
        merge = refs/heads/mybranch
[remote "upstream"]
        url = https://gitea.com/progman/B
        fetch = +refs/heads/*:refs/remotes/upstream/*

and when I do a tea open in that clone
I see the munging:

http://https/gitea.com/progman/B

Does anything look wrong about this config?
(of course this is being done through one user ident but I'll create a 2nd if necessary)
thanks!

I've created a B here then, since not possible to fork a repo from one's own account, cloned it locally then pushed it to an empty repo A on here. the .git/config in the local copy of A (is this now any different from a clone of a fork?) is: ``` [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = https://gitea.com/progman/A fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = upstream merge = refs/heads/master [branch "mybranch"] remote = origin merge = refs/heads/mybranch [remote "upstream"] url = https://gitea.com/progman/B fetch = +refs/heads/*:refs/remotes/upstream/* ``` and when I do a ```tea open``` in that clone I see the munging: ``` http://https/gitea.com/progman/B ``` Does anything look wrong about this config? (of course this is being done through one user ident but I'll create a 2nd if necessary) thanks!

progman commented

2021-07-17 07:37:17 +00:00

does the --description argument work for you? where I can get a PR created is between different branches on the same repo, and this argument seems to have no effect here.

does the --description <value> argument work for you? where I can get a PR created is between different branches on the same repo, and this argument seems to have no effect here.

noerw commented

2021-07-17 08:31:50 +00:00

@progman this was fixed in #371 but isn't released yet

Your .git/config also looks all good to me. I really don't get how this would be happening. Does this happen on a different machine for you as well?

@progman this was fixed in #371 but isn't released yet Your `.git/config` also looks all good to me. I really don't get how this would be happening. Does this happen on a different machine for you as well?

noerw commented

2021-10-18 10:19:53 +00:00

I'll close this, feel free to reach out if you still have questions. tea 0.8.0 was released in the meantime

noerw closed this issue

2021-10-18 10:19:53 +00:00

noerw referenced this issue

2021-10-18 10:27:32 +00:00

Improve Documentation #433

6543 referenced this issue from a commit

2021-12-02 18:33:57 +00:00

Improve Documentation (#433)

Sign in to join this conversation.