FreeOrion

Forums for the FreeOrion project
It is currently Tue Oct 24, 2017 12:30 am

All times are UTC




Post new topic Reply to topic  [ 188 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13  Next
Author Message
PostPosted: Sun Jun 05, 2016 7:52 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4228
Location: Sol III
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).
Quote:
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


Top
 Profile  
 
PostPosted: Sun Jun 05, 2016 8:52 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 195
@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/02/09/reflog-your-safety-net.html


Top
 Profile  
 
PostPosted: Sun Jun 05, 2016 11:00 pm 
Offline
AI Contributor
User avatar

Joined: Tue Jun 24, 2014 9:55 pm
Posts: 444
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).
Quote:
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


Top
 Profile  
 
PostPosted: Mon Jun 06, 2016 8:07 am 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4228
Location: Sol III
Cjkjvfnby wrote:
Reseting, is good solution since only one my commit is real, other are fixes for rebase issues.
Ok, done.


Top
 Profile  
 
PostPosted: Sun Jun 12, 2016 11:38 am 
Offline
AI Contributor
User avatar

Joined: Tue Jun 24, 2014 9:55 pm
Posts: 444
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.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Last edited by Cjkjvfnby on Sun Jun 12, 2016 5:19 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Jun 12, 2016 12:45 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4228
Location: Sol III
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...?


Top
 Profile  
 
PostPosted: Sun Jun 12, 2016 3:09 pm 
Offline
AI Contributor
User avatar

Joined: Tue Jun 24, 2014 9:55 pm
Posts: 444
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


Top
 Profile  
 
PostPosted: Sun Jun 12, 2016 3:30 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4228
Location: Sol III
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?


Top
 Profile  
 
PostPosted: Sun Jun 12, 2016 5:20 pm 
Offline
AI Contributor
User avatar

Joined: Tue Jun 24, 2014 9:55 pm
Posts: 444
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


Top
 Profile  
 
PostPosted: Thu Sep 29, 2016 9:01 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3248
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:
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 <oliver.mecking@web.de>
 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 <oliver.mecking@web.de>                                                 
 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:
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:
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:
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:
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.


Top
 Profile  
 
PostPosted: Thu Sep 29, 2016 9:51 pm 
Offline
AI Contributor
User avatar

Joined: Tue Jun 24, 2014 9:55 pm
Posts: 444
Code:
git fetch --all --prune
syncs all repos
Code:
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


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 7:32 am 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
Quote:
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.

Quote:
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:
$ 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.

Quote:
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


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 7:37 am 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
Cjkjvfnby wrote:
Code:
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


Top
 Profile  
 
PostPosted: Fri Sep 30, 2016 11:33 pm 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3248
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.
Quote:
Quote:
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 ;-)
Quote:

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.
Quote:
Quote:
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.


Top
 Profile  
 
PostPosted: Sat Oct 01, 2016 12:14 am 
Offline
AI Contributor

Joined: Tue Feb 17, 2015 11:54 am
Posts: 224
MatGB wrote:
All I wanted to do was remove a single commit from my branch.


I use
Code:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 188 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group