How to push an improved function to your project ?

[schlebe]

I'm new in using Github.

One month later I made a Pull Request.

I change your code locally on my PC.

Today, I want to push my work so that you can read it and perhaps integrate it in your final solution.

When I click to push my work on Github, Visual Studio 2022 indicates that there is an error without displaying which !
So, finally, I succeed to push my change locally ... but only locally.

How can I push my work on your Github project ? Which git command can or must I use ?

[AdamWhiteHat]

Whoops! I think everyone makes this mistake at least a few times in their careers, and continue to make this from time to time because its easy to do if you're not paying attention, pressed for time, etc.

One nice thing about git is that you can probably get yourself out of nearly any bind you can get yourself into, by accident. You would really have to be deliberate and go out of your way to put yourself into a situation that was impossible to recover from.

That said, any kind of unsticking yourself from a situation using git is going to require using git on the command line, and using git on the command line can be quirky, tedious and daunting. While there almost always exists some magic incantation that does precisely what you are looking for, finding it, and understanding it well enough to feel confident you are not going to dig yourself a deeper hole, can be difficult and time consuming.

A Fork in the Road

First, I'd ask if was done on a fork of the repository or not?

Looking at the repositories on your account, it doesn't appear this is the case, so I am going to proceed to answer under the assumption that the answer is 'No'.

For those who have come here with the same problem, but who's answer to the above question is Yes, your situation is less complicated, and you can, if you want, skip to Step # 5 and straight to the git command(s) to move your local commit into a different branch that's not main. If you did not do this to your own fork, however, just moving your local commit out of main and into another branch wont get you too far, as you likely will be just as unable to push that new branch to the repository if you don't have commit access to it. You solution will involve moving your local commit into a different repo.

I am going to first give a high-level overview of what we are going to do first, as I think that will aid in your overall understanding if you have the big-picture idea in mind and where we are going. I hate blindly following directions without any context for understanding them in, or any idea why, and I presume you do as well.

Without delay:

1. First we will fork my repo. A pull request typically will requires you to have your changes checked into a branch on a fork you own, and then use that branch to in a pull request. This is because a person typically does not have permissions to create a new branches on another person's repo. We will do this through github.com's website.
2. Then we will use the git command line to add your newly forked repository as a "remote tracked repository" (referred to as a "remote" going forward) to your git repo that you made your changes to (the folder in which BigDecimal was placed when you cloned it, is a git repository). We will give the new remote repo we add a name. I typically name different remotes/forks after the username they come from, so we will probably name yours "schlebe".
3. We will unset the upstream branch on your checked-out main branch (the branch you made your commit to. likely the current one)
4. We will set the upstream branch on your (current, checked-out) branch to be schlebe/main. This will point towards your fork. You fork will not be the destination for this branch and whatever commits it has. The terminology here is is perhaps a little confusing; branches only track other branches (which reside on a remote), not remotes directly. This makes sense, because a remote repository may contain many branches.
5. At this point you could push your local commit, and it would push the commit to schlebe/main, your fork. But since the typical workflow is to create a branch off of the main branch, to commit your work to your working branch, then merge your working branch back to the main branch (or request it be merged via a pull request), we will copy the current branch, into a new branch. This is with the branch command, and by specifying the copy flag (-c) with the branch command, your local commits will be brough along into the copy, and they will appear on your new branch--just as if you had created a branch first, and then committed your changes to that branch instead.
6. Undo changes on the main branch and check out clean state. Since your changes are now (copied) in another branch, we undo the changes committed to main and pull down a fresh, clean state. Future contributions should start by fetching the latest changes to this branch, then creating a branch from it and working in the new branch.
7. Then you will push your new branch to the remote repo, which will be your fork. Your branch which contains your changes should appear on your fork.

And then, at this point, you are welcome to submit a pull request on my repo, and should be able to select your branch on your fork as the branch to merge into mine.

Onward:

1. Fork This Project!

So first, you will need to fork my repo.
So browse to https://github.com/AdamWhiteHat/BigDecimal and click on the fork button near the upper-right corner.
Keep the name BigDecimal, click to accept and you should land at https://github.com/schlebe/BigDecimal

2. Finding the Remote
(git repo, not tv controller)

As mentioned, we will need to use the git command line to accomplish what we need to do.

In the instructions below, I will style command line commands in code formatting like this to help eliminate confusion about which words are the command and which words are not.

I am going to assume your OS is windows. Let me know if this is not the case.

I use the git bash environment command line application available from https://git-scm.com
You should probably already have that installed, as I think visual studio might even install it for you as its default git client, although I could be wrong about that.
To find out, hit your windows key, or bring up the start menu and type git bash to search for it. If its not installed, go to https://git-scm.com and download the appropriate version for your OS.

Once git bash is up and running, type pwd and hit enter to find out what directory the current directory is, it will probably be in your user account folder.

Mine is: /c/Users/CodeNinja
Which is just C:\Users\CodeNinja but looks like that since it's a GNU environment, and this Unix-like environment uses forward slashes instead of backslashes and treats the C drive as just another folder.

Use the cd command to navigate to the directory where you cloned BigDecimal down into.
For example, I cloned mine into C:\Users\CodeNinja\source\repos\BigDecimal

If you browse to it in file explorer and copy the full path to it once there, you can use the middle button on your mouse to paste it into the console window in order to "cd" directly there in a single command:
cd "C:\Users\CodeNinja\source\repos\BigDecimal"

Quote the path if you find that that upon hitting enter, all of your backslashes have been stripped away. This is weird behavior, and I just noticed it doing this to me for the first time today--just now while writing this--but its doing it to me consistently now so perhaps its a bug you will encounter too. Quoting the path fixes this issue.

Once you are in the BigDecimal directory, if the directory is under git version control, the name of the branch should appear in a teal color next to the directory path when you type dir

Type git status to confirm you are in a git repository. If it comes back with:

fatal: not a git repository
Well, then its not a git repository.

For you, it will probably say something like:

On branch main
Your branch is ahead of 'origin/main' by 1 commit.

Entering:
git remote --verbose

Should show you something like:

origin https://github.com/AdamWhiteHat/BigDecimal.git (fetch)
origin https://github.com/AdamWhiteHat/BigDecimal.git (push)

We want to add your fork as a "remote tracked repository", and the command for that should be, verbatim:
git remote add schlebe https://github.com/schlebe/BigDecimal.git

Now typing:
git remote --verbose

Should show:

origin https://github.com/AdamWhiteHat/BigDecimal.git (fetch)
origin https://github.com/AdamWhiteHat/BigDecimal.git (push)
schlebe https://github.com/schlebe/BigDecimal.git (fetch)
schlebe https://github.com/schlebe/BigDecimal.git (push)

Please ensure that its looks like the above.

The problem with the "git remote add" command is, if the remote address is wrong, truncated, or is nonsense garbage, it wont alert you to the fact that there is a problem, but it will definitely cause some problems in the later steps, and it might be hard to know why, so its probably worth just double checking that the command looks like it got entered correctly, and that "git remote --verbose" looks like above.

3. Unsetting the Upstream Branch

We need to unset the upstream branch on your current branch.

Assuming you checked in your commit to the branch "main", and that the current branch is still "main", the command for this is:
git branch --unset-upstream main

If you need to switch branches to get back to main, or whatever branch you made your commit to, you should be able to simply do:
git switch main

4. Un-Unsetting the Upstream Branch
(a.k.a. Re-Setting the Upstream Branch)

We now need to set the upstream branch to schlebe/main.
But first we need to fetch the histories, objects and refs from the newly-added remote repository 'schlebe'.

Luckily, git provides us with a command that allows us to get two birds stoned at once:
git fetch schlebe --set-upstream main --refetch

Here we are performing 'git fetch', but of specifically the remote repository 'schlebe'. Issuing 'git fetch' without specifying the remote repository name is equivalent to issuing 'git fetch origin'.

git-scm.com's documentation for git-fetch has this to say about the --set-upstream flag:

If the remote is fetched successfully, add upstream (tracking) reference [...]

And it takes 1 argument: The (remote) branch name to track, because remote tracking tracks branches, not repositories. The remote branch to track here is main.

Note that our local branch is also named 'main', which is perhaps a bit confusing for us. Not for git though, its expecting a name of a branch on the remote repository. Unfortunately, we are not able to specify schlebe/main here to make this explicit.

The --refetch flag is not strictly necessary, but may fix problems in certain scenarios where the local repository's object database might be incomplete or corrupted. But primarily it makes git produce more verbose output as it downloads files from the server, which gives us something more interesting to stare at instead of a blank line with a blinking caret.

5. Branching Begets Branching

Copy the current branch, into a new branch:
git branch -c main a-faster-log-natural

(or whatever you want your branch name to be. here I choose "a-faster-log-natural", as (I think) that describes what your changes aim to do. Feel free to substitute "a-faster-log-natural" with whatever you want.)

The above command only creates the branch, but does not switch to it, so we must switch to the new branch:
git switch a-faster-log-natural

Now you can push your commit to your forked repository, finally pushing them to beyond only local commits:
git push

Now if you browse to your fork at https://github.com/schlebe/BigDecimal you should see your new branch available under the branch drop-down control.

6. Un-Maim the main

Before we create a pull request, lets clean up your main branch by bringing down a clean copy from the server that doesn't have your local commit checked into it by issuing these commands in order:

git switch main
git branch --unset-upstream main
git switch a-faster-log-natural
git branch --delete main
git checkout --track schlebe/main

7 In Order to Pull, One Must First Push

Head back over to your fork's GitHub page: https://github.com/schlebe/BigDecimal
Under the branch drop-down control, switch to your new branch by selecting it from the dropdown.

Once you do, right there at the top, it should say something like:

This branch is 1 commit ahead of AdamWhiteHat/BigDecimal:main.

And just to the right of that you should see another drop down that says "Contribute".
Expand that and click on the "Open Pull Request" button, and fill out the form.

...

I seen your other questions about the tests. Everything looks normal in your screenshot. In order to start them, there is a green triangle icon on the test window toolbar. Its supposed to be a "play" button.

Those should launch the tests. If that's what you tried, and nothing happened, yeah that's very strange and I'm not sure what is wrong without seeing what its doing in real time.

But since you tried to do the right thing and write a test, but you were having trouble, I don't mind writing the function to call it with some the same test values the current function runs with and gathering some timing metrics around it with the stopwatch class as a comparison. I am curious to see how you were able to speed it up. Its true its probably the slowest function in the entire library as it can be slow to converge with certain inputs.

...

Hopefully the above should work for you. Let me know if any of these steps did not work for you. Include a screenshot or copy of the output or error message if you have one to help me identify what went wrong.

P.S. Thanks for asking this question in the "discussions" area, so that others who fall into the same trap may benefit from it also.

[schlebe]

Hello Adam,

thanks to help me and the big work to write it.

I have done what you explain until point 4. At this point, I encountered followed problem

C:\Users\berna\source\repos\AdamWhiteHat\BigDecimal>git remote --verbose
origin  https://github.com/AdamWhiteHat/BigDecimal (fetch)
origin  https://github.com/AdamWhiteHat/BigDecimal (push)
schlebe https://github.com/schlebe/BigDecimal.git (fetch)
schlebe https://github.com/schlebe/BigDecimal.git (push)

C:\Users\berna\source\repos\AdamWhiteHat\BigDecimal>git branch --set-upstream-to=schlebe/main
error: the requested upstream branch 'schlebe/main' does not exist
hint:
hint: If you are planning on basing your work on an upstream
hint: branch that already exists at the remote, you may need to
hint: run "git fetch" to retrieve it.
hint:
hint: If you are planning to push out a new local branch that
hint: will track its remote counterpart, you may want to use
hint: "git push -u" to set the upstream config as you push.

C:\Users\berna\source\repos\AdamWhiteHat\BigDecimal>

The repository exist on my personal GitHub space and it contains only a branch named main !

What can I do now to unlock this situation ? Must I do a git fetch or a git push -u ? What is the correct command to use in my situation ?

On my PC in C:\Users\berna\source\repos\ folder is see only old AdamWhiteHat\BigDecimal folder.

Thanks for any help.

[AdamWhiteHat]

I realize you may have already gotten past this, but I wanted to answer your question for the purposes of posterity.

I referred to this page and followed my steps above recently when I wanted to do the same thing at work, and indeed encountered the same problem at the same step as you mention.

I will edit my tutorial above appropriately to include this correction, so hopefully in the future, I or someone else can follow them and achieve success.

For brevity, Ill just get right to the answer without providing too much detail or caveats for scenarios that seem unlikely for those following this tutorial:

Assuming _main_ is a valid branch on the newly-added remote repository _schlebe_, one should be able to entirely replace Step 4 with the following command:

git fetch schlebe --set-upstream main --refetch

Lets break this command down:

1. git fetch schlebe
   • Fetches the histories, objects and refs from the remote repository 'schlebe'. Simply 'git fetch' wont work, because by default git fetch only fetches the origin. Adding the new remote repository in Step 2 does exactly that, nothing more. But what we are missing here is the histories of the new remote repository.
2. --set-upstream main
   • If the remote (schlebe) is fetched successfully, this configures the branch main (of the remote) to be the upstream (tracking) reference branch for the current (local) branch. The use of 'main' here is maybe slightly confusing because the local branch is also named main, but I double checked and performed some tests that the argument for this flag is the name of a branch on the remote repo specified elsewhere in the command, and you are not able to specify it as schlebe/main or something to make it explicit.
3. --refetch
   • This (optional) flag fetches all objects as a fresh clone would. This flag isn't really necessary. Its primarily designed for people who are using clone filters, and if those filter definitions have changed, which is unlikely to apply to anyone following this tutorial. What it DOES do for the rest of us, is it fixes scenarios where the local repository's object database might be incomplete or corrupted, and for repos where that's not the case, it may still provide some minor performance benefits because it "performs object database pack consolidation" which compresses the object database and removes any duplicate objects.
   • But I think the primary importance of this flag, at least for me, is this flag causes git to produce some animated output to watch while its working, such as percentage counters that track the progress downloading files from the server and so on, and thus makes it feel like the above command is actually doing something. And this is a lot more satisfying than what it displays without it: A blinking caret for some time followed by 2 static lines of text (boring!).

Anyways, I believe by replacing step 4 with the above command, you should be able to continue on to Step 5 without modification. I will update the tutorial above to reflect this, replacing what was said before with this corrected step, so as to keep the tutorial as clean and straightforward as possible.

[schlebe]

Sorry Sorry Sorry to keep this message.
I have now buyed a book about GIT on O'Reilly to learn it and I have saved 2 modified sources in a backup directory on my PC.
Then I cloned your GITBUB on my personnal space on GITHUB and I changed directly theses 2 sources on Github.
I have now made a PullRequest.
Now you can admit or refuse it in your main repository.
Best regards