Git/github advice Topic is solved

[Pete9008]

While looking at high saliency motor data I've become convinced that we may be able do better so i would like to try a few things.

Now I already have a fork of the necessary OpenInverter repos but they have diverged somewhat (due to both my changes and parent repo changes). I don't want to lose my changes (some in main and some in a branch). If any of the ideas work it would be nice to be able to to a pull request.

What's the best way forward?

Is it possible to somehow start a new branch in my existing fork, undo all my changes just in that branch and then apply all Johannes changes to get to a branch that is up to date? If so any hints as to what the git black magic syntax is to do this?

Or should I fork Johannes repo again to create a second OI firmware repo in my github account (can you have two forks of the same repo in the same account)?

Sorry for all the questions but I still find git confusing and I'm sure I can waste a lot or time (and potentially do a fair bit of damage) Trying to figure this out by trial and error!

Edit - probably worth mentioning that the changes are likely to affect the main code and the libopeninv submodule. I have existing forks of both, and both have diverged.

[Bigpie]

I'd probably create a new branch from your main/master, push that to github

Code: Select all

git checkout -b new_branch_name

will create a new branch for you (assuming you're already on main/master)

Push to github

Code: Select all

git push -u origin new_branch_name

Add johannes as a new remote (upstream)

Code: Select all

git remote add upstream git@github.com:jsphuebner/stm32-sine.git

Code: Select all

git fetch --all

Reset your main/master to johannes

Code: Select all

git reset --hard upstream/master

[Pete9008]

That's odd, after thanking your post I lost the quick reply box at the bottom of the thread

Edit - even after posting a reply via the quote button the quick reply is still missing (just for this thread though, it's there for others)?

Edit2 - Also for the last couple of days, when on Android, I seem to need to clear cookies before I can sign in, has there been a forum update?

I'd probably create a new branch from your main/master, push that to github

Code: Select all

git checkout -b new_branch_name

will create a new branch for you (assuming you're already on main/master)

Push to github

Code: Select all

git push -u origin new_branch_name

Comfortable with those bits

Add johannes as a new remote (upstream)

Code: Select all

git remote add upstream git@github.com:jsphuebner/stm32-sine.git

Code: Select all

git fetch --all

Reset your main/master to johannes

Code: Select all

git reset --hard upstream/master

This where I lose it. Isn't Johannes repo already set as upstream (as it's forked from there) or is this setting a different upstream just for the branch and if so why?

I get very uneasy about commands like 'git reset --hard upstream/master' as they sound dangerous, what does it do, does it just affect the branch?

Could really do with a git primer somewhere including the common commands There are a lot of professional programmers on here who just seem to know how to use it and as an occasional coder, who is OK with SVN but not used git much, I find it all really confusing. There are plenty of guides on the web but they all seem to either just cover the very basic stuff or go right over my head - if anyone knows of a good one please could you let me have a link?

[Bigpie]

His repo is set as the origin of the repo on your github. You local repo only knows about your github repo at the moment. It's quite a different mindset from SVN. Think of each as a separate node. You could probably do what you want using the github UI.

The git reset will make your branch history match that of the upstream, hence the creating a branch for your changes before hand. There will be other ways to achieve this outcome.

[Pete9008]

His repo is set as the origin of the repo on your github. You local repo only knows about your github repo at the moment. It's quite a different mindset from SVN. Think of each as a separate node. You could probably do what you want using the github UI.

The git reset will make your branch history match that of the upstream, hence the creating a branch for your changes before hand. There will be other ways to achieve this outcome.

Still not got a quick reply box on this thread

Thanks, so once you are in a branch is everything you do contained completely to that branch, both the upstream and the reset commands? What I don't want is to do a reset and find it wipes out all my changes in the master and other branches (I also still haven't figured out how to undo things either).

If I change the upstream and then do a push is that still pushing to my github repo?

Edit - notice you use git@github.com: instead of https://github.com/, is there any difference/benefit of one over the other or are they equivalent?

Edit2 - just found this https://git-scm.com/book/en/v2/Git-Basi ... th-Remotes and remotes are starting to make sense, the git remote show command looks particularly useful for seeing how stuff is set up.

[Pete9008]

This may be starting to make sense

Is the following right? :

The local repository is basically a chain of snapshots, one for each commit. Each commit points to the previous one forming a chain (each link being a commit). Each commit also points to a snapshot of the working directory which stores the entire contents/state of the working directory at that point. The snapshots can share binary images of files that don't change so the whole repository isn't anywhere near as big as you might expect.

So whatever you do the previous versions is still there in full in the commit snapshots. To get back to an earlier state you just checkout the snapshot you want which restores the working directory to the state it was in when the commit/snapshot was made.

Creating a branch is just creating another pointer to a different chain of commits which branches off from wherever you were when the branch was created. It doesn't add a new snapshot, just a new pointer to an existing snapshot.

Branches can have different pull and push remote repositories (I think).

I think the fundamental difference I hadn't fully 'got' was that both the local and remote repo contains all the history (all the snapshots). A push or pull is just copying across the missing commits, snapshots, branch names, etc, it only ever adds stuff. Even deleting is just adding a new snapshot, the deleted file is still there in the repo blob store (it just isn't referenced by the new commit/snapshot). As you say fundamentally very different to SVN/CVS!

[Bigpie]

Sounds like you've got it now. A nice visual cheatsheet is here https://ndpsoftware.com/git-cheatsheet. ... local_repo; Click on Local Repo then reset --hard for example

There's still features I don't understand, but for day to day, I've not needed them. It's been a long time since I used SVN and even more so CVS

[Pete9008]

Good link, thanks.

And now I've started to get my head round how it works your instructions make sense too

[Pete9008]

I'd probably create a new branch from your main/master, push that to github

Code: Select all

git checkout -b new_branch_name

will create a new branch for you (assuming you're already on main/master)

Push to github

Code: Select all

git push -u origin new_branch_name

Add johannes as a new remote (upstream)

Code: Select all

git remote add upstream git@github.com:jsphuebner/stm32-sine.git

Code: Select all

git fetch --all

Reset your main/master to johannes

Code: Select all

git reset --hard upstream/master

Just thinking about this a bit more, would another way of doing it be to checkout the first commit of my fork, which should put the working directory back into sync with Johannes old version, create a branch from that, set his repo as upstream and then fetch/pull all the changes he has made since then? Would that essentially do the same thing? Don't think either approach is better or worse but would like to see whether I'm understanding it right?

Edit - the other thing I'm staring to realise is that it is actually safe to try these things as long as nothing is pushed, worst case you just delete the local repo and start again!

[Bigpie]

If you checkout a commit that's not the head of the branch, you become in a 'detached head' I've not done this and created a branch before, but I 'think' you could do this, then rebase your changes on to the new branch but I'm not 100% confident on that

[Pete9008]

Am I right in thinking that it would only be in the detached head state until the new branch was created? Once created would head be pointing to the last commit in the new branch?

Btw, thanks for mentioning the detached head state, it's amazing how much easier it is to find stuff once you know the correct terminology. Off to google rebase now!

Edit - Ok, I might now understand rebase. Would it be needed in this case, as none of my changes are needed in the new branch, or would it just be a fast forward merge of the upstream changes to get the branch up to date with Johannes latest?

[Pete9008]

Figured out why I always get lost with this, the libopeninv submodule within stm32-sine project isn't called in at the latest version (0bef3c1), instead the submodule is at commit 350fc75. If you try and build with the latest code you lots of CAN module errors.

So what should I do here, in my project should I checkout the submodule at 350fc75 (which puts it in detached head mode) and then create the branch from there and start making my code mods? Will this cause problems at a later date if a pull request is needed?

[Bigpie]

350fc75 looks like is on a can refactoring branch (https://github.com/jsphuebner/libopenin ... _structure) not sure why, you can merge your new branch back in to that branch or any other.

[Pete9008]

350fc75 looks like is on a can refactoring branch (https://github.com/jsphuebner/libopenin ... _structure) not sure why, you can merge your new branch back in to that branch or any other.

Think it's done, the MTPV branch is on the local repo and the remote and both tell me that they are up to date with Johannes (and seem to have the same commit ref)

Ended up checking out 7f33001 (pre all my earlier mods and common to Johannes - detached head now reported), created the branch (detached head disappears), pushed branch to origin, did a git pull upstream master which pulled all the more recent changes into the local branch (up until this point it was telling me that the libopeninv had been modified but is now considered up to date) and finally a git push to update the origin. No idea if that was the right way to do it???

I can see the power of git, and the way it works is very, very clever, but it still confuses the hell out of me!

Assume Johannes is in the middle of some CAN changes that haven't made it into the inverter code yet?

[catphish]

The local repository is basically a chain of snapshots, one for each commit. Each commit points to the previous one forming a chain (each link being a commit). Each commit also points to a snapshot of the working directory which stores the entire contents/state of the working directory at that point. The snapshots can share binary images of files that don't change so the whole repository isn't anywhere near as big as you might expect.

So whatever you do the previous versions is still there in full in the commit snapshots. To get back to an earlier state you just checkout the snapshot you want which restores the working directory to the state it was in when the commit/snapshot was made.

Creating a branch is just creating another pointer to a different chain of commits which branches off from wherever you were when the branch was created. It doesn't add a new snapshot, just a new pointer to an existing snapshot.

Yes, this is exactly how it works

A commit is a metadata entry that points to 1) snapshot of your tree and 2) the previous commit to form a chain.

A branch is simply a name that points to a commit. The purpose is to allow you to maintain multiple independent chains of commits.

Git is decentralized which means your local version can have as many branches as you like, and each one stores its own full chain of commits. When you push, you are sending a particular named branch to a repository somewhere else, replacing whatever that named branch previously pointed to at the remote location.

This leads itself to being able to do all sorts of useful things. For example, you could pull someone else's "master" branch into your local copy, but call it something else. You can then advance that copy and push it back to your own Github. And finally use a Github "pull request" to ask the original owner to merge your branch into theirs.

I hope it's all making sense. I consider Git to be simultaneously very simple and very complicated.

Another useful thing you can do is to make a new branch from any point in your commit history, and then "cherry-pick" individual more recent commits into it. This means you can make a branch that contains just selected changes.

[Pete9008]

Thanks, nice to have it all confirmed. Also found a couple of useful commands (probably well know to regular git users but new to me) which I have found very useful in making sense of it all:

git remote -v This tells you what remotes are set up for the project

git log --oneline --decorate --graph --all This gives you a report showing all the commits and a semi graphical view of all the branches.

Couple of questions, is there a gui for git on Linux that is worth using or does everyone use the command line? If the command line are there any shortcuts for the log command as typing all that it is a pain!

[catphish]

Is there a gui for git on Linux that is worth using or does everyone use the command line?

There are several GUIs. I usually use the command line, but I also like "Github Desktop".

With regard to "shortcuts", you should learn to make heavy use of tab completion. If you start typing almost anything and press tab it will complete it for you. This works for commands, branch names, remotes, etc. I also use ctrl-r to quickly search back previous commands that I use a lot.

[Pete9008]

I do use tab completion a lot but you do need to remember the first letter of each option and my memory is rubbish!

Edit - Just tried ctrlR but can't quite see what it does. I use the up and down keys a lot to go though the history. Is there any way to bring up a list of the history?

Edit2 - Found you can add aliases for commonly used commands using git config and ended up using this https://gist.github.com/bensternthal/9238814 to create an lg command that gives the detailed log.

[catphish]

Edit - Just tried ctrlR but can't quite see what it does. I use the up and down keys a lot to go though the history. Is there any way to bring up a list of the history?

ctrlR is a search, so if you press ctrlR then start typing, it will bring back the last matching command. Then if you press ctrlR again, it will cycle older matching commands.

I use it a lot to bring back complicated commands that I've used previously. I'm not sure it's that useful for git, but I use it a lot. For example when I want to set up my CAN interface, I press ctrlR and type "can" and it brings back the last matching command "sudo ip link set can0 up type can bitrate 500000".

To bring up a list of history, you can just run the command "history" and it will dump out the full list. Bash has no way to browse and select from the list though as far as I know. Other shells are more "graphical" like that.

[Pete9008]

Thanks, looked it up after you first mentioned it and have already used it quite a bit - very useful!