From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: cannot find hash in the log output Date: Fri, 3 Dec 2010 16:11:58 -0500 Message-ID: <20101203211158.GA2632@sigill.intra.peff.net> References: <7v8w07rje3.fsf@alter.siamese.dyndns.org> <20101203175212.GA8267@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Junio C Hamano , git@vger.kernel.org To: Eugene Sajine X-From: git-owner@vger.kernel.org Fri Dec 03 22:12:11 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1POcvJ-0007eL-Vr for gcvg-git-2@lo.gmane.org; Fri, 03 Dec 2010 22:12:10 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753493Ab0LCVME (ORCPT ); Fri, 3 Dec 2010 16:12:04 -0500 Received: from xen6.gtisc.gatech.edu ([143.215.130.70]:43098 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752659Ab0LCVMD (ORCPT ); Fri, 3 Dec 2010 16:12:03 -0500 Received: (qmail 26094 invoked by uid 111); 3 Dec 2010 21:12:00 -0000 Received: from Unknown (HELO sigill.intra.peff.net) (129.79.255.205) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.40) with ESMTPA; Fri, 03 Dec 2010 21:12:00 +0000 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Fri, 03 Dec 2010 16:11:58 -0500 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, Dec 03, 2010 at 03:10:40PM -0500, Eugene Sajine wrote: > Yes this does make sense to me. Although it is not necessary to have > conflicts during the merge - recursive merge as i understand also can > create new blobs. I haven't thought about it too hard, but I don't see why any merge would create a new blob unless there is a conflict. Otherwise you are always taking one of the blobs that already exists in some other part of history. > Now as this is pretty much clear: don't you think that the information > about one blob content changed during the merge should be present in > the merge commit info? No. We suppress "uninteresting" parts of merges by default because they are mostly clutter. If you really want to see them, use "-m". > It seems strange that git log contains merge commit, but > git whatchanged doesn't show the merge commit, while this > merge commit actually had a change of content in the file, The fact that git whatchanged does not show merge commits by default is just historical. There is really no need for whatchanged to exist at all these days, now that "git log" can do diffs internally. In fact, it is simply implemented these days as "git log" with a few different defaults. -Peff