Re: Git, merging, and News/Relnotes files

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 5, 2008, 20:03 UTC
Message-ID: <alpine.LFD.1.10.0807051253000.2815@woody.linux-foundation.org>
In-Reply-To: <486FC65C.70602@thewritingpot.com>

On Sat, 5 Jul 2008, Edward Z. Yang wrote:

> 
> I'm slightly surprised no one suggested that I can the file, given that
> both Git and the Linux kernel don't have one.

Well, I personally think ChangeLog files are a total waste of time. You're much better off autogenerating those from the real logs, I think.

[ Although in all honesty, I also think we could improve on our reporting 
  tools, and have ways to perhaps highlight big or important changes some 
  way ]

But a NEWS file that actually talks about new features is a different thing. It can make lots of sense to maintain something like that, so I wouldn't suggest canning it if it works for you. I'm not convinced it would work for the kernel, but I suspect it can work really well for other projects.

Show 8 quoted lines

> > For example, the default 'union' merge will literally _duplicate_ 
> > identical that were added in both branches. So if you cherry-pick a commit 
> > so that it exists both in the branch you are merging _and_ the branch you 
> > are merging into, then any additions to the NEWS file will basically show 
> > up twice, and yet auto-merge "cleanly".
> 
> I suppose that's why we have git reset --hard HEAD~. :-) I will
> certainly keep this gotcha in mind.

Well, the real problem with a clean automatic merge is not that it can't be undone (or better yet - fixed: just edit the NEWS file and then do a "git commit --amend NEWS" to fix up the atomatic merge), but the fact that most of the time you'll simply never even notice.

IOW, when something merges cleanly (and the 'union' merge will basically always do so), the most common case is probably that people won't even _look_ at the end result - especially if it works fine most of the time.

That's why a trivial conflict can often be better than a silently clean merge: at least it forces people to spend a small amount of brainpower to look at the obvious fix.

But hey, give it a try. Maybe you'll like the union merge, together with occasional manual fixups. Or maybe you'll decide that a specialized merge strategy isn't that painful after all (or can find somebody who already went through the pain and wrote one you can use).

		Linus