Thanks for the time to give me these suggestions. Unfortunately, I kept hitting 
snags that would not clear up, and, since my contributions are sporadic only, I 
simply nuked the whole environment (again!) and started over. I simply couldn’t 
get past the “This repository is 27 commits behind” hump. I would rather focus 
on the docs than the git interface.

I hope I can get going on the actual docs now.


> On Sep 11, 2016, at 7:37 PM, John Ralls <> wrote:
>> On Sep 11, 2016, at 1:05 AM, David T. via gnucash-devel 
>> <> wrote:
>> but, my documentation itch needs scratching, and I want to make sure my 
>> efforts at helping actually help.
>> I’ve been generating traffic with ideas on how to improve the documentation, 
>> and it seems to me I should dig back into the catacombs of Git to implement 
>> some of my great suggestions. Please bear with me, as I have numerous areas 
>> in git where I could use help.
>> Before I start digging in to new bug fixes in the documentation, I want to 
>> be sure I am working on a current copy of the documentation. For background, 
>> I am working on a Mac, using SourceTree to navigate git. I have my own 
>> github account at <> and I have forked master 
>> from 
>> <>. 
>> On github, when I open my fork it says at the top:
>> This branch is 27 commits behind Gnucash:master.
>> I realize that I should do something to not be behind—but what precisely am 
>> I supposed to do? Do I take action on github, or in Sourcetree? Which action?
>> Next, my SourceTree maint repository points to 
>> <>, and I have 3 branches on my 
>> machine for three bugs I worked on in February (743672, 762656, and 762088). 
>> The last two of these bugs now read on BugZilla RESOLVED FIXED, while the 
>> first is still on BugZilla as NEW. My Sourcetree screen looks like this:
>> I am not sure what this signifies, whether I need to do something (or 
>> whether whatever I do above will affect this). I note that the highlighted 
>> line includes both 743672 and 762656; does this mean that I somehow added my 
>> branch for 743672 to my branch for 762656? If that is what I did, I imagine 
>> it would be preferable for 743672 to have its own branch; is there a way to 
>> untangle them?
>> Finally, on github, the pull request for 762656 originated with me, and John 
>> and I exchanged some comments about technical aspects of the commit, and the 
>> page concludes with the note: 
>>> Closed with unmerged commits
>>> This pull request is closed, but the sunfish62:bug-762656 branch has 
>>> unmerged commits.
>> Clearly, I did Something; probably, I should clear this up. Can I simply 
>> click the Delete Branch button—or will that cause the whole patch to go away?
> David,
> To bring your github repo up to date you need to pull from 
> git://, which will bring your local repo up to 
> date, then push to git:// You'll need to 
> add that as a repository (select Repository>Repository Settings from the 
> menu, then the Add button). I suggest you name it "upstream" to comport with 
> Geert's naming convention in the wiki Git page.
> Be sure to tick the "rebase" box when pulling. Remember to pull both maint 
> and master, and to push both as well. There are a couple more wrinkles: 
> Because I changed the tags on PR52 (the one for bug 762656) on that commit 
> you will either get a conflict when the rebase tries to apply it or it will 
> morph into just changing those flags. I think it will be the conflict, in 
> which case you want to skip it (git rebase --skip if you were doing it from 
> the command line, SourceTree will have some GUI thing that does the same). If 
> git figures out what to do on its own and morphs the commit you'll need to 
> reset it. If you haven't made any other local commits you can just reset to 
> the commit before it. Control-click on the previous commit and select "reset 
> maint to this commit".
> The next wrinkle is that you need to force push to 
> git:// and I don't think that SourceTree 
> knows how to do that so you'll have to do it from the terminal. Click the 
> Terminal button on the top right and then at the command line say
>  git push -f origin maint
> You can get rid of the old feature branches in 
> git:// while you're at Terminal:
>  git push github :Bug-762088
>  git push github :bug-762656
> Note the colon in front of the branch name. It's a version of `git push 
> github foo:bar`, which you'd use if your local branch foo corresponded to 
> branch bar on the remote, so "push local branch foo to remote branch bar". 
> With only the second branch listed it means "push nothing to remote branch 
> bar", which deletes remote branch bar.
> Since you've never made local changes to master you can push it normally from 
> SourceTree.
> As for bug 743672, I'm planning to just delete the "What's New" sections this 
> week unless someone objects.
> The mailing list eats inline attachments, so put screenshots at the end. It 
> still might not work, the Mac mailer can be a bit uncooperative. 
> I'd think you'd see the "unmerged commits" notice on both PR52 and 53 since I 
> edited 52 and rebased 53. As I explained on 53, that changed the commits from 
> the ones you submitted so github can't tell that your changes were in fact 
> merged. The rebasing and force-pushing will change the comments to something 
> about "obsolete commits", but you needn't worry about it.
> I'll be up on IRC later today so ask there if you need more help.
> Regards,
> John Ralls

gnucash-devel mailing list

Reply via email to