Better branch model about remi HOT 6 OPEN

I would rather do FF rebases onto master than merges anyway.

But I think this is all a bit too early as IMO REMI is quite far from a stable API where any branch model has to be considered.

from remi.

Yeah, we should use that git model to ensure stable versions on master and make the repository more readable and well organized.

from remi.

John, what is the purpose of an FF rebase? I have't deep knowledge of git usage.

from remi.

For single commits - tiny bugfixes or other small things that are not large
enough to be called a 'feature', it keeps the history more readable as you
don't have a merge commit for every commit. For example, if a user submits
a pull request with one commit then this generates a merge commit also (if
merged using the git web interface). That makes the history seem messy.

That extends for local master merges, where git creates a merge commit
because you git pull. Buy most definitions this is not a feature
branch, it is just that your HEAD didn't agree with master and git created
merge to make them agree.

Just look at the git history for all the recent small fixes by contributors

• do all the merge commits make things readable? not really I think.

On 6 November 2015 at 09:49, Davide [email protected] wrote:

John, what is the purpose of an FF rebase? I have't deep knowledge of git
usage.

—
Reply to this email directly or view it on GitHub
#53 (comment).

from remi.

Thank you for the explanation. You are right, infact I felt 'unconfortable' when submitting the merges of pull requests. However this is another aspect not strictly related with what cyberpro4 says. I mean, both thinks can coexist. We can organize better the repository for the future changes and furthermore use FF rebase. Right?

from remi.

Yes, we can, and I do in other projects, use both. FF for small things, and feature branches + merges for large things.

from remi.