From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id F18421F600 for ; Sun, 23 Jul 2017 22:13:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751510AbdGWWN1 (ORCPT ); Sun, 23 Jul 2017 18:13:27 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:61527 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751455AbdGWWN0 (ORCPT ); Sun, 23 Jul 2017 18:13:26 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id AFDF48110B; Sun, 23 Jul 2017 18:13:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=1HZfQ/Ye+wRJcL3QS/1U7HEJVJ0=; b=kERYDN qyebH7+/phNhF64iJ8/HJzrEKtIe/yuqtb6UHHUGSW3MIrb74BZBApaTCtZmWyNY 3Fjy0V0ysx6u59LtzdMyHnC1XU3wUzO9Vsa4JDSqO7lwNCMVzvlfhHqzxwZ/4v2A nBIOvzj55D0zyIYh+RUGdT6j2yhCBi2kIF+Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=eYyyiX2scD7JyY5u0rPE8kqxCcXGgD3y rPrBYDU/gcnf8hhB64Eku9egWDXj9xcP+2etIqIE5Fe8VZVAM9M86JXIulTM86t1 6+ty1GHKPWozpaY2rdSDu5KgAkX/JjA0i+BUhi3Qt+YJSsGavnvwCVBUHsCDrCu7 6Hgb5/yudIE= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A92C68110A; Sun, 23 Jul 2017 18:13:18 -0400 (EDT) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 1BBA981109; Sun, 23 Jul 2017 18:13:18 -0400 (EDT) From: Junio C Hamano To: Andreas Heiduk Cc: Git Mailing List Subject: Re: Bug^Feature? fetch protects only current working tree branch References: Date: Sun, 23 Jul 2017 15:13:16 -0700 In-Reply-To: (Andreas Heiduk's message of "Sun, 23 Jul 2017 16:50:54 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 21680308-6FF4-11E7-8DC6-61520C78B957-77302942!pb-smtp2.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Andreas Heiduk writes: > A `git fetch . origin/master:master` protects the currently checked out > branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a > mismatch between the index and HEAD. BUT branches which are HEADs in other > working trees do not get that care - their state is silently screwed up. > > Is this intended behaviour or and just an oversight while implementing > `git worktree`? The latter. "git worktree" is an interesting feature and has potential to become useful in wider variety of workflows than it currently is, but end users should consider it still experimental as it still is with many such small rough edges like this one. Patches to help improving the feature is of course very welcome.