Pushing into origin/master with a new change description

[Andreas Pakulat]

On Sun, Aug 5, 2012 at 5:21 PM, Morten Volden <mvolden2 at gmail.com> wrote:
>
> 2012/8/5 Morten Volden <mvolden2 at gmail.com>
>>
>>
>> 2012/8/5 Andreas Pakulat <apaku at gmx.de>
>>>
>>> Hi,
>>>
>>> On Sun, Aug 5, 2012 at 10:42 AM, Morten Volden <mvolden2 at gmail.com>
>>> wrote:
>>> > Not quite sure if I broke something in the remote repo or not (I
>>> > sincerely
>>> > hope not), so just to make sure.
>>>
>>> It does not look like anything was broken, although the gitk history
>>> could look a tad bit nicer.
>>>
>>> > I took the changes made in my local development branch (for both
>>> > kdevplatform and kdevelop ) and merged them into my local master.
>>>
>>> It seems you first merged master into your local branch regularly and
>>> also directly before pushing which is why the merge of
>>> outputview-extension into master was a 'fast-forward' . Thats why
>>> there was no dedicated merge-commit saying 'outputview-extension was
>>> merged into master' anymore. As Ivan already said, you could prevent
>>> this with git merge --no-ff.
>>
>>
>> Thanks Andreas and Ivan for your replies. I'm sorry to bring up off-topic
>> stuff that basically originates from me not reading the manual properly.
>>
>>>
>>>
>>> > Browsing the remote repository I see that there is no revision number
>>> > to
>>> > these changes and there is no change description.
>>>
>>> If you talk about the git merge outputview-extension done in your
>>> local master branch, then yes since there was no commit created for
>>> this.
>>>
>>> > What I really wanted was to have a single change description for all
>>> > the
>>> > small commits that was made in the development branch. I naively
>>> > expected
>>> > git to present me with the option to do this at some point in the
>>> > process.
>>>
>>> See the git merge manual, if it can do a fast-forward then it'll
>>> prefer that by default. A separate merge-commit is only inserted when
>>> using --no-ff or if the a fast-forward is not possible.
>>>
>>> > So the question is:
>>> >
>>> > a) Is the remote repository broken?
>>>
>>> No.
>>>
>>> > b) Is there some way to fix the change description in the remote repo?
>>>
>>> No. You need to make sure the history is as you want it before
>>> pushing. Personally I find gitk very useful for this.
>>
>>
>> Great :-)
>>
>> I'll be pushing the changes to kdev-custom-buildsystem in a short while,
>> let's see if I can do the merge correctly this time :-).
>
> No luck. :-/
>
> Just pushed the changes to custom-buildsystem. The same problem.

No, actually everything went as we said it would. However apparently
you're expecting something different.

> As a perforce user I'm having some difficulty wrapping my head around how
> git does things. I expected there to be one commit message for the entire
> merge. Instead when I do git log on a given file I see the commit logs from
> the development branch (But not the commit message from the merge).

As Ivan said, this is the standard thing. Its also nice often since
one can see how a feature that isn't trivial evolves over time.
Merging in git just means putting the feature-branch commits back into
the master line of commits and making the changes available for users
of master.

What I usually do with feature-branches is commit often, even
non-compiling things when I want to 'save' some state. Then once the
feature works and all the bugs I could find are fixed up I look at the
commit log in the branch and rebase the commits so the history is
looking as I want it (squashing bugfix commits where it makes sense
etc.). Once I have a history which makes sense and is if possible
always compiling I merge the branch back into master. I also don't
merge the master branch into my feature branch while working on it -
unless its a very long-living branch - so other features/bugs do not
distract me from my feature-work. Those problems can still be fixed
when merging things back into master.

Andreas