The Git/GitHub Questions, Answers and Howto Thread

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#166 Post by Vezzra »

Cjkjvfnby wrote:1) Where I can find what was commited before I rewrite history?
Dunno, AFAIK when you force push the rebased branch, the old one is lost. The only way to recover it is if another copy exists in a cloned repo. Which fortunately is the case here, I have a copy up to Mats commit "Hangar part cost balancing" (a4ec700).
2) Can someone who did not pull yet make reserve copy of Fighters branch?
I can restore the branch up to the commit mentioned above by force pushing my version, the three commits you added will be lost (of course, you can make a copy of the Fighters branch in its current state before I force push my version).

Ok?

P.S.: Oh, Mat beat me to it. Well, no problem, the more, the merrier :D

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#167 Post by LGM-Doyle »

@Cjkjvfnby,

Everything is probably still saved.

Try

git reflog

It should list a whole bunch of commits by their hash. git basically keeps all commits until they have been garbage collected. git reflog lists everything its still got.

You can checkout the commits by hash until you find the one before your mistake. Make that commit your new branch and try again.

git checkout <hash>
git branch -m <newname>

For more details see http://gitready.com/intermediate/2009/0 ... y-net.html

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#168 Post by Cjkjvfnby »

Vezzra wrote:
Cjkjvfnby wrote:1) Where I can find what was commited before I rewrite history?
Dunno, AFAIK when you force push the rebased branch, the old one is lost. The only way to recover it is if another copy exists in a cloned repo. Which fortunately is the case here, I have a copy up to Mats commit "Hangar part cost balancing" (a4ec700).
2) Can someone who did not pull yet make reserve copy of Fighters branch?
I can restore the branch up to the commit mentioned above by force pushing my version, the three commits you added will be lost (of course, you can make a copy of the Fighters branch in its current state before I force push my version).

Ok?

P.S.: Oh, Mat beat me to it. Well, no problem, the more, the merrier :D
Reseting, is good solution since only one my commit is real, other are fixes for rebase issues.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#169 Post by Vezzra »

Cjkjvfnby wrote:Reseting, is good solution since only one my commit is real, other are fixes for rebase issues.
Ok, done.

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#170 Post by Cjkjvfnby »

My workflow on rebase of the Fighters branch.
  • create copy of the Fighter branch with name old-fighters
  • create copy of merge-base for the Fighter branch with name old-master
  • rebase
  • make diff old-master old-fighters to file
  • make diff master Fighters to file
  • diff the diff to check if any rebase error occures*
  • push
* I use PyCharm `Compare with ...` dialog. It show two files in panels and highlight difference. Also it allow to edit files.
It helped me to find issue in my rebasing.
Last edited by Cjkjvfnby on Sun Jun 12, 2016 5:19 pm, edited 1 time in total.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#171 Post by Vezzra »

I don't think I understand how that' supposed to work, or what you try to achieve by that... I mean, when you rebase, you have to solve all the arising conflicts during the rebase process, otherwise you can't complete the rebase, can you? Meaning, once the rebase is complete, all conflicts must have been solved, so what is diffing old-fighters/merge-base (that is the commit where old-fighters branches off master, right?), rebased-fighters/master, then diffing the diffs supposed to do?

As far as I understand, you're first diff contains all the differences between the "unrebased" Fighters branch and master at the commit where "unrebased" Fighters branches off, and your second diff all the differences between the rebased Fighters branch and current master. Which, in both cases, means the diffs contain all the changes of all the commits of the Fighters branch, the first diff before and the second after the rebase.

Diffing those diffs will yield all the changes to the Fighters branch that the rebase introduced, which are effectively all the changes that happened in master since the last rebase of Fighters, plus the changes needed for conflict solving. Applying that diff to the rebased Fighters branch means to apply all those changes a second time, which I'd expect to create a big mess...?

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#172 Post by Cjkjvfnby »

Vezzra wrote:I mean, when you rebase, you have to solve all the arising conflicts during the rebase process, otherwise you can't complete the rebase, can you?
This helps me to find place where I solved conflict with error. Diff-diff helps me to find places there this can happen.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#173 Post by Vezzra »

Cjkjvfnby wrote:This helps me to find place where I solved conflict with error. Diff-diff helps me to find places there this can happen.
Ah, ok, so you actually don't apply that diff-diff, you just use it to find locations of conflict that might need additional fixing after rebase?

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#174 Post by Cjkjvfnby »

Vezzra wrote:
Cjkjvfnby wrote:This helps me to find place where I solved conflict with error. Diff-diff helps me to find places there this can happen.
Ah, ok, so you actually don't apply that diff-diff, you just use it to find locations of conflict that might need additional fixing after rebase?
Yes
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#175 Post by MatGB »

So, in a PR discussion Marcel explained some basics to Sloth and I said I'd fix the error made. However, doing this is somethign I've only recently learnt how to do properly so I thought I'd post the commands I used, partially as reference and partially for others (plus, someone might observe an improvement I could make to my taskflow).

Code: Select all

matgb@MatGB-Desktop:~/freeorion$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'master/master'.
matgb@MatGB-Desktop:~/freeorion$ git fetch master
remote: Counting objects: 105, done.
remote: Compressing objects: 100% (79/79), done.
remote: Total 105 (delta 60), reused 25 (delta 25), pack-reused 1
Receiving objects: 100% (105/105), 349.28 KiB | 677.00 KiB/s, done.
Resolving deltas: 100% (60/60), completed with 13 local objects.
From https://github.com/freeorion/freeorion
   1e8c148..cfd3060  master     -> master/master
matgb@MatGB-Desktop:~/freeorion$ git rebase
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/master/master.
matgb@MatGB-Desktop:~/freeorion$ git fetch sloth
remote: Counting objects: 122, done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 122 (delta 85), reused 75 (delta 75), pack-reused 24
Receiving objects: 100% (122/122), 164.37 KiB | 0 bytes/s, done.
Resolving deltas: 100% (89/89), completed with 38 local objects.
From https://github.com/deepsloth/freeorion
 * [new branch]      LEMBALALAM -> sloth/LEMBALALAM
 * [new branch]      Lembala    -> sloth/Lembala
 * [new branch]      asteroid_coating -> sloth/asteroid_coating
 * [new branch]      defense_network_icon -> sloth/defense_network_icon
 * [new branch]      field_descriptions -> sloth/field_descriptions
 * [new branch]      genetic_engineering_icon_fix -> sloth/genetic_engineering_icon_fix
 * [new branch]      ground_guardians -> sloth/ground_guardians
 * [new branch]      kraken_in_the_ice -> sloth/kraken_in_the_ice
 * [new branch]      natives_specials_tweak -> sloth/natives_specials_tweak
matgb@MatGB-Desktop:~/freeorion$ git cherry-pick abe72ef
[master 1259612] Added the new special: Kraken in the Ice.
 Author: Sloth <[email protected]>
 Date: Tue Aug 9 10:33:17 2016 +0200
 5 files changed, 105 insertions(+)
 create mode 100644 default/scripting/monster_designs/SM_WHITE_KRAKEN.focs.txt
 create mode 100644 default/scripting/ship_hulls/monster/SH_WHITE_KRAKEN_BODY.focs.txt
 create mode 100644 default/scripting/specials/KRAKEN_IN_THE_ICE.focs.txt
matgb@MatGB-Desktop:~/freeorion$ git cherry-pick a0265da
[master 12a2698] Fixed and tweaked the Kraken in the Ice special.
 Author: Sloth <[email protected]>                                                  
 Date: Thu Sep 29 20:07:06 2016 +0200                                                   
 3 files changed, 4 insertions(+), 3 deletions(-)                                       
matgb@MatGB-Desktop:~/freeorion$                                                        
                                       
Doing this requires having the person whose work you're cherry picking set as a remote in your Git setup, that's something I've done for most of our regular contributors, it also requires the use of the very powerful Rebase command.

NB: I massively prefer to learn to use the Command Line with Git as a) it's cross platform so I can do exactly the same thing on Windows as Linux and b) there's little chance of a GitGUI developer deciding to redo their interface entirely just after I've got used to it (as happened with gitg when I upgraded my Linux install, the new version is weird and hides how to cherry-pick so well I haven't found it yet).

The important lines above are

Code: Select all

git checkout master

git fetch master
Slight confusion here, I've made the mistake of both naming the FO Github repository as master and then we have the main branch called master, the first line makes sure I'm working in my master branch that always remains a direct copy of master, the second then grabs an updated version of master from the server

Code: Select all

git rebase
This updates my version of master, if there was any work there it would check for conflicts and make sure my work was listed as most recent ready to be pushed to master on the server.

Code: Select all

git fetch sloth
This grabs an updated version of Sloth's github profile with all the work he's made PRs from, it lists all branches and similar.

Code: Select all

git cherry-pick abe72ef
git cherry-pick a0265da
These two lines simply grab the commits I want from Sloth's work and put them into the branch I'm working on.

Then I simply push it to master directly, or if I wanted I could work on it then push, etc.

The more I learn about Git the more impressed I am, but I find you have to understand the logic of what it's doing and why in order to remember which commands do what, and it doesn't always use earth logic when doing so (plus, my old GUI cherry picked from a branch and you told it where to go, but the command line needs you to be in the destination branch and tell it what you want).
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#176 Post by Cjkjvfnby »

Code: Select all

git fetch --all --prune
syncs all repos

Code: Select all

http://stackoverflow.com/a/1994491
you can cherry-pick range of commits
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: The Git/GitHub Questions, Answers and Howto Thread

#177 Post by adrian_broher »

I massively prefer to learn to use the Command Line with Git […] b) there's little chance of a GitGUI developer deciding to redo their interface entirely just after I've got used to it.
In general I'm not a big fan of GUI applications, unless the task requires non-text interaction (games, graphics, 3d design and so on). What I experienced so far when being force to use a GUI interface for $TOOL is that some features are not exposed and most likely it's the feature I do like the most.
Slight confusion here, I've made the mistake of both naming the FO Github repository as master and then we have the main branch called master, the first line makes sure I'm working in my master branch that always remains a direct copy of master, the second then grabs an updated version of master from the server
If this annoys you you can use the git remote rename command to rename it:

Code: Select all

$ git remote
origin
upstream
$ git remote rename origin foo
$ git remote
foo
upstream
It will also change any internal reference to the renamed remote so no tracking branch is broken.

I personally prefer to use `upstream` as the authoritative source of a project (e.g. freeorion/freeorion) and `origin` for the fork that I own (e.g. adrianbroher/freeorion). The default convention is that `origin` is the remote you cloned from.
The more I learn about Git the more impressed I am, but I find you have to understand the logic of what it's doing and why in order to remember which commands do what, and it doesn't always use earth logic when doing so (plus, my old GUI cherry picked from a branch and you told it where to go, but the command line needs you to be in the destination branch and tell it what you want).
I can understand that the sheer mass of possible operations is overwhelming but I never felt like that git itself is not logical in its workflow or the command line syntax. Care to elaborate?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: The Git/GitHub Questions, Answers and Howto Thread

#178 Post by adrian_broher »

Cjkjvfnby wrote:

Code: Select all

git fetch --all --prune
syncs all repos
--all syncs all repos.
--prune clears dangling remote branches. That means when the remote repository had a foo branch and it was deleted it will be deleted locally on you repo too. This of course doesn't apply for local branches that were checked our from remote branches.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#179 Post by MatGB »

adrian_broher wrote: In general I'm not a big fan of GUI applications, unless the task requires non-text interaction (games, graphics, 3d design and so on). What I experienced so far when being force to use a GUI interface for $TOOL is that some features are not exposed and most likely it's the feature I do like the most.
I'm getting to that stage, my big problem is my memory isn't what it was and I have little post its with common commands else I forget what I need to do next.
Slight confusion here, I've made the mistake of both naming the FO Github repository as master and then we have the main branch called master, the first line makes sure I'm working in my master branch that always remains a direct copy of master, the second then grabs an updated version of master from the server
If this annoys you you can use the git remote rename command to rename it:
To be honest I'm so used to it I think if I renamed one of them I'd get even more confused, but thanks ;-)

I personally prefer to use `upstream` as the authoritative source of a project (e.g. freeorion/freeorion) and `origin` for the fork that I own (e.g. adrianbroher/freeorion). The default convention is that `origin` is the remote you cloned from.
Makes sense, except because I'm mostly checking script work by others these days, or making small tweaks, I'm virtually always working with master, my remote is just something I maintain on the rare occasions I need to make a PR, which happens so rarely it's virtually never up to date.
The more I learn about Git the more impressed I am, but I find you have to understand the logic of what it's doing and why in order to remember which commands do what, and it doesn't always use earth logic when doing so (plus, my old GUI cherry picked from a branch and you told it where to go, but the command line needs you to be in the destination branch and tell it what you want).
I can understand that the sheer mass of possible operations is overwhelming but I never felt like that git itself is not logical in its workflow or the command line syntax. Care to elaborate?
Well, apart from the cherry picking confusion caused by GUIs setup to do it the other way, one of the things I always get confused by (although I think I've now got it sorter) is reversion/resetting already committed stuff. The other day I recompiled and it was just after the AI team had pushed an incomplete thing to master, so the game was unplayable, they fixed it within a few hours but in the meantime I needed to remove their commit, which was inbetween some of my stuff.

All I wanted to do was remove a single commit from my branch, but I ended up creating a new branch from before their merge and cherry picking in the stuff I wanted that was more recent: I didn't want a revert commit undoing their stuff in my history, I simply didn't want that one thing in my history: I understand the logic of recording everything, but the idea that sometimes you just want to get rid of something you didn't want, especially something done by someone else you were testing, seems to me logical, and revert commits create too much clutter. I've since learnt I could've rest and then cherry picked, the new branch wasn't needed, but even that was an annoying extra step—the lack of a simple "tell this commit to begone" thing is something that annoys me.

That and the whole merge-from-master problem we've encountered several times, rebasing as default would make the most sense but it's not, it appears, standard practice, and being able to simply update my repo from master should be easier to do (and, more importantly, teach).
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

Morlic
AI Contributor
Posts: 296
Joined: Tue Feb 17, 2015 11:54 am

Re: The Git/GitHub Questions, Answers and Howto Thread

#180 Post by Morlic »

MatGB wrote: All I wanted to do was remove a single commit from my branch.
I use

Code: Select all

rebase -i
for that. Drop the commit and pick everything else...
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply