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

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

Re: GitHub migration procedure

#16 Post by adrian_broher » Sun Mar 29, 2015 9:26 am

Geoff the Medio wrote:You propose to delete the release branch, but then have a tag or link to a particular commit for a release. But if the release commit is on the release branch, which was deleted, how can you link to or refer to it, since the release commit (at least for v0.4.4) is not merged back to trunk, so only exists on the (deleted) branch?
You can list the existing tags in a repository and checking a particular tag like you would check out a branch.

In git there are the so called refs. Refs are symbolical names, which point to a git object. Depending on the kind of ref they point to different kind of git object.

Branches point to a commit. Git knows that you can manipulate branches by committing to a branch.
Tags point to also to a commit. A tag however is not intended to manipulated, it should just point to a commit in time.
Then we have the HEAD ref, this points to the commit, which is currently placed in the working directory. Most of the time this the checked out branch.
You also have remotes, which are references pointing to a branch / tag in a remote repository. Those are considered read only.

Every commit, that is reachable by a ref, will not be deleted from git. So when you have a branch and a tag pointing to a commit and delete the branch the commit and it's ancestors are still reachable by the tag and will not be deleted. If you delete the tag too however this history will become unreachable and will be deleted by the next garbage collection run by git.

Edit:
Vezzra wrote:AFAIK deleting a branch in git just deletes the "branch marker" pointing to the latest commit of the branch. This doesn't change anything about the commit history. The tag won't be affected by deleting the branch, and still point to the same commit as before.
Well, pretty much this. ;)
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: GitHub migration procedure

#17 Post by Vezzra » Sun Mar 29, 2015 9:42 am

Geoff the Medio wrote:But if the release commit is on the release branch, which was deleted, how can you link to or refer to it, since the release commit (at least for v0.4.4) is not merged back to trunk, so only exists on the (deleted) branch?
You obviously still have a concept of branches in mind that is specific to subversion. Git branches are different. When you create a branch in git, you essentially create nothing but a pointer. Upon creation, that pointer points to the same commit as the pointer of the base branch.

Example: We have a branch, master, with three commits, A, B and C. C was the latest commit, so the branch pointer "master" points to C. Now we decide to create a new branch "release". Our currently checked out branch is "master", from which we branch off, so the newly created branch pointer "release" also points to C. Normally with the creation of a branch you also check out that branch (which actually doesn't change anything in the working copy, as "master" and "release" are of course absolutely identical). This is very different from subversion: There creating a branch actually creates a copy of the base branch (even if it's not a deep copy, it's still a copy).

Then we do some coding, and commit these changes, creating commit D. As the currently checked out branch is "release", the branch pointer that gets moved to the new commit is "release". "Master" now still points to C, "release" to D. We could now check out "master", which would reset the working copy to commit C, do some edits and make another commit E. This will move the branch pointer "master" to E. "Release" will still point to D. We have now a diverging history: Up to commit C "master" and "release" are identical, from that point they differ: "Master" has A-B-C-E, "release" has A-B-C-D.

If we tag D and then delete "release", we can no longer check out "feature" as a branch and continue adding changes, but it is still possible to access commit D via the tag, as the commit itself and the tag pointing to it remain unaffected by the deletion of the branch pointer.

What happens when we don't have the tag and delete the branch is a good question, which Marcel just answered. I hope that makes things clearer...

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12393
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#18 Post by Geoff the Medio » Sun Mar 29, 2015 10:06 am

Vezzra wrote:If we tag D and then delete "release", we can no longer check out "feature" as a branch and continue adding changes, but it is still possible to access commit D via the tag, as the commit itself and the tag pointing to it remain unaffected by the deletion of the branch pointer.

What happens when we don't have the tag and delete the branch is a good question, which Marcel just answered. I hope that makes things clearer...
That part about tags yes, but the preceding discussion was not adding any new information to my understanding of git branches.

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

Re: GitHub migration procedure

#19 Post by adrian_broher » Sun Mar 29, 2015 10:50 am

Geoff the Medio wrote:That part about tags yes, but the preceding discussion was not adding any new information to my understanding of git branches.
In this case I'm still a bit lost. What do you mean by:
You propose to delete the release branch, but then have a tag or link to a particular commit for a release. But if the release commit is on the release branch, which was deleted, how can you link to or refer to it, since the release commit (at least for v0.4.4) is not merged back to trunk, so only exists on the (deleted) branch?
Are you talking about the time where you prepare and bugfix the release? Then you will need a branch. But after that you tag the commit which should be your release and delete the branch because you're not working anymore on the release.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12393
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#20 Post by Geoff the Medio » Sun Mar 29, 2015 11:05 am

I don't know what you're asking... Before discussing tags, Vezzra's post talked about how branches have separate pointers to their latest commits and a shared history up to the branch point. This was not new information. Then he started talking about tags and deleting in the part I quoted. That was helpful.

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

Re: GitHub migration procedure

#21 Post by Vezzra » Sun Mar 29, 2015 11:17 am

Geoff the Medio wrote:Before discussing tags, Vezzra's post talked about how branches have separate pointers to their latest commits and a shared history up to the branch point. This was not new information. Then he started talking about tags and deleting in the part I quoted. That was helpful.
Ah, I see. Well, from your question I got the impression that you still had difficulties understanding the difference between subversion and git branches, so I inserted that explanation as a preliminary, before I went on to tags and deleting branches. Obviously I misjudged, and the only thing you still had questions about was how it's possible to have a tag pointing to a commit of a branch that has been deleted.

The short answer being in that case: The tag keeps the commit history alive, and can be checked out. Of course you'll have to tag the commit before you delete the branch, otherwise all references to the commit are lost, and the commit becomes inaccessible.

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

Re: GitHub migration procedure

#22 Post by adrian_broher » Sun Mar 29, 2015 12:20 pm

Edit by Vezzra: This post is a reply to this one. Moved it here.
MatGB wrote:And now all you have to do is explain what us poor plebs have to do ;-)
Maybe this article can help you getting into the topic:
http://www.sitepoint.com/version-control-git/
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12393
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

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

#23 Post by Geoff the Medio » Sun Mar 29, 2015 2:37 pm

OK, what did I do wrong this time?

https://github.com/freeorion/freeorion/ ... -migration

I tried to rebase the logging-migration branch on the master, somehow got an extra (empty) merge commit, seeimingly for for a file I'd already resolved conflicts on, and now the branch says it is 7 commits ahead of master (?? I'd expect 3, or maybe 4 if the do-nothing merge commit is included), and the ordering of commits in the log is inconsistent with their times. Perhaps the merge commit is expected for a merge, but I tried to rebase...

Edit: maybe there's something weird with the importing of the branch? This revision graph doesn't make much sense to me...
Attachments
revision_graph.png
revision graph after... whatever I did
revision_graph.png (15.82 KiB) Viewed 873 times

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

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

#24 Post by Vezzra » Sun Mar 29, 2015 3:01 pm

Geoff the Medio wrote:I tried to rebase the logging-migration branch on the master
First of all, I have a commit message here that reads:

Code: Select all

Merge remote-tracking branch 'origin/logging-migration' into logging-migration
I don't know what you intended with that commit, but apparently you tried to merge the remote branch into the corresponding local one. I don't think that's a good idea, changes of the remote branch should be fetched or pulled into your local branch. But that's probably just the result of your attempt at rebasing.

Which brings me to the important point: This is exactly the scenario where you must not use rebase, as you've already pushed the logging-migration branch to a remote, shared repo. Rebasing is one of the git commands that rewrite commit history, and therefore must be avoided if that will change already published commits.

The problem e.g. for me now is, I see the commits "Replaced log4cpp with Boost.Log", "Removed log4cpp code." and "More log4cpp removal." twice, in master and in logging-migration.

The correct way for what you probably wanted to do (fetching changes committed to master into your branch) would have been merging master into logging-migration.

Of course we are now in need of fixing that. I'm not a veteran myself at these things, but I guess undoing the "Merge remote-tracking branch 'origin/logging-migration' into logging-migration" commit via a hard reset and force push should do the trick - Marcel?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12393
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

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

#25 Post by Geoff the Medio » Sun Mar 29, 2015 3:07 pm

Vezzra wrote:The problem e.g. for me now is, I see the commits "Replaced log4cpp with Boost.Log", "Removed log4cpp code." and "More log4cpp removal." twice, in master and in logging-migration.
??? Where do you see log4cpp releated commits in master? I only intended to and only can see modifications to the logging-migration branch, with none in master.
The correct way for what you probably wanted to do (fetching changes committed to master into your branch) would have been merging master into logging-migration.
That's what I tried to do. Or sort of... at least that's the direction it was supposed to go. I was modifying the logging-migration branch, not master, so if it committed (and pushed) things back to master, something even weirder happened.

I may just avoid using branches...

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

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

#26 Post by Vezzra » Sun Mar 29, 2015 3:18 pm

Geoff the Medio wrote:??? Where do you see log4cpp releated commits in master? I only intended to and only can see modifications to the logging-migration branch, with none in master.
Yep, sorry, my git gui client (SourceTree) displayed things a bit confusingly. To be precise, I see these commits now twice in the logging-migration branch. The "before rebase" and "after rebase" versions.
That's what I tried to do. Or sort of... at least that's the direction it was supposed to go. I was modifying the logging-migration branch, not master, so if it committed things back to master, something even weirder happened
No, you're right, nothing got into master. It's just the logging-migration branch that got messed up.

My solution should fix the branch (I hope to hear from Marcel soon, otherwise I've to try and trust my luck), but you will need to delete your local branch (that's the one without "origin" in its name) and pull in the remote logging-migration branch again, if I fix it. That should work AFAIK.

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

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

#27 Post by adrian_broher » Sun Mar 29, 2015 3:37 pm

Geoff, did you do a clean download of the repository after the migration was done?

As you can see here: https://github.com/freeorion/freeorion/ ... 65d9963842 the merge commit has two parents.
One is the commit you did https://github.com/freeorion/freeorion/ ... 6dff9243a0
The other one is the same commit, https://github.com/freeorion/freeorion/ ... f8bbecfc76 that I imported from the old repository. I removed the

Code: Select all

+      <AdditionalDependencies>Common.lib;Parsers.lib;log4cpp.lib;zdll.lib;%(AdditionalDependencies)</AdditionalDependencies>
Because it striked me odd that you would remove, according the log message, the log4cpp dependency when adding the log4cpp.lib library again.

* You had an outdated repository.
* You committed your version of the patch "More log4cpp removal."
* You pulled the updated repository version.
* When pulling git has seen, that both variants of "More log4cpp removal" are not equal and merged the branches.

How to prevent it the next time:
Don't pull from a repository, fetch instead and then decide if a merge or a rebase is the better way to update your branch.
OR do the equivalent of 'git pull --rebase' to tell git, that the pull should use a rebase instead of a merge as resolving strategy.
Vezzra wrote:Of course we are now in need of fixing that. I'm not a veteran myself at these things, but I guess undoing the "Merge remote-tracking branch 'origin/logging-migration' into logging-migration" commit via a hard reset and force push should do the trick - Marcel?
Yes, fetch the changes, checkout the logging-migration branch, hard reset it to the 'good' commit (take a look into gitk to decide which one that is) and force push the branch to the remote origin/logging-migration again. Geoff needs to fetch this remote branch and hard reset his local logging-migration branch to that remote branch.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12393
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

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

#28 Post by Geoff the Medio » Sun Mar 29, 2015 3:48 pm

adrian_broher wrote:Geoff, did you do a clean download of the repository after the migration was done?
Yes, into a new empty directory. Then I manually copied over all the dependency headers, libraries, dlls, etc, then did various modifications, commits, and syncs (using the GitHub for Windows Sync button), then switched to the logging-migration branch, and then attempted to bring that branch up to date with the master, which is when things got complicated.

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

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

#29 Post by Vezzra » Sun Mar 29, 2015 3:59 pm

adrian_broher wrote:* You had an outdated repository.
* You committed your version of the patch "More log4cpp removal."
* You pulled the updated repository version.
* When pulling git has seen, that both variants of "More log4cpp removal" are not equal and merged the branches.
Well, I thought that the problem was simply this:
Geoff the Medio wrote:I tried to rebase the logging-migration branch on the master
...that he tried to rebase a branch already pushed to origin onto master, instead of merging master into logging-migration?
Yes, fetch the changes, checkout the logging-migration branch, hard reset it to the 'good' commit (take a look into gitk to decide which one that is) and force push the branch to the remote origin/logging-migration again. Geoff needs to fetch this remote branch and hard reset his local logging-migration branch to that remote branch.
Done. The commit history looks fine again in my gui client. Geoff, can you delete your local logging-migration branch and pull it again from the repo (and, if you hadn't re-cloned it after Marcel uploaded the final version, you need to do before doing anything else).

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

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

#30 Post by Vezzra » Sun Mar 29, 2015 4:08 pm

Geoff the Medio wrote:I manually copied over all the dependency headers, libraries, dlls, etc, then did various modifications, commits, and syncs (using the GitHub for Windows Sync button), then switched to the logging-migration branch, and then attempted to bring that branch up to date with the master, which is when things got complicated.
Hm, sounds like you somehow told GitHub for Windows to do this sync via rebase instead of merge, which messed up things.

Anyway, I'm afraid you need to learn the git command line tools, there will be no way around that, even if you'll be using a gui client for everyday work. This GitHub application apparently obscures too much what's really going on, which leads to mistakes. Knowing the command line tools might help prevent these.

Post Reply