You are here

Branching Encog 3.0.0

Now that Encog 3.0.0 has been released on all 3 platforms I wanted to provide a quick note on how this is laid out in Git.

There are two branches. "master" and "v3.0".

Master, which is always the main branch in git, is always the next major release. So now it is 3.1. This is very similar to the "trunk" we had in SVN.

v3.0 will contain all bug fixes for the current release, and is 3.0.1. These bug fixes will be merged back into 3.1 as well. There will likely be several 3.0.x releases before 3.1.

fxmozart's picture

So to develop, and implement new things, we now switch our branch to version 3.0, right ?

jeffheaton's picture

Actually for new feature development you can just keep using the same "master" branch that you've been using before. That will put your changes into what will become 3.1 in a few months.

The 3.0 branch is mainly for bug fixes that will be pushed out to the service releases (3.0.1, 3.0.2, etc). And then any of these bug fixes need to be made to 3.1 as well.

All new features should go into 3.1, since that is the current release that is now in development.

hoijui's picture

you might also want to have a look at this:
i would recommend that.

at first, we used a similar branching scheme like you do now (each mayor release has its own branch). but this will get very ugly the longer you have to/want to maintain the release branches, and may ultimately result in maintenance hell.

and i think i already suggested it once, but will again here...
maybe try to establish an IRC channel for the devs.
to learn how to use git, and ask and explain stuff to each other just works better in chat then on the forum.
i am in #encog at whenever i am online in IRC, and i'd be happy to give git advices. ;-)
I have some experience in using git for a bigger open source project, where i was also release manager for some time.

some general rules:
* if you have to use cherry-picking, you did something wrong. (most basically, it is bad cause a single logic commit will be around with multiple SHA1s).
* always rebase on branches with the same name (for example, master and origin/master)
* always merge branches with different names (eg. master and featureX)

something that was asked in an other thread:
using a distributed VCS indeed usually means you can cut down on the number of people with push access, and at the same time allow people to submit stuff more easily to the community. in your case, i guess the most natural list of people with push access would be jeff and seema only.
in the project i work at, it went from ~40 to 6 when we changed from SVN to git.

your friends are:
* gitk
* git gui
* git rebase -i (interactive rebase -> only use on history not yet pushed to the main repo!)
* git branch (create branch)
* git branch -D (delete branch)
"git rebase -i" will need some practice to feel comfortable with, but the others should be straight forward.

fxmozart's picture

So now i have overwrote my files with what Jeff pushed yersterday, when i submit it says now there's more or less EVERY file changed..But i only changed 3 files..

Is there a command to fix this issue ? (Issue happens quite a lot for me).

Only way i found was to actually delete the whole repo from my account and reclone it..


PS: took the "fast" route...deleted my repo , recloned...but if anyone knows the answer, would really help.

SeemaSingh's picture

I've run into something like this. Where I do a "git pull" and I don't see all of the new changes. I will see that git mentions something about a "fast forward". I think it actually keeps a pointer, called a "head", I guess like on an old VCR, where you can be behind the current version and continue happily along even though you've pulled the latest code. Not sure WHY you would want to be in this state, sounds dangerous to me.

I found I could do something called a "rebase" to move my head pointer back up to the current.

fxmozart's picture

I downloaded Git Extensions from visual studio extensions , the new one that is outside of visual studio..

Now it's quite easier to see things.

The one inside visual studio was a pain.

SeemaSingh's picture

Ohhhhhhhh I might have to look at that. Thx for the link.

hoijui's picture

if you don't know what rebase is, you should definitely learn about it. it is one of the most important git commands. (btw, i mentioned in my last post in this thread)

the thing you explained with seeing many files changed, while you only changed few, is most likely the famous issue git has with line endings (on windows).
there is a git config setting you might want to play with:
git config core.autocrlf true
(this sets it to true)
you may have to use false or have it unset.
after changing this setting, you have to reset, and see if the repo shows changes still. but.. well it is a relatively difficult thing.. best is if you read about it somewhere.

if you do it wrong, you commit files with the wrong line endings.

edit: i guess one of the best explanations:

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer