[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: namespace convention for short-lived branches

From: Dmitry Gutov
Subject: Re: namespace convention for short-lived branches
Date: Thu, 23 Apr 2015 04:03:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

On 04/22/2015 08:56 PM, Glenn Morris wrote:

You can verify this by looking at the mails that come about when
emacs-24 is merged to trunk, eg:


There have been no complaints so far.

Like I thought, it's only showing the new commits (the merge commits in this case, both the "meaty" and "skipping" ones).

While it seems like the emails contain all the changes (squished together, which might appeal to people used to Bazaar's merges), you don't see the merged commits' messages (only their first lines).

And while in merges from emacs-24 you see the ChangeLog changes now, as soon as they're auto-generated there too, that will change. I'm not sure we want to include the full message of each commit inside the merge commit's message (which would be a way to fix that).

At the risk of opening the chat-about-git-floodgates again, this prompts
me to ask: is there a setting that will make such merge mails better?
I'm using

log --format=full -C --stat -p -m --first-parent

I'm a simple-minded person who just wants to see
"difference between master before this change was applied and after it
was applied"

Yup, it seems you're already aware of what I described above.

Sometimes the diffs don't seem to make sense. Eg in


The NEWS diff is completely bogus AFAICS (the NEWS file in emacs-24
merges to NEWS.24 in trunk).

I believe that some of the edits there were done by hand, to resolve the conflicts. And some of NEWS entries were moved to NEWS.24 in a later merge commit, 98284ef.

So it seems correct.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]