Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422870AbWCUSZU (ORCPT ); Tue, 21 Mar 2006 13:25:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1422794AbWCUSZS (ORCPT ); Tue, 21 Mar 2006 13:25:18 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:17810 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S1422861AbWCUSZQ (ORCPT ); Tue, 21 Mar 2006 13:25:16 -0500 Subject: Re: [PATCH 000/141] V4L/DVB updates part 1 From: Mauro Carvalho Chehab To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, linux-dvb-maintainer@linuxtv.org, video4linux-list@redhat.com, akpm@osdl.org In-Reply-To: References: <20060320150819.PS760228000000@infradead.org> <1142962995.4749.39.camel@praia> Content-Type: text/plain Date: Tue, 21 Mar 2006 15:24:38 -0300 Message-Id: <1142965478.4749.58.camel@praia> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1-3mdk Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2424 Lines: 52 > Hmm. I don't know if it's stgit per se. Maybe the breakage came from a > mercurial merge that got exported to git as a patch, rather than as a > merge. We can't discard any cause, but, at mercurial, I just export the patches, removing all version-dependent code. After doing, I do a diff between Mercurial and git trees. Only after that, I proceed. > > If that's the case, then I'm afraid that the problem is the mercurial > part, or at least the hg->git conversion. I have no idea how hg does > merges, and maybe the broken merge was done in the hg tree. Patch generation seems to be ok, since I have the habit to check all patches before commiting. Also, diffstat I sent were generated by looking at the stg exported patches. I dunno if this is common, but running git-fsck-objects after working for a while with stgit generates lots of > > The really sad part about this is that it means I have to be much more > careful with dvb merges, since I can't trust the tree any more, when it > apparently has something strange going on. I'll rebuild the entire tree from the beginning, and I'll also update both git and stg version to latest ones. > If things like this keep on happening, I'll have to ask you guys to change your work habits. > > That said, I _tried_ to check for similar cases in the past history, and I > couldn't find any. So hopefully this was a one-off occurrence. I hope this won't happen again. What is sad is that I can't determinate the root cause of this breakage, but it seemed to be associated with merging handling at stg or git. One possibility is that stg pick doesn't seem to be preserving commit date, so that patches are compared with the wrong versions. The first 141 patches were committed in the past, starting from the end of 2.6.15 window and were already committed at stgit. I just did a git pull . prev to retrieve they. The newer 49, however, were not committed yesterday, but also in the past. Yesterday, I just picked them from work branch. However, stgit marked commit timestamp as if they were just committed. This might have generated some troubles at resolution conflict code on git. > > Linus Cheers, Mauro. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/