Page 12 of 15

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

Posted: Sun Jun 05, 2016 7:52 pm
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

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

Posted: Sun Jun 05, 2016 8:52 pm
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

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

Posted: Sun Jun 05, 2016 11:00 pm
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.

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

Posted: Mon Jun 06, 2016 8:07 am
by Vezzra
Cjkjvfnby wrote:Reseting, is good solution since only one my commit is real, other are fixes for rebase issues.
Ok, done.

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

Posted: Sun Jun 12, 2016 11:38 am
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.

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

Posted: Sun Jun 12, 2016 12:45 pm
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...?

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

Posted: Sun Jun 12, 2016 3:09 pm
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.

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

Posted: Sun Jun 12, 2016 3:30 pm
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?

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

Posted: Sun Jun 12, 2016 5:20 pm
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

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

Posted: Thu Sep 29, 2016 9:01 pm
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

[email protected]:~/freeorion$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'master/master'.
[email protected]:~/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
[email protected]:~/freeorion$ git rebase
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/master/master.
[email protected]:~/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
[email protected]:~/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
[email protected]:~/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(-)                                       
[email protected]:~/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).

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

Posted: Thu Sep 29, 2016 9:51 pm
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

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

Posted: Fri Sep 30, 2016 7:32 am
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?

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

Posted: Fri Sep 30, 2016 7:37 am
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.

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

Posted: Fri Sep 30, 2016 11:33 pm
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).

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

Posted: Sat Oct 01, 2016 12:14 am
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...