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

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

#46 Post by Vezzra »

Dilvish wrote:The somewhat confusing situation Geoff related above seems to me to emphasize that even for us with commit writes to the main repository, it would be best to do most of our work via branches on our own forks, so on our local machines our individual github fork would be (normally) the 'origin' remote, and the main freeorion repository would be the 'upstream' remote. It seems to me that helps keep things organized and clean.
I think that depends on the purposes for doing a specific work via a branch. If it's something you intend to put up for peer review via pull request, then this approach sounds very reasonable. That would be the kind of changes/additions where, in the past, we would have made patches that we posted on the forum for testing/review purposes.

But I wouldn't use it otherwise. We didn't post patches for all things we committed, there were a lot of things we worked on in our local working copies we just committed when we thought them ready, for those we now would create local branches that we merge into our local master before pushing the changes.

And bigger projects like the SDL migration, revised colonization mechanics etc. where there might be several devs committing contributions can't be done with a branch in a "personal" fork anyway (unless you want to grant others push access to your personal fork, then you can do it, but I'd still fail to see the advantage of doing so in that specific scenario).
It seems that one of the big benefits of going our individual work in feature branches that are either just on our local machines or (more commonly) also on our personal forks at GitHub, is that rebasing can be used to clean up the commit history before it gets pulled/merged/pushed to freeorion/freeorion, such as is described in this article.
Well, from what I've read the opinions on the merging vs rebase topic seem to differ, with preferences for the one or the other being subject to personal taste, at least to some degree.

Personally I agree with you, when rebasing is possible (that is, without screwing work others might have based on already published commit history), then it's preferable because it produces a more linear (less maze-like) history. So, with local only branches and branches you only pushed to your personal fork for pull requests, that sounds like a good approach. However, when it comes to squashing commits:
I think it's important to note that this approach should be used only within a certain (uh, which is the right word here?) context, or maybe conditions. Because I've also read recommendations to keep git commits "atomic", and not squeeze too many or unrelated changes into one commit. It makes isolating a "bad" (bug introducing) change easier (git bisect), ditto cherry-picking. As far as I understood, more but smaller commits are generally preferable to fewer but larger ones - as long as you don't go overboard of course.

By that I don't want to argue that there aren't cases where squashing commits makes sense. The example you quote is one of those cases where it obviously does. So, squashing commits is a good recommendation, as long as people take care not to go overboard with it. I wouldn't want someone to get the impression that it might be a good idea to squash all the commits he did on his local branch into a single huge one before merging into master. That's definitely not the idea. ;)

Now, all that said, regarding using rebase on branches we put up for pull requests, I wonder if that makes any sense at all. Because, IIRC, and from what I've observed so far, it seems that merging a pull request via the github web interface always produces a merge with fast forward explicitely turned off. In that case a prior rebase is de facto pointless if I understood the whole mechanic correctly. What rebasing does is effectively changing the commit all the commits of your branch are based upon/derived from to the most recent commit of the branch you rebase onto. So that, when you do the subsequent merge, a fast foward merge can be done, resulting in a linear history that looks as if there has never been a branch.

If the subsequent merge command suppresses the fast forward feature, this "flattening" of commit history does not happen, so what would be the point of rebasing prior to the merge? So, in order to get the linear history we aim for, we would have to merge pull request manually instead of using the github web interface.

Did I understand that correctly, or am I missing something obvious? Marcel?

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

Re: GitHub migration procedure

#47 Post by Vezzra »

MatGB wrote:both have received comments and tags from others (Vezzra and adrianbroher) without being merged.

Why tag them and not merge them?
Putting a tag on it just requires a click and is quickly done, merging shouldn't be done before you do at least some basic review, for which (as Marcel already mentioned too) I didn't have the time.
Conversely, when I merge stuff in, how should I tag it or should that be left to someone else regardless?
That actually raises the question what our basic policy should be with regard to tags, milestones, and assignees.

My suggestions so far:

* Re tags: I don't know if the creator of a pull request can set tags on it, even if he does not have write access to the repo. But if, I'd suggest that the creator of the pull request sets the appropriate tags. If only devs with write access can set tags, they of course need to do that. As Marcel already pointed out, the tags help us to categorize the pull requests.

* Re assignees: IMO that should be set by the dev who decides he wants to take care of the PR, that is, takes responsibility that the PR gets properly reviewed, tested, corrected if necessary (whatever applicable in case of the PR in question of course), and finally merged (or rejected). That's a good feature to divide up the work and avoid having several devs working on the same PR independently. That of course means that if you start working on a PR, please tell that the others by assigning yourself to the PR.

* Re milestones: That's something I'd like to hear the input of my fellow devs. Marcel has created the milestone "Next release" and began assigning PRs to it, which looks like a good idea. I suggest to start a bit of brainstorming here what we should do with the milestone feature, what policies/procedures we want to follow. Ideas?

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

Re: GitHub migration procedure

#48 Post by Cjkjvfnby »

Vezzra wrote: * Re tags: I don't know if the creator of a pull request can set tags on it, even if he does not have write access to the repo. But if, I'd suggest that the creator of the pull request sets the appropriate tags. If only devs with write access can set tags, they of course need to do that. As Marcel already pointed out, the tags help us to categorize the pull requests.
I can see tags, milestones and assignments but can't change.
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
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: GitHub migration procedure

#49 Post by Dilvish »

Cjkjvfnby wrote:I can see tags, milestones and assignments but can't change.
For Pull Requests submitted by someone who doesn't theirself have write access, please add a first comment suggesting what tags/milestones/assignments you think most suitable. (I know you've been doing that at least some, Cj, but I want to put out a clear encouragement to everyone in your situation.)

@Vezzra regarding forks. Yes, as I learn more it seems that nearly all the benefits I was focused on can really be handled (and in fact principally must be handled) via local branches, whether or not those local branches wind up being pushed to a personal GitHub fork of FO. Given how much emphasis GitHub seems to place on making forks, and making pull requests from them, it seems remarkable to me (in a negative way) how cumbersome it is to keep one's fork in sync with the main upstream repo. GitHub itself apparently has no web interface way to do this (leaving me flabbergasted), and instead suggests a longish series of pulls, merges and pushes done at the command line with one's local repo as the intermediary between the 'upstream' main repo and one's github fork repo. I am largely using the SmartGit gui, which makes this process easier (and certainly makes it much easier to view logs/commit structure/current repo status and whatnot and seems invaluable for keeping my local repo reliably properly structured), but it is still a bit of a nuisance and seems potentially more error prone than it should be. All my key work seems to be handled between my local forks and the upstream main repo; pushing to my fork has so far just been an extra bookkeeping step to keep it up to date.

I think I may push out out or more branches for 'experimental' features to my fork though, for compilation-capable folks to try out. A key one of those is the 'range circle' feature which I previously posted a patch for on our forums. I have since then improved it and really like it quite a bit, but it got enough pushback from Geoff and Eleazar that I haven't been in the mood to try evangelizing it again, but I will probably put it up to share it. It seems like one big gap that git currently has is the limited ability to provide a description to go with a branch-- you are mostly just stuck with the branch name tradeoff between descriptiveness versus length/cumbersomeness. There is apparently an ability to add a branch description, but it just stays in your local config and does not get pushed along with the branch. I may open up a pull request in my own fork just to provide a way to give a description. :lol: I guess that will have the added benefit of providing a more prominent place to discuss the feature with anyone interested, as well. Am I missing something significant on this branch-description issue?
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: GitHub migration procedure

#50 Post by MatGB »

Dilvish wrote:Given how much emphasis GitHub seems to place on making forks, and making pull requests from them, it seems remarkable to me (in a negative way) how cumbersome it is to keep one's fork in sync with the main upstream repo. GitHub itself apparently has no web interface way to do this (leaving me flabbergasted), and instead suggests a longish series of pulls, merges and pushes done at the command line with one's local repo as the intermediary between the 'upstream' main repo and one's github fork repo. I am largely using the SmartGit gui, which makes this process easier (and certainly makes it much easier to view logs/commit structure/current repo status and whatnot and seems invaluable for keeping my local repo reliably properly structured), but it is still a bit of a nuisance and seems potentially more error prone than it should be. All my key work seems to be handled between my local forks and the upstream main repo; pushing to my fork has so far just been an extra bookkeeping step to keep it up to date.
Ye gods that looks like work, guess there are disadvantages of a more powerful tool, the very simply right click/update from SVN method I've gotten used to isn't there are all, no wonder I was getting confused trying to figure out how to do it.
I think I may push out out or more branches for 'experimental' features to my fork though, for compilation-capable folks to try out. A key one of those is the 'range circle' feature which I previously posted a patch for on our forums. I have since then improved it and really like it quite a bit, but it got enough pushback from Geoff and Eleazar that I haven't been in the mood to try evangelizing it again
I always liked that idea, the barebones you first published was a bit crude IIRC, but it was a long time ago—I've currently got three Collective Thought Networks built as I have fleets chase down Space Clouds just to guarantee they're working, knowing where the cutoff is for stuff like that, travel times and speed bonuses would be very useful.

This reminds me that I need to learn how to compile now I've access to a machine capable.

I've been thinking similarly for a few longer term projects I want to work on, sorting out, fro example, Stealth As A Strategy is going to take a lot more effort than simply redoing all the planetary stealth numbers and tweaking the detection techs, almost certainly worth creating a branch just for that and asking others to contribute ideas. Same applies to, for example, sorting out the population/production bonuses balance issue (it'd be especially useful for working through the Infrastructure based ideas I had, a lot of pushback on them but with work it'd be doable and if it's somethign people can try/give feedback on that'd be good).
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: GitHub migration procedure

#51 Post by Cjkjvfnby »

Dilvish wrote: GitHub itself apparently has no web interface way to do this (leaving me flabbergasted), and instead suggests a longish series of pulls, merges and pushes done at the command line with one's local repo as the intermediary between the 'upstream' main repo and one's github fork repo.
I do it in 2 click in my IDE.
git allow to create aliases http://stackoverflow.com/questions/7534 ... parameters.

I push my local master to github fork only if I want to see changes in github interface.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

jcantero
Krill Swarm
Posts: 12
Joined: Sun Nov 24, 2013 5:08 pm

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

#52 Post by jcantero »

There is a clear advantage in doing the merges in the local repository and then push them to the github repo: ability to rollback if things go really wrong. Also ability to revert, and do other things that you don't want to do in a published repo. So your local repo acts as a intermediate buffer to catch mistakes, and you only push to the remote repo when you are positively sure that all is OK. This feature IMHO is specially useful if you are a commiter to the official repo, that needs extra care of. Sure you need more steps, but I think it's worth it.

The model of github with your double (local and remote) repository seems a bit strange at first, but you can think of it in this way: if you had a computer permanently connected to the Internet, you wouldn't need a second repository. Instead, you let others access to your entire repository (even via web with cgit) or only to certain parts of it (there is a whole section of configuration for this that almost nobody uses). But since most of us don't have our computer permanently connected to the Internet with a static IP and domain, what we need is that somebody hosts a mirror of our repo. And that is what services like GitHub and others provide.

Image

So think of your repositories on github as a mere mirror of the content of your local repo, but restricted to the view that you want to show of it to the outside world (in the above image it's called "developer public"). Your work is always in your local repository, and you only "export" (push) when you want to share with others that work (and only the branches you want to share, not everything). Note that the arrow is from "developer private" to "developer public" (push), not the other way (there is not pulls). The pulls are got from the "blessed repository" (freeorion/freeorion here). Note also that "integration manager(s)" repo(s) (the commiters that have rights to push to the blessed repository) don't communicate directly with the private repos of other developers (they are usually behind a NAT with a random dynamic IP, during short periods of time) so they must rely on the public repos hosted by GitHub (or whichever) to fetch the changes proposed by the developers through their published branches and merge them. That's the arrow from "developer public" to "integration manager". If there is only a "integration manager", he/she only need to push to the "blessed repository". But if there are several "integration managers", they also need to fech and merge (to pull) the commits that other integration managers commit to the "blessed repository", ideally _before_ the push, and possibly trying to maintain his/her master branch as close as upstream as they can.

This means that is not a good idea for a "integration manager" to work with the local master branch (or the branch that tracks upstream/master) directly except when he/she is merging changes to the official repo. He/she should save this brach (and preferably call it master to avoid confusion) to keep syncronized with the blessed repository, and do his/her developer work using other branches. By extension, if the developers do the same in their public and private repos, then master is always the same for all in all the forked repos, and you always can safely branch from it, and do a pull master from the "blessed repository" without conflicts.

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

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

#53 Post by Dilvish »

jcantero wrote:There is a clear advantage in doing the merges in the local repository and then push them to the github repo
I can't help but feel you are overly focused on apologetics for the current situation. Let's go ahead though and examine the common situation where I have forked a main project repository (remote 'upstream') and am working with a local clone of my github fork (remote 'origin'). For simplicity's sake let's say that the the main repository only has a master branch. In what I understand to be the most common practice (or at least a very common one), I want to keep my local master branch in sync with the upstream master branch, and I do all my work on local branches, which I sometimes push to my github fork (origin), for making a pull request or sharing. (Even if I do sometimes push from my local feature branch directly to upstream master that doesn't really change the discussion.) It's good practice for me to keep my fork's master branch in sync with the upstream master branch (even if I sometimes decide to delay or forgo updating my feature branches with the new commits). My git gui software is totally capable of determining (and does determine) whether my local master branch has any commits not in upstream master, and whether or not upstream master has commits not in my local master. With a little bit of prodding it will also do these same determinations for origin. (Or I could have it easier to track origin instead of upstream.) In a common scenario upstream master will have commits that local and origin master don't; to rectify that I first sync my local master with upstream master, and then I push my local master to origin. Given that I'm relying on the software to double check that there are no conflicting commits, why don't I have a single button to take care of these steps? (None of the git guis I've used or read about so far do). What is the special step of oversight that I, the user, am doing in the multistep process that would be lacking in the single-click process? It appears to me that there is not one. If there are any kind of conflicting commits (or just any commits in the other direction than upstream->local->origin) my software could flag that to me to deal with first, just like it does in the current multi-step process.

Ok, so that's for my local git gui, whereas a part of my beef was about the github web interface, since they're the ones promoting the whole fork thing. They are not simply hosting remote backup storage of my local repository. They have interface elements to let me directly fork the upstream repo. Why can't they also have a way for me to tell them that I want my fork master to always be kept in sync with the upstream master? It is already paying attention to the issue and telling me when upstream master has something my fork master doesn't. Why make me jump through extra hoops to deal with it? That way at my local repo I could just deal with the simple task of keeping my local master in sync with origin master. At the very least, this should be a configuration that I should be able to specify to github, even if there are some situations where folks might prefer to instead specify to leave the setup as it is currently. It's just too much pointless nuisance (and corresponding risk of error, greater opportunity to accidentally pull from or push to the wrong place) to deal with a standard process.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

jcantero
Krill Swarm
Posts: 12
Joined: Sun Nov 24, 2013 5:08 pm

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

#54 Post by jcantero »

Well, I was talking about using this instead of this not in the sense of "user interface" but in the sense of "workflow". But to try to answer your questions:
Dilvish wrote:Given that I'm relying on the software to double check that there are no conflicting commits, why don't I have a single button to take care of these steps? (None of the git guis I've used or read about so far do). What is the special step of oversight that I, the user, am doing in the multistep process that would be lacking in the single-click process? It appears to me that there is not one. If there are any kind of conflicting commits (or just any commits in the other direction than upstream->local->origin) my software could flag that to me to deal with first, just like it does in the current multi-step process.
Because the multistep process is the over-cautious newbie-friendly way to do an operation, but often you can do the same with fewer steps. If you know that your local branch is not going to have commits that can conflict, the five steps are only two (and one can be superfluous): git checkout master (to guarantee you are in the master branch) and git pull upstream master.

Git is a comman-line tool, and most recipes and explanations are written in terms of command-line idioms. I assume the vast majority of git gui tools can mimic these commands, but it can be differences between them, so git command-line notation serves as a 'lingua franca' for everybody to understand. If you git gui can translate it to a simple button, great! If not, at least you have the basic steps to do it, and more important: to undestand what's going on.
Dilvish wrote:Why can't they also have a way for me to tell them that I want my fork master to always be kept in sync with the upstream master? It is already paying attention to the issue and telling me when upstream master has something my fork master doesn't. Why make me jump through extra hoops to deal with it?
Because if you use an automatic tool to keep in sync your repo with another repo, and somehow the source repo gets screwed (or its history is rewritten), then your repo automatically gets screwed or left in a inconsistent state. You can easily set a process to do a periodic "git pull upstream master" every XX seconds, but it seems like a dangerous idea and I guess GitHub devs may think the same way.

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

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

#55 Post by Dilvish »

jcantero wrote:If you know that your local branch is not going to have commits that can conflict,
So, if I'm confident I already know some key aspects of my local status, I can skip some status-checking steps,
the five steps are only two (and one can be superfluous): git checkout master (to guarantee you are in the master branch) and git pull upstream master.
and if I don't care about updating my fork's master branch, then I can save the hassle of "push origin master" (or gui clicks)! It has the elegant simplicity of a Zen koan! :D However, I think this "some steps are often reasonable to skip" line of discussion is at best simply beside the point.
Dilvish wrote:Why can't they also have a way for me to tell them that I want my fork master to always be kept in sync with the upstream master? It is already paying attention to the issue and telling me when upstream master has something my fork master doesn't. Why make me jump through extra hoops to deal with it?
Because if you use an automatic tool to keep in sync your repo with another repo, and somehow the source repo gets screwed (or its history is rewritten), then your repo automatically gets screwed or left in a inconsistent state. You can easily set a process to do a periodic "git pull upstream master" every XX seconds, but it seems like a dangerous idea and I guess GitHub devs may think the same way.
I think this point might be significant if I had suggested "why can't my local gui (or the github web UI) automatically keep both my local master and origin master in sync with upstream master without me having to do any clicks at all?", but that is not what I suggested. For my local gui, the setup I spoke in favor would allow all the same history checking that you might have considered to be always performed prior to "git checkout master && git pull upstream master". (I'll confess, I generally don't bother double checking that someone hasn't screwed-up upstream master before performing a git pull upstream master, but I don't think my proposal significantly changes the risk profile of that practice.) As far as GitHub itself is concerned, I note that even the "over-cautious newbie-friendly way" that you linked in their help pages did not include any explicit step of such double checking, so asserting that as some overriding principle on their part seems unfounded.

Regardless, in either setup, the one of my proposal or the current status quo, the point of (potential) vigilant defense of my repo integrity is centered at my step of updating my local repo, not at the step of updating my GitHub fork, so your point doesn't seem to me to carry much weight. This is especially true given your first suggestions, that I could skip the "over-cautious" steps if I'm confident my local changes are not in conflict with upstream, and also that I not bother pushing to origin master-- the former invites the exact trouble you cite concern for, and as for the latter, while the backup value of an out-of-date fork is non-zero, it is notably underwhelming. In my previous post I had troubled to bold and underline a key sentence, which I don't really see a reply to, perhaps because of your command-line focus. I'll note that it probably would be possible for me to add an alias to my .gitconfig to perform the necessary series of commands which I could then in a concise fashion cause to be executed at the command line, and some guis might even allow me to attach such an alias to a button, but I would still consider that to be a disappointingly minimal level of support from the gui.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

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

#56 Post by Mitten.O »

I think you may be onto something, Dilvish. If you never committed to the master of your fork, all pulls from upstream to it would be fast-forwards and therefore guaranteed to work. Then you could have it update automatically, or with the press of a button, always. A pull only branch.

It would basically be like a remote branch (like remotes/origin/master), except visible to other repos. Hm.. I am not certain that you cannot fetch the remotes of a repository. Not that that would help without the button.

Git is in some ways a fairly low level technology and humanity is still exploring the higher level concepts to build on top of it. GitHub being the leading attempt at such. Gerrit has its own view of matters, which is in some ways better. Git has made so many things possible that we begin to imagine possibilities even beyond. Exciting times.
Any code by me in this post is released under GPL 2.0 or later.

jcantero
Krill Swarm
Posts: 12
Joined: Sun Nov 24, 2013 5:08 pm

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

#57 Post by jcantero »

Maybe I found something that can help in this regard, Dilvish. But let me first apologize, because the following references also use "command-line style" git. I hope you can easily translate them to your GUI usage.

Git already provides an automatic way to refer to a branch in a remote repository with the notation remote/branch, as in origin/master or upstream/release-0.4.4. You can use one of these remote references instead a local branch or commit in certain commands such as merge, but there is two important limitations: they are read-only: you can't merge or rebase to one of them (however you can merge or rebase from them). You can't checkout a remote reference either (but you can create a local branch pointing to the remote reference and then do the checkout of the new branch). The important thing about remote references is that git fetch automatically advances the remote references when the repository is updated from the remote. That means that upstream/master is always synced with a simple "git fetch" or the equivalent click that your GUI git tool provides. Perhaps this is enough for you, assuming your GUI can show you remote branches.

Unfortunately, it is a very restricted way to keep track of a remote branch (at least in command-line). So git has additional configuration to link a local branch with a remote branch (reference), called remote tracking (branches). From the section Tracking Branches of the Git book:
Checking out a local branch from a remote branch automatically creates what is called a “tracking branch” (or sometimes an “upstream branch”). Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type git pull, Git automatically knows which server to fetch from and branch to merge into.
Note that this git pull surely it's a simple click or button in yout GUI tool.

Now the ugly details: this link has a lenghtly explanation about how to configure the .git/config file of a git repository to track remote branches. But there is also a way or two to achieve the same using the command-line: Track a new remote branch created on GitHub, Make an existing Git branch track a remote branch? And we must also take into account the behaviour of push, handled by the push.default variable of the git configuration (see git-config documentation or this).

I know, I know, this is a complex subject, and maybe not worth the effort. But perhaps somebody can figure it out and tell us. :wink:

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

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

#58 Post by Dilvish »

jcantero wrote:Maybe I found something that can help in this regard, Dilvish. But let me first apologize, because the following references also use "command-line style" git. I hope you can easily translate them to your GUI usage.
I'm on Linux and use a mix of command line and gui to work with git, so your language is no problem. The gui I am using is Smartgit, and it handles tracking remotes no problem; what you discuss all appears fairly familiar to me. After experimenting a bit with having my local master track origin master versus upstream master, I wound up deciding that leaving it tracking upstream master is more effective for me (probably because, as you noted, the step of pushing to origin master is a bit of an optional final step for backup or sharing purposes, not really part of the primary workflow). That was the context from which I wrote my original complaint about the unnecessary hassle of maintaining upstream master -> local master -> origin master. It would have been yet an extra degree of nuisance if my gui did not support tracking, yuck!
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: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#59 Post by Vezzra »

MatGB wrote:Ye gods that looks like work, guess there are disadvantages of a more powerful tool, the very simply right click/update from SVN method I've gotten used to isn't there are all, no wonder I was getting confused trying to figure out how to do it.
Well, I wouldn't go that far, this whole workflow with two repos, the main one and a personal fork, isn't something git requires you to do, that's a thing github builds on top of git.

To get used to working with git I think you can leave out the personal fork stuff for now. Then things should be quite a bit simpler. With a git gui client you shouldn't be too far from the "right click/update" method you know from SVN, the git pull command works similar.

Did you work through some basic git tutorials? Git is a complex tool, but the subset of commands you're going to need for everyday work shouldn't be too daunting to learn, a good tutorial should focus on these without burdening you with the scarier parts. ;)
This reminds me that I need to learn how to compile now I've access to a machine capable.
Feel encouraged to do so :D

The SDK for Windows has already been updated to work with git and github, as have been the instructions on the wiki. Just try it - no risk, no fun! ;)

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

Re: GitHub migration procedure

#60 Post by Vezzra »

Dilvish wrote:Am I missing something significant on this branch-description issue?
No... AFAICT you've got the essentials covered pretty well.

Post Reply