Pushing into origin/master with a new change description

[Ivan Shapovalov]

On 5 августа 2012 17:21:51 Morten Volden 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.
> 
> When merging I did:
> 
> git merge --no-ff -m "Use outputmodel defined in
> outputview/outputmodel        REVIEW: 105321" outputview-extension
> 
> Where outputview-extension is the name of my development branch.
> 
> 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).
> 
> > I'll most definitely take a look at gitk - Thanks!
> > 
> >> Andreas
> >> 
> >> PS: There are technical ways of changing the history, but you cannot
> >> do this yourself (requires sysadmins giving you force-push rights
> >> temporarily) nor is it really necessary in this case.
> >> 
> >> --
> >> KDevelop-devel mailing list
> >> KDevelop-devel at kdevelop.org
> >> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> > 
> > --
> > - When the split is pulled, mr. Grenade is no longer our friend

Well, this time the merge commit _is_ actually created and given SHA1 of 
2184749fce0587fa3921bd553d287be722102fde.
But yes, you'll always see the whole development history behind that single 
merge commit. That's the point of Git... ;)

BTW, as Andreas pointed out, you've got many merges "master -> local branch" 
and the resulting history looks somewhat messy... Though this is absolutely 
technically correct.
I personally use "git rebase master my_branch" to keep the history clean.
-- 
Best regards,
Shapovalov Ivan