The Git/GitHub Questions, Answers and Howto Thread

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

Moderators: Committer, Committer

Post Reply
Message
Author
User avatar
Cjkjvfnby
AI Contributor
Posts: 465
Joined: Tue Jun 24, 2014 9:55 pm

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

#61 Post by Cjkjvfnby » Mon Apr 13, 2015 10:44 am

Get merged branches:

Console (local and on server):

Code: Select all

git branch --merged master -a
Github (server only)
open https://github.com/freeorion/freeorion/branches
check that number of commits ahead master is 0 in second column:

Code: Select all

(2|0)  # behind|ahead
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

#62 Post by MatGB » Mon Apr 20, 2015 4:28 pm

Ye gods some elements of the UI are a royal pain.

In Git GUI for Windows, there's no built in Pull function (that I can see anyway), but you can "Add" one under tools, but if you don't do it 100% correctly it'll just fail on you and not tell you why. But it appears once you have added it you can keep it there permanently, which is good. Given the main use of a repo for a lot of contributors is to hack around with the current version in trunk (or whatever it's now called), that's a really weird UI choice.

I've got it working now and it works fine. I appear to have managed to author some changes, commit them at my end, push them to my fork on Github then pull them into the main repo. It insists on adding a commit for every time I've updated my fork from master back into master, which I find mind bogglingly stupid, but I can't see how to remove that.

Still, I think I'm almost at the stage where I feel confident in writing a "guide to new contributors" thing. Almost. I think I'll need some more coffee before I get started though, and probably kill off some more species (testing some changes using Trith, kill off all the nasties...)
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
Dilvish
AI Lead, Programmer
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

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

#63 Post by Dilvish » Mon Apr 20, 2015 4:49 pm

MatGB wrote:In Git GUI for Windows, there's no built in Pull function (that I can see anyway), but you can "Add" one under tools... It insists on adding a commit for every time I've updated my fork from master back into master, which I find mind bogglingly stupid, but I can't see how to remove that.
Rather than a plain pull (causeing a merge), for updating your master like this you want the command to be "git pull --rebase" (I think that alternatively there might be a way to have it prefer a "fast-forward merge" which in this case shouldn't case an extra merge commit, but I'm not so sure how to set that up. You should be able to add "git pull --rebase" the same way you added the pull command, or apparently it can be added by editing your .gitconfig file
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

#64 Post by MatGB » Mon Apr 20, 2015 4:56 pm

Ah, for some reason I thought that was basically resetting my repo to trunk, and not keeping my changes, appears otherwise, OK, I can add that in as well.
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
Dilvish
AI Lead, Programmer
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

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

#65 Post by Dilvish » Mon Apr 20, 2015 5:15 pm

Geoff, one of your recent substantive commits came in designated as if it was purely a merge, without a standard commit message (at least that's how it looks to me). I'm not even sure how that can happen. Am I reading this wrong?

Edit: on a related note, it would be nice if you could do your updates from master as a rebase like I pointed out to Matt above, so we could avoid having most of these merge commits other than for pull requests.
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

#66 Post by MatGB » Mon Apr 20, 2015 5:23 pm

That one confused me because it's basically all the stuff I'd committed in my previous two merges, I think it was meant to be Geoff merging them into his fork but went wrong somehow as my stuff was definitely already in Trunk.
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: 286
Joined: Tue Feb 17, 2015 11:54 am

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

#67 Post by Morlic » Thu Apr 23, 2015 5:59 pm

So what is our procedure with pull requests that need some update / additional commits?

For commit history reasons, we already said it makes sense to squash the commits into a single on. However, this procedure kills the line comments. So I suppose I will simply add new commits and only once everything is discussed and the content is accept-worthy, I squash the commits. After this, we then can merge.

Is this correct or is there a more prefered way?
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
Geoff the Medio
Programming, Design, Admin
Posts: 12496
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

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

#68 Post by Geoff the Medio » Thu Apr 23, 2015 9:27 pm

Dilvish wrote:Geoff, one of your recent substantive commits came in designated as if it was purely a merge, without a standard commit message (at least that's how it looks to me). I'm not even sure how that can happen. Am I reading this wrong?

Edit: on a related note, it would be nice if you could do your updates from master as a rebase like I pointed out to Matt above, so we could avoid having most of these merge commits other than for pull requests.
The first paragraph is probably the result of my trying to do something along the lines of the second. Git doesn't seem to like doing merging or similar actions as readily as SVN did, so I sometimes have to resort to manually editing / deleting / restoring files to get it to update, along with picking commits or resetting to particular commits, or possibly saving a few (local) commits as patches and then re-applying them after updating. If I included someone else's commit amongst those patches by accident, perhaps this would happen...?

User avatar
Dilvish
AI Lead, Programmer
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

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

#69 Post by Dilvish » Thu Apr 23, 2015 10:44 pm

Geoff the Medio wrote:or possibly saving a few (local) commits as patches and then re-applying them after updating.
If you have changes that have not been committed, then yes some save process is generally necessary before a pull/update, but your software should make it easy to save these into a 'stash', which is a bit like a temporary commit, but should be really simple to save and reload.
Git doesn't seem to like doing merging or similar actions as readily as SVN did, so I sometimes have to resort to manually editing / deleting / restoring files to get it to update, along with picking commits or resetting to particular commits
Unlike the commit or stash process I mention above, these steps do sound pretty ugly to have to go through, and prone to errors. Particularly if you are using GitHub's GitGUI offering then I will blame your GUI, I've heard it's quite mediocre. Now that I have learned git a bit more and have a nice GUI for it, I find it much better than SVN in pretty much every way I can think of (maintaining the fork is still a minor nuisance, but if I had tried to do the same with SVN it probably would be even worse). I very highly recommend smartgit: http://www.syntevo.com/smartgit/ it makes this whole process much much easier. To save temporary code in a stash it's a menu command Local->Save, and then it can be selected and reapplied with a right-click. It integrates with github and you can make or fetch pull requests with it. The visual log display it makes is really great for seeing where the commits of a pull request or some private branch you're working on fit in with the sequence of commits on master, and it makes it really easy to review the substance of a commit too. I'm sure there are other good GUI's as well.
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
Geoff the Medio
Programming, Design, Admin
Posts: 12496
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

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

#70 Post by Geoff the Medio » Fri Apr 24, 2015 5:58 am

Dilvish wrote:...if you are using GitHub's GitGUI offering...
The process described above is too complicated for the GitHub for Windows interface. Generally with that, if I click the sync button, it just pops up a failure message, and I have to go back to various TortoiseGit stuff and/or command line reset actions.
...smartgit...
TortoiseGit can do all you describe as well. Only thing I haven't figured out with it is how to reset easily.

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

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

#71 Post by MatGB » Fri Apr 24, 2015 6:13 am

With GitGUI, I've set up two extra 'tools' that do basically what I need, Pull is basically the equivalent of SVN Update, and Rebase is a more advanced version that merges all my messing around, but that will only work if you've no unstaged changes, so less useful if you're working on something and want to grab recent stuff.

Theoretically there's a config file somewhere I can copy but I can't find it, setting up pull was easy, just setting the command as git pull {repo address}, rebase needed a bit more, I think putting --rebase before the repo name.
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
Geoff the Medio
Programming, Design, Admin
Posts: 12496
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

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

#72 Post by Geoff the Medio » Fri Apr 24, 2015 6:19 am

MatGB wrote:...that will only work if you've no unstaged changes, so less useful if you're working on something and want to grab recent stuff.
That's my main annoyance with git presently. If local modifications aren't ready to make a commit of yet, I can't easily update from the main repository. This seems to be the case even if the locally modified files aren't modified in the remote changes.

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

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

#73 Post by adrian_broher » Fri Apr 24, 2015 7:21 am

MatGB wrote:but that will only work if you've no unstaged changes, so less useful if you're working on something and want to grab recent stuff.
Geoff the Medio wrote:If local modifications aren't ready to make a commit of yet, I can't easily update from the main repository.
You both have a mental blockade here. There is no such thing as 'modifications not ready for a commit'. Also there is no such thing as 'you need recent stuff'.

1. You can commit every time you want and you should commit often.
2. If your commits are not 'nice' enough for publishing you do an interactive rebase and beautify them up before publishing (pushing) them to the public.
3. If you NEED updates from upstream you fetch them and rebase your local branches. If you just WANT them show a little bit of self discipline.

As Dilvish said you can throw in the stash function here somewhere, but I never saw the need for that.


1. My working branches often look like:

* <my-feature> Make the whole change set compile
* Doc typo on another thing
* Fixup another thing on platform 2
* Fixup third thing on platform
* Fixup one thing on platform
* Do a third thing
* Fixup one thing
* Do another thing
* Do one thing
* <upstream/master> <master> old upstream commit I don't care about

2. When I'm happy with the whole changeset I do an interactive rebase, squashing the additional commits and split commit, that shouldn't be one:

* <my-feature> Make the third thing compile
* Make the another thing compile
* Make the one thing compile
* Do a third thing + (Fixup third thing on platform)
* Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing)
* Do one thing + (Fixup one thing) + (Fixup one thing on platform)
* <upstream/master> <master> old upstream commit I don't care about

3. After that I do another interactive rebase to squash the split up commits:

* <my-feature> Do a third thing + (Fixup third thing on platform) + (Make the third thing compile)
* Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing) + (Make the another thing compile)
* Do one thing + (Fixup one thing) + (Fixup one thing on platform) + (Make the one thing compile)
* <upstream/master> <master> old upstream commit I don't care about

4. Lets have a look what changed:

* <upstream/master> A new commit
* Another new commit, conflicting with 'Do another thing'
| * <my-feature> Do a third thing + (Fixup third thing on platform) + (Make the third thing compile)
| * Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing) + (Make the another thing compile)
| * Do one thing + (Fixup one thing) + (Fixup one thing on platform) + (Make the one thing compile)
|/
* <master> old upstream commit I don't care about

5. Checkout master and rebase master

* <upstream/master> <master> A new commit
* Another new commit, conflicting with 'Do another thing'
| * <my-feature> Do a third thing + (Fixup third thing on platform) + (Make the third thing compile)
| * Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing) + (Make the another thing compile)
| * Do one thing + (Fixup one thing) + (Fixup one thing on platform) + (Make the one thing compile)
|/
* old upstream commit I don't care about

6. Checkout my-feature and rebase. It will notify you of the conflict and it's up to you how to fix it (you did the change after all).

* <my-feature> Do a third thing + (Fixup third thing on platform) + (Make the third thing compile)
* Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing) + (Make the another thing compile) + (resolved conflict)
* Do one thing + (Fixup one thing) + (Fixup one thing on platform) + (Make the one thing compile)
* <upstream/master> <master> A new commit
* Another new commit, conflicting with 'Do another thing'
* old upstream commit I don't care about

7. Checkout master and reset hard to my-feature

* <my-feature> <master> Do a third thing + (Fixup third thing on platform) + (Make the third thing compile)
* Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing) + (Make the another thing compile) + (resolved conflict)
* Do one thing + (Fixup one thing) + (Fixup one thing on platform) + (Make the one thing compile)
* <upstream/master> A new commit
* Another new commit, conflicting with 'Do another thing'
* old upstream commit I don't care about

8. push master to upstream

* <upstream/master> <my-feature> <master> Do a third thing + (Fixup third thing on platform) + (Make the third thing compile)
* Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing) + (Make the another thing compile) + (resolved conflict)
* Do one thing + (Fixup one thing) + (Fixup one thing on platform) + (Make the one thing compile)
* A new commit
* Another new commit, conflicting with 'Do another thing'
* old upstream commit I don't care about

9. Delete my-feature branch

* <upstream/master> <master> Do a third thing + (Fixup third thing on platform) + (Make the third thing compile)
* Do another thing + (Fixup another thing on platform 2) + (Doc typo on another thing) + (Make the another thing compile) + (resolved conflict)
* Do one thing + (Fixup one thing) + (Fixup one thing on platform) + (Make the one thing compile)
* A new commit
* Another new commit, conflicting with 'Do another thing'
* old upstream commit I don't care about
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

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

#74 Post by Cjkjvfnby » Fri Apr 24, 2015 7:36 am

adrian_broher wrote:
MatGB wrote:but that will only work if you've no unstaged changes, so less useful if you're working on something and want to grab recent stuff.
Geoff the Medio wrote:If local modifications aren't ready to make a commit of yet, I can't easily update from the main repository.
You both have a mental blockade here.
It is SVN style.

You way is impossible for GUI users.

Making good history take too much time and does not improve process.
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: 1086
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

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

#75 Post by adrian_broher » Fri Apr 24, 2015 7:40 am

Cjkjvfnby wrote:Making good history take too much time and does not improve process.
It makes reviews easier for me.
So no reviews for you anymore. >:(

It makes bisecting easier/possible.
It makes looking up the history easier/possible.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

Post Reply