Thanks for the PR! I believe, the current form is historic and should be reconsidered fundamentally.

git 1.7 was released in 2010. Do we really have to make things more complicated by distinguisheing and explaining workflows for software that is 14 years old? I'd rather just assume that everybody has a newer version.

But irrespectively, I would not recommend --set-upstream here. Yes, --set-upstream has its justification, but if you are not a git expert, --set-upstream is more complicated:

• you have to learn what it does (or just use it without questioning, but that makes git look even more complicated)
• you have to learn what the benefits are for subsequent commands (mostly git psuh) are and how they look. Otherwise you've gained nothing. . But for a beginner, I think it's still more complicated to learn: use git push --set-upstream origin my-branch for the first push and git push afterwards; rather than just learn always git push origin my-branch.

I propose to just delete this block:

Note also that https://learn.scientific-python.org/contributors/first-contribution/ does not mention --set-upstream. I consider that as the canonical workflow guideline. If --set-upstream should be discussed, I would vote to get it in there and link to it from the matplotlib docs "for a more refined workflow".

Additionally, I propose to put the following paragraph into a .. hint:: to set it apart from the standard workflow:

Do we really have to make things more complicated by distinguisheing and explaining workflows for software that is 14 years old? I'd rather just assume that everybody has a newer version.

To be fair to @juanis2112, she said the same thing and I was the one who said to put it in just in case there was someone who had very strong opinions about us keeping it. If there aren't any, then 🤷‍♀️ I don't have an issue with deleting it.

Thanks for your comments @timhoffm. I was actually the one who wrote the scientific python guide and now I'm reconsidering some stuff there based on the experience I've had at the SciPy sprints. I will probably review it and make some edits after the sprints.

I agree there's no need to add workflow explanations for old versions of git so I'll go ahead and remove the tab.

About tracking the branches, I added the 'set-upstream' part because that's what git suggests when you only do 'git push' but it does require further understanding. It's definitely not needed for doing the 'first PR' but if there's extra changes needed within the same branch, this is something that people will eventually have to do so maybe it is good to have it somewhere after. For example in the sprints guide it is mentioned later. In the Matplotlib guide it probably belongs to the section 'Update a pull request'. Let me know if this makes sense and I'll do it that way.

Also I'm happy to implement the hint too.

I’m confused by this as I always just do git push origin and don’t usually have a problem. I have only occasionally seen the error about not having an upstream branch. I’m not certain, but I think it happens when I branch off a branch that I subsequently delete.

These are my two recent changes. If you all agree, I can update the PR description and screenshots!

I will probably review it and make some edits after the sprints.

🚀

I would find a diagram of the workflow helpful. There are many visualization variants out there. I likte this one, tough I would make a stronger visual connection between the the two occurences (main + feature branch) of the local and of the remote repos.

Oh, I get it now. Thanks!

It looks like some exception handling changes accidentally made it into this PR branch?

It looks like some exception handling changes accidentally made it into this PR branch?

Those are on main - a rebase should fix this.

Thanks for your suggestions @timhoffm. I just made a commit with the changes.

I'll also look into the diagram idea once I start working on the SP guides.

Not sure what the 'Exeption handling control' changes are. I did do a rebase on this PR after opening since there were some changes pushed to main while I was working on it. @tacaswell please let me know what to do or how to fix this.

Not sure what the 'Exeption handling control' changes are. I did do a rebase on this PR after opening since there were some changes pushed to main while I was working on it

Could you have accidentally pulled main into your feature branch when rebasing? That exception came in from #28573 and another rebase should fix it.

There are two copies of this "Add tabs for push command depending on git version" commit (c8440972d55730dfe5dc016e56a10edb49aeee32 and ffdda7e590cd2180284ccf236fe06bd02552e7fd):

Likely what happened is that you rebased, and then you followed git's advice to do a git pull due to branch divergence. However, after a rebase, you've moved the commit (and it thus has a new hash), so you want to delete the old copy and do a force push to the remote. To be safer, you can do --force-with-lease to have git verify that the commit you are replacing on the remote is the same one that git thought it was locally.

To fix the PR, you can do the following:

$ git switch main
$ git pull
$ git switch fix-development-workflow
$ git rebase --interactive main

In the editor that opens, remove the line with the old copy of the duplicate commit (ffdda7e590), and if there are any, also remove any commits that you didn't do (but I don't think this should happen). This should end up as:

pick c8440972d5 Add tabs for push command depending on git version
pick 2603c1f5b1 Delete tab for branch tracking workflow
pick 54df55604c Apply suggestions from code review

Save, quit the editor, and the rebase should complete without issue. Then you need to force push to delete the extra commits on the branch on GitHub:

$ git push --force-with-lease origin fix-development-workflow

(You can leave out the remote and branch name if you have tracking set up, but it's nice to be explicit when force pushing.)

If you want to do a little extra, as part of the interactive rebase, you can change the second and third lines from pick to squash (because the second commit basically reverts most of the first), and then update the commit message.

Thanks @QuLogic. I followed the steps, including squashing the commits and updating the commit message. However I don't see the new commit message reflected.

Also, the circle ci tests are still failing but it doesn't seem related to any files I changed. Thoughts?

However I don't see the new commit message reflected.

Since it looks like the actual commit (at least on here) is fine, you can try git amend to change the message, then git push (or maybe git push --force-with-lease to change it.

To fix the PR, you can do the following:

$ git switch main
$ git pull

Also, the circle ci tests are still failing but it doesn't seem related to any files I changed. Thoughts?

Ah sorry, in the instructions quoted above, I assumed your main branch was tracking the upstream remote, but it seems to be tracking your origin fork (you can check with git branch -vvv), so things went backwards a bit. You can either fix it by redoing the rebase and ensuring you merge with upstream:

$ git switch main
$ git pull upstream main  # Explicitly merging with upstream's main.
$ git switch fix-development-workflow
$ git rebase --interactive main

Or you can rebase against the upstream branch directly:

$ git fetch upstream
$ git switch fix-development-workflow  # If necessary.
$ git rebase --interactive upstream/main  # Rebase against the upstream main branch.

As part of the rebase, you can change pick to reword to get your editor and change the commit message if you want to do that as well.

Thanks @juanis2112!