Console (local and on server):
Code: Select all
git branch --merged master -a
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
Moderator: Committer
Code: Select all
git branch --merged master -a
Code: Select all
(2|0) # behind|ahead
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 fileMatGB 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.
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...?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.
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.Geoff the Medio wrote:or possibly saving a few (local) commits as patches and then re-applying them after updating.
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.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
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.Dilvish wrote:...if you are using GitHub's GitGUI offering...
TortoiseGit can do all you describe as well. Only thing I haven't figured out with it is how to reset easily....smartgit...
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.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.
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.
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'.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.
It is SVN style.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.You both have a mental blockade here.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.
It makes reviews easier for me.Cjkjvfnby wrote:Making good history take too much time and does not improve process.