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=-3.2 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD, STOX_REPLY_TYPE 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 5D2D2207D6 for ; Thu, 27 Apr 2017 22:08:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423304AbdD0WIB (ORCPT ); Thu, 27 Apr 2017 18:08:01 -0400 Received: from smtp-out-4.talktalk.net ([62.24.135.68]:35960 "EHLO smtp-out-4.talktalk.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162486AbdD0WH7 (ORCPT ); Thu, 27 Apr 2017 18:07:59 -0400 Received: from PhilipOakley ([92.31.218.76]) by smtp.talktalk.net with SMTP id 3rZsd1rA2cpsk3rZsdbDDC; Thu, 27 Apr 2017 23:07:57 +0100 X-Originating-IP: [92.31.218.76] X-Spam: 0 X-OAuthority: v=2.2 cv=ILRAMUnG c=1 sm=1 tr=0 a=e6L6E7eW+5Nb7SO+DvSdIg==:117 a=e6L6E7eW+5Nb7SO+DvSdIg==:17 a=8nJEP1OIZ-IA:10 a=ybZZDoGAAAAA:8 a=xtxXYLxNAAAA:8 a=FOMDAfpskrF99ATBFH0A:9 a=wPNLvfGTeEIA:10 a=0RhZnL1DYvcuLYC8JZ5M:22 a=xts0dhWdiJbonKbuqhAr:22 Message-ID: Reply-To: "Philip Oakley" From: "Philip Oakley" To: "Junio C Hamano" Cc: "Stefan Beller" , "Jeff King" , "Orgad Shaneh" , "Dakota Hawkins" , "git" , "Christoph Michelbach" References: <4BF0A1BFFFFD421EB8C5F7E6FEF14357@PhilipOakley> Subject: Re: Submodule/contents conflict Date: Thu, 27 Apr 2017 23:07:57 +0100 Organization: OPDS MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-CMAE-Envelope: MS4wfE7PblHoMfq63oQWmYBmIceAuP4YIjxl0zrDSiZDmfteoQZSoqnH60UG4nRneaNg+hhrZ9kakvxrRvKvyfKpj/S/hYwjfpqQD/fbCI3BsKocEzrxvOCD AiVCKOV6cdqCeJZC+I9rziY6koLEwZv+WkoQpP8sE2b85fnMoCEv+RxBSZSxSs2iaG8HCTKCNDrVx856oUQTsUnkIWnRonoDyhujxSXG0ZPvF9cFLiRKSPb6 F/4EER/G+bXM7JNR+ouwdBH0+qT8LZjTel/WcD6cgnkYPn9tpkNjS4jSARbRm2yAWXZPyc4JCicQ1of3bGR2jMvpysKD/0fcWcH64g3sMB0= Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: "Junio C Hamano" Sent: Wednesday, April 26, 2017 3:51 AM > "Philip Oakley" writes: > >> As I recall Christoph was using checkout to copy a file (e.g. a >> template file) from an older commit/revision into his worktree, and >> was suprised that this (git checkout ) also _staged_ the >> file, rather than simply letting it be in a modified/untracked state. > > This probably is taking it even further than the original topic, but > I raise this weather-balloon to see if anybody is interested. > > In the modern day, it might be useful if the "--working-tree-only" > mode added a new file as an intent-to-add entry to the index, but > that is not what "git apply (no other options)" (which is the gold did you mean `git add` ? Or am I missing something. > standard for command that operates on the working tree and/or on the > index) does, so it is not done in this patch. IOW, if you grab a > path that does not exist in your index out of , you will > write out an untracked file to the working tree. It sound like a good idea, as I wasn't aware of another easy way of doing it. > > -- >8 -- > Subject: [PATCH] checkout: add --working-tree-only option > > "git checkout " has always copied the blob from > the tree-ish to the index before checking them out to the working tree. > > Some users may want to grab a blob out of a tree-ish directly to the > working tree, without updating the index, so that "git diff" can be > used to assess the damage and adjust the file contents taken from a > different branch to be more appropriate for the current branch. > > The new option "--working-tree-only" allows exactly that. > > In the hindsight, when a command works on the working tree and/or > the index, the usual convention is: > > - with no other option, the command works only on the working tree; > > - with "--cached" option, the command works only on the index; and > > - with "--index" option, the command works on both the working tree > and the index. > > So we probably should have triggered the default behaviour under the > "--index" option, and triggered this "--working-tree-only" mode of > behaviour when "--index" option is not given. From the same point > of view, "git checkout --cached " would have > done the same as "git reset " would do. And > that may have made the command set a bit more consistent. > > But that is merely a hindsight being 20/20, oh well. > > Signed-off-by: Junio C Hamano > --- > Documentation/git-checkout.txt | 22 +++++++++++++++------- > builtin/checkout.c | 10 +++++++++- > t/t2022-checkout-paths.sh | 21 +++++++++++++++++++++ > 3 files changed, 45 insertions(+), 8 deletions(-) > > diff --git a/Documentation/git-checkout.txt > b/Documentation/git-checkout.txt > index 8e2c0662dd..201677752e 100644 > --- a/Documentation/git-checkout.txt > +++ b/Documentation/git-checkout.txt > @@ -14,6 +14,7 @@ SYNOPSIS > 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] ] > [] > 'git checkout' [-f|--ours|--theirs|-m|--conflict=