Re: Bizarre missing changes (git bug?)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 26, 2008, 19:58 UTC
Message-ID: <alpine.LFD.1.10.0807261249430.4188@nehalem.linux-foundation.org>
In-Reply-To: <200807260512.40088.zippel@linux-m68k.org>

On Sat, 26 Jul 2008, Roman Zippel wrote:

Show 8 quoted lines

> >
> > So without --full-history, if any parent matches the state, it just
> > removes the merge and picks that parent that contained all the state.
> > Obviously, any changes to that file can be sufficiently explained by
> > walking just that limited history, because they must have changed in
> > _that_ history too!
> 
> Is that really a good default behaviour?

Yes. It's the only sane default right now. See below.

> Is there a way to change that default?

Use an alias or something.

To see why it's the default, do a few tests. In particular, try it with gitk on the kernel. Try it on some fairly simple file that doesn't get a lot of churn. Example:

	gitk lib/vsprintf.c

vs

	gitk --full-history lib/vsprintf.c

and if you don't _immediately_ see why --full-history isn't the default, there's likely something wrong with you. One is useful. The other is not.

So we absolutely _have_ to simplify merges. There is no question about it.

That said, we currently simplify merges the simple and stupid way, and I've hinted several times on this mailing list that there is a better way to do it (last time it was the discussion about "filter-branch".

In fact, if you google for

	filter-branch full-history

you'll find some of the discussion. In order to make --full-history useful as a default, we'd need to do an after-the-fact merge cleanup (ie remove lines of development that are later found to really be totally uninteresting), but that is *hard*.

But if we did that, I'd agree to making --full-history the default (and it would be a good thing, no doubt about it - I just cannot see how to do ti simply and sanely enough)

		Linus