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.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD, STOX_REPLY_TYPE,TVD_FINGER_02 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 AFED82070F for ; Mon, 19 Sep 2016 14:47:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752039AbcISOrD (ORCPT ); Mon, 19 Sep 2016 10:47:03 -0400 Received: from smtp-out-3.talktalk.net ([62.24.135.67]:49328 "EHLO smtp-out-3.talktalk.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764AbcISOrB (ORCPT ); Mon, 19 Sep 2016 10:47:01 -0400 Received: from PhilipOakley ([92.22.33.116]) by smtp.talktalk.net with SMTP id lzqKbe7yVxR4blzqKbyPNC; Mon, 19 Sep 2016 15:46:49 +0100 X-Originating-IP: [92.22.33.116] X-Spam: 0 X-OAuthority: v=2.2 cv=JNN5iICb c=1 sm=1 tr=0 a=7PoCAWDTb98b1EGiAsJI/w==:117 a=7PoCAWDTb98b1EGiAsJI/w==:17 a=N659UExz7-8A:10 a=cCri8_SAAAAA:8 a=U6JZQEu2cVQQrebrB9wA:9 a=pILNOxqGKmIA:10 a=sbRuPzbSW-bVi6QwGVni:22 Message-ID: <033051503D8C4F618B1E4879AFF8C28D@PhilipOakley> Reply-To: "Philip Oakley" From: "Philip Oakley" To: "Git List" , "Michael J Gruber" References: <2AD952BD65034D25BF26C7F138D24F25@PhilipOakley> <3b06b9ee-3975-acf1-41d8-02b774a2dd3c@drmicha.warpmail.net> Subject: Re: clarification of `rev-list --no-walk ^`? Date: Mon, 19 Sep 2016 15:46:50 +0100 Organization: OPDS MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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: MS4wfPLhxCsBbjV6JxMh1fkFiaE+ZCYUqWnSzZSCZYJreLIJt2pIuIY4srPP+rP1QoaKN8oUXQeEJFup2vfFvWYHUfiPrQ2/O54kTuTh6/p/NAhl20uUVz8t QUut8+tuo1XQcZWZAEc+IRi1fCnZgXkGMTQghq0YYwnJfx3wLfJnDi8b+LWOYc1A7c5BtFlNdFx5ZwzYsi/70ZGZOBCfonPAxIU= Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org From: "Michael J Gruber" > Philip Oakley venit, vidit, dixit 19.09.2016 12:56: >> A question came up on the Git user list regarding cherry-pick that got me >> reading the manual (again), in this case regarding --no-walk ranges. >> >> Essentially my question is: If --no-walk is given to rev-list (e.g. via >> charry-pick), and the user includes a caret prefixed rev, when does that >> range definition take effect on the command line, especially in light of >> the --do-walk option? >> >> In rev-list(1) there are only 8 references to 'range', with only >> the --no-walk option saying "This has no effect if a range is specified." >> but leaving open the decision as to what does (and does not) comprises >> the >> specification of a range on the cli. >> >> The two and three dot notations are fairly obvious ranges from >> gitrevisions(7) as they are complete strings, while the caret prefix is >> an >> implied range (it needs additional parameters to complete the range, and >> there-in lies the issue). >> >> It can be read that >> >> $ git cherry-pick maint next >> >> would pick two single commits, while >> >> $ git cherry-pick maint next ^master >> >> could implicitly be read as >> >> $ git cherry-pick maint next --do-walk ^master >> >> because the ^ caret starts the range that cancels the --no-walk. >> >> Clearly that's not what is intended, which is >> >> $ git cherry-pick --do-walk maint next ^master >> >> but it is open to interpretation as to where in the command line the >> caret >> range prefix's --do-walk (to countermand the --no-walk) should applied. >> >> If the user did want just the single commit at the tip of maint, and then >> the range master..next, what would be their command line, and also, how >> would the man page warn against false expectations? > > Maybe: > > Every negative rev (rev prefixed with ^, or a range) implies a > `--do-walk` (right at its position on the command line). > > And then curb the misleading range sentence in the `--no-walk` > description. At the moment the cherry-pick man page's example implies that --do-walk is applied from the beginning, rather from the point given on the command line. I had a very quick search of the *.c code for the options but didn't get any further. Hopefully the user issue/misunderstanding is elsewhere... I'll add this to my little list. -- Philip