Commit history in master repository

[Cláudio Silva]

On Fri, Feb 3, 2012 at 10:20 AM, Daniel Hellstrom <daniel at gaisler.com> wrote:
> On 02/03/2012 08:58 AM, Sebastian Huber wrote:
>>
>> Hello,
>>
>> if we look at the commit history here:
>>
>> http://git.rtems.org/rtems/log/
>>
>> we see that some of our commits show up twice, e.g. "PR 1962/bsps -
>> MVME162 Console Corrections and Improvements".  We also have these merge
>> commit messages.   I think that it is better (please note that I am a Git
>> novice) to use a rebase instead of a merge before we push changes upstream
>> into the master branch.
>
>
> If I understood the problem correctly, I agree with you. That has come up
> for discussion a couple of times here at Gaisler as well when converting
> from SVN to GIT, there is a simple solution:
> 1. never work in master branch!  This means you never have conflict in
> master.
> 2. before pushing upstreams do:
>  A. update master by fetching from server
>  B. rebase working branch against newly updated master
>  C. push working branch to server master: git push origin work:master

I agree that rebasing your work is the best option to avoid those
commit messages.
In git commands this workflow would be:

1) git checkout -b feature_branch origin/master - (create new branch)
2) do your changes, git add / git rm, git commit, etc.
3) git fetch origin - (update by fetching from server)
4) git rebase origin/master - (Your new commits will be placed on top
of the origin/master head)
5) git push origin feature_branch:master

As an alternative to 5) you can:
5) git checkout master
6) git merge feature_branch (since you have rebased your work, this
merge will be fastforward (no conflicts))
7) git push origin master:master

For those not familiar with git, RTEMS wiki has now some
documentation: http://wiki.rtems.org/wiki/index.php/RTEMS_GIT_Repository

Regards,
Cláudio