From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F4020C04A95 for ; Wed, 28 Sep 2022 12:54:41 +0000 (UTC) Received: from localhost ([::1]:33394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odWaG-00083a-Tv for qemu-devel@archiver.kernel.org; Wed, 28 Sep 2022 08:54:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53926) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odU99-0004QF-3v for qemu-devel@nongnu.org; Wed, 28 Sep 2022 06:18:40 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:30056) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odU95-0001FJ-3U for qemu-devel@nongnu.org; Wed, 28 Sep 2022 06:18:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664360304; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eWrykbZ6EDbhsP4uZHh19HK4EOi/KsCUb3vOrrGY+P8=; b=R4cyRILjxT3g+aMwhv2ESWwVKowFCz4S4V++12tBHnrUioQzTsThg3VlBh2GBMF8MavB0w ZaakamGlp9lWle7TL4OddfrXgak3ncTZWXfqfW/sL/xQgWS+WDgU98o6pUKeyfIV/Igyhc QgNMhnc095QE9UWcvdHi2UVSHuCRHSU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-398-SuWFuYJUPnCxqAV1xKIXAA-1; Wed, 28 Sep 2022 06:18:22 -0400 X-MC-Unique: SuWFuYJUPnCxqAV1xKIXAA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 52498100FD92; Wed, 28 Sep 2022 10:18:22 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.68]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0BEB92027063; Wed, 28 Sep 2022 10:18:20 +0000 (UTC) Date: Wed, 28 Sep 2022 11:18:18 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: "Michael S. Tsirkin" Cc: Thomas Huth , Ani Sinha , John Snow , Laurent Vivier , Paolo Bonzini , imammedo@redhat.com, qemu-devel@nongnu.org Subject: Re: Why we should avoid new submodules if possible Message-ID: References: <59150265-44ed-0b14-df1c-42e3f2e97b7e@redhat.com> <20220628060210-mutt-send-email-mst@kernel.org> <20220928052352-mutt-send-email-mst@kernel.org> <20220928061303-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220928061303-mutt-send-email-mst@kernel.org> User-Agent: Mutt/2.2.6 (2022-06-05) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Received-SPF: pass client-ip=170.10.133.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.082, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, Sep 28, 2022 at 06:13:45AM -0400, Michael S. Tsirkin wrote: > On Wed, Sep 28, 2022 at 10:37:14AM +0100, Daniel P. Berrangé wrote: > > There's also the perenial problem that developers frequently send > > patches that mistakenly include submodule changes, which is related to the > > way that 'git checkout' doesn't sync submodule state when switching branches. > > Do you happen to know how exactly that happens? For any given branch the submodule is synced to a given git commit hash. If the submodule checkout is not synced to the same commit hash it will show as dirty, and if you git add this pending change, it'll record that new submodule commit hash. Seeing dirty state is common when you switch between branches, either side of a git master change that updated a submodule. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|