Git Help

[jarmonik]

Some help with the Git needed. I started working on atmospheric rendering overhaul on D3D9client and I would like to "push" my current work in progress to a new branch.
The current branch is "orbitersim/d3d9client" that's where the changes go if I commit and push. But I would like to commit them to "jarmonik/orbiter/atmo-remake" instead and then make a pull-request later-on when the work is finished. No local/remote branch created yet. I have been writing code two months without touching the Git and I have forgotten most of it.

I tried with bad results:
-stash
-create/checkout new branch
-stash pop

So, I restored my "clean" backup copy of the work.

 

[n72.75]

Step 1. fork the repo.
Step 2. clone it locally to your computer, and checkout d3d9client (git checkout d3d9client)
Step 3. create a new branch

If you're using the visual studio git plugin you can create a new local branch like this.


you can also do this via command line with
git checkout -b atmo-remake

Step 4. make new commits to this branch. when you push them, either with VS, or "git push" a tracked branch will be added on GitHub
Step 5. when it's all done. you can make a pull request to orbitersim/d3d9client

 

[Face]

A branch in Git is just a pointer to a commit. Thus you can always create a new branch where ever you are. On the command-line, command to create a new branch at the checkout you are at, is "git checkout -b jarmonik/orbiter/atmo-remake".

 

[n72.75]

Stash is not something I use much. Doesn't work well with my workflow.

Here's a video on it though.

 

[jarmonik]

A branch in Git is just a pointer to a commit. Thus you can always create a new branch where ever you are. On the command-line, command to create a new branch at the checkout you are at, is "git checkout -b jarmonik/orbiter/atmo-remake".

Thanks, that did exactly what I needed. It was that easy after all.

 

[jarmonik]

I found my self in a trouble with the Git once more. I had to revert (undo) a merge of a bad pull request. I restored the branch "some_fixes" but it shows 3 commits behind, 0 ahead. When is should be 0 behind and about 10 ahead. So, I guess I need to re-base it somehow and I don't want to mess things up, so, what should be done ?

 

[jarmonik]

I haven't had any luck. Looks like it refuses to rebase the branch because it's merged already. Maybe it's easier to create a new branch and re-commit the code.

 

[Urwumpe]

I wish I could help you, but I fail to follow your actions there. You have a bad PR merge, reverted to the previous state and did you commit the reverted state then again?

 

[jarmonik]

Yes, the revert is merged.

This is the current layout:

X-Main-Main-X-Main-Main-X
 \         / \         /
   Feature      Revert   

I want the re-apply the Feature on a top of main and continue working on it
  
X-Main-Main-X-Main-Main-X
 \         / \         / \
   Feature     Revert      Feature

 

[n72.75]

I found my self in a trouble with the Git once more. I had to revert (undo) a merge of a bad pull request. I restored the branch "some_fixes" but it shows 3 commits behind, 0 ahead. When is should be 0 behind and about 10 ahead. So, I guess I need to re-base it somehow and I don't want to mess things up, so, what should be done ?

any time I do something where I could potentially lose work, I make a "back up" copy of the repository. If you do mess something up you can always "get push --force" from your backup" to restore the state you had on github.

keep in mind that "git revert" doesn't delete any commits, it makes a new commit undoing the changes made by a previous one. this preserve the commit history.

to undo a merge commit you need to use "git revert -m <parent number> <commit ID of Merge you're trying to revert>

parent number is pretty much always 1. double check that it undid what you want.

 

[jarmonik]

to undo a merge commit you need to use "git revert -m <parent number> <commit ID of Merge you're trying to revert>
parent number is pretty much always 1. double check that it undid what you want.

I tried that and it made it look even more messed up. But I'll try it again. Yes, I made a backup copy of the repository.

 

[n72.75]

I tried that and it made it look even more messed up. But I'll try it again. Yes, I made a backup copy of the repository.

I can try it myself too if you want.

 

[n72.75]

The first thing you need to do is get 'some_fixes' to be even with 'main'

If you checkout some_fixes, and rebase main onto it, it will make it even, since those 3 commits are already part of main's history, and all rebasing does is replay branch A onto branch B. You could also just create a new branch based on main. Either way you need something even with main to start with.

I found my self in a trouble with the Git once more. I had to revert (undo) a merge of a bad pull request. I restored the branch "some_fixes" but it shows 3 commits behind, 0 ahead. When is should be 0 behind and about 10 ahead. So, I guess I need to re-base it somehow and I don't want to mess things up, so, what should be done ?

Because your 'some_fixes' branch only had commits that merged, and commits that reverted, and because these were already in the history of main rebasing will just make 'some_fixes' be exactly the same as 'main'. because rebasing just "replays" the commits in the feature branch over the branch you're merging into

I think I misunderstood your question earlier. Hopefully I'm able to give better advice now.

Yes, the revert is merged.

This is the current layout:

X-Main-Main-X-Main-Main-X
 \         / \         /
   Feature      Revert 

I want the re-apply the Feature on a top of main and continue working on it
 
X-Main-Main-X-Main-Main-X
 \         / \         / \
   Feature     Revert      Feature

There are several ways you can approach this. And all of them are messy in one way or another

You can "revert a revert'



This is probably the best way to do it. Every thing else involves messing with branch history and is more prone to errors than its worth worrying about.

Those options would be something like:

• Cherry-picking the last good merge commit
• git reset to the last good commit (requires push --force, messes with history)
• interactive rebase (not git beginner friendly, messes with history)

I'm still willing to checkout, build, and test any branch that is ready for merging
According to git, I do a lot of reviews, so I must be good at it

 

[jarmonik]

Thanks for you help. I think I managed to get it sorted out. I created a new branch on a top of main and then used TortoiseGit to cherry-pick a range of commits from the "some_fixes".
Yeah, it would be good idea to do more extensive code testing before merge. I did plenty of testing and verification that everything is working properly. It worked perfectly and blow up on my face right after the merge. Still have to figure out why.