Skip to content
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

Detect bogus PRs #268

Open
nomeata opened this issue Jun 7, 2019 · 9 comments
Open

Detect bogus PRs #268

nomeata opened this issue Jun 7, 2019 · 9 comments

Comments

@nomeata
Copy link

nomeata commented Jun 7, 2019

I usualy do

git checkout -b joachim/feature
git commit
git hub pull new

or

git commit
git branch -m joachim/feature
git hub pull new

Sometimes I mix the two up, and end up doing

git commit
git hub pull new

which pushes my changes to master, and then tries to create a PR against master, which fails (no commits).

It would be great if git hub pull new would detect that it would push to the base branch, and just abort with a message and without doing anything.

@leandro-lucarella-sociomantic
Copy link
Contributor

I'm setting this as low-prio as it is a minor usability issue.

Pro-tip: use git hub pull new -c joachinm/feature always and that's it.

@leandro-lucarella-sociomantic
Copy link
Contributor

BTW, the tool was created with a triangular workflow in mind, i.e. always using forks to create PRs from, so there might be more areas where it behave funnily if you just use one remote.

@nomeata
Copy link
Author

nomeata commented Jun 12, 2019

if you just use one remote.

corporate environment here…

Pro-tip: use git hub pull new -c joachinm/feature always and that's it.

I sometimes use that mode, but then I have to follow up with git reset --hard origin master so that my local master is accurate again.

@leandro-lucarella-sociomantic
Copy link
Contributor

corporate environment here…

I'm deeply sorry :)

I sometimes use that mode, but then I have to follow up with git reset --hard origin master so that my local master is accurate again.

Right. But you have a similar problem with your second case, actually your local master is gone. You could also just do the git branch -m joachinm/feature after the git hub pull new -c joachinm/feature.

@nomeata
Copy link
Author

nomeata commented Jun 13, 2019

actually your local master is gone

That’s what I thought too at some point. But not a problem with recent gits; git checkout master will just magically recreate it!

You could also just do the git branch -m joachim/feature after the git hub pull new -c joachim/feature

But then I have to type the feature branch name twice :-)

@leandro-lucarella-sociomantic
Copy link
Contributor

¯_(ツ)_/¯

To be honest I feel like this feature request is just not worth it. Reasons are:

  1. It addresses a very rare use case.
  2. There are easy workarounds.

But if there is an implementation that doesn't involve adding new API requests (I think it is also not worth slowing down every call to hub pull new to fail early on very rare use cases), I would be happy to merge it.

@leandro-lucarella-sociomantic
Copy link
Contributor

BTW, if you use bash, you don't even have to type it twice, just use Alt-.:

git hub pull new -c joachinm/feature
git branch -m [Alt-.]

@nomeata
Copy link
Author

nomeata commented Jun 13, 2019

But if there is an implementation that doesn't involve adding new API requests

Yes, absolutely, if you are reluctant adding this that’s totally fine. I was hoping all information is already easily present (e.g. seeing that hub.upstream = hub.forkrepo and -b = HEAD).

@leandro-lucarella-sociomantic
Copy link
Contributor

Yeah, I didn't thought about it in depth, but it probably can be done without querying the API. I'll leave it open in case someone wants to pick it up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants