[mythtv] [mythtv-commits] mythtv commit: fbe4969 by Raymond Wagner (wagnerrp)
mythtv at colin.guthr.ie
Tue Dec 7 14:19:57 UTC 2010
'Twas brillig, and Jean-Yves Avenard at 07/12/10 12:45 did gyre and gimble:
> On 7 December 2010 22:37, Simon Kenyon <simon at koala.ie> wrote:
>> what is generating this log message?
>> it does not describe the change
>> is this just a function of the way git works?
> Raymond merge his private view with the master..
The email message itself is actually not very informative and a little
misleading. This is a merge commit and while the diff available on the
link generated does not really reflect this actual commit. It just shows
you (I think) the parent at which the merge was based (a merge commit
has two parents as you'll likely see on the github view).
So in this case the Merge commit:
is actually really a view of:
I'm not sure if it really makes sense to show a diff on a merge commit
to be honest but that's something for the github guys to suss out.
The only time a merge commit is "useful" (from a "caring that it
happened" perspective) is when there are merge conflicts that need to be
As a method of keeping things "neater", if people do not actually
publish their own private branches, then after a git pull (which creates
a merge commit if you've got local commits and upstream commits are
pulled in), then a simple git rebase origin/master before doing the git
push will factor out the merge.
Rebasing is generally not advised when you've published your branch for
others to test (as it requires forced updates on pulls), but it might be
worth doing for general usage.
I tend to do that in projects I manage but I wont go out of my way to do
it as merges are a natural part of git workflow (I'm just a bit anal
about things like that).
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the mythtv-dev