Another gnucash git question

[John Ralls]

On Apr 30, 2011, at 9:36 AM, Geert Janssens wrote:

> On zaterdag 30 april 2011, John Ralls wrote:
>> Don't add branches to refs/remotes anything. Hang your working branches off
>> of your local mirror-branches (trunk and 2.4 if you have one; only trunk
>> is made automatically)
> 
> Can you help me understand why this is not done ? If I look with gitk, I now 
> have a commit with four branches on it:
> refs/remotes/origin/trunk
> refs/remotes/trunk
> trunk
> bugfix (my working branch)
> 
> But there is nothing suggesting that my working branch if based on trunk or 
> refs/remotes/origin/trunk.
> 
> For completeness, bugfix is not a tracking branch. It was simply created with
> git branch bugfix
> I don't know if this is correct, or if this branch should have been tracking 
> trunk.


Geert,

You don't want local stuff in refs/remotes: Git uses those references to keep track of what's on the remote, and if you put local references there it will get confused.

Working branches shouldn't be tracking branches. They should branch from tracking branches (which means that the parent of the root commit of the branch should be a commit on the tracking branch). 

By "commit with 4 branches on it", I understand that you have a single commit with the names of those 4 branches in little boxes next to it on the timeline display. What that means is that that commit's SHA1is the HEAD reference for all 4 of those branches. Git-update rewrites the references in refs/remotes/<branches> to match those in refs/remotes/origin/<branches>. That's so that the git svn dcommit (on your system)->svn update (on my server)->git push(on my server, to github)-> git pull origin (on your system) can work without getting confused. That means that the commits from your original git svn import are now accessible only from the working branches that you created. Once you rebase them from refs/remotes onto new branches in refs/heads, you can delete the branches in refs/remotes and run git prune and git repack -d. (Make a backup first and run git fsck --unreachable to see what's going to get deleted.) git svn log --oneline is a good check to make sure that the svn side is synced up properly; if you get log output, all is well.

If your bugfix branch has been merged back into trunk and dcommitted, then that's good, too. If bugfix has commits that haven't been merged, then something's wrong.

You should run git fsck after you've gotten everything rebased to make sure that the repo is in good order. It would be wise to make frequent backups as well. 

Regards,
John Ralls