git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Brandon Casey <casey@nrlssc.navy.mil>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] filter-branch: assume HEAD if no revision supplied
Date: Wed, 30 Jan 2008 13:03:49 -0800	[thread overview]
Message-ID: <7vk5lrgh56.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LSU.1.00.0801302034310.23907@racer.site> (Johannes Schindelin's message of "Wed, 30 Jan 2008 20:35:00 +0000 (GMT)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 30 Jan 2008, Brandon Casey wrote:
>
>> filter-branch previously took the first non-option argument as the name 
>> for a new branch. Since dfd05e38, it now takes a revision or a revision 
>> range and modifies the current branch. Update to operate on HEAD by 
>> default to conform with standard git interface practice.
>
> FWIW I think the code wanted to let "git filter-branch" without options 
> print the usage.

That might be a valid safety concern to some folks.  Previously
we have seen people say "Whenever I see a command foo that I do
not know what it does, I type 'foo <Enter>' and expect it gives
the usage back.  So any new destructive command 'foo' should not
do a damage by using built-in default." (I think it was about
"git stash" without parameter).

By the way, I do not personally think it is worth to be heavily
supportive to the practice of trying an unknown command without
understanding, and I do not agree such a safety is necessarily a
good idea, especially if it makes normal use of the command more
cumbersome by people who understand what it does.

Even though "git stash" itself is not destrictive, you need to
know its "apply" subcommand to undo the action.  In that sense,
it is destructive to clueless people who blindly type whatever
command they see.

That's why we still allow you to say "git stash", but we removed
its "git stash <randam message>" syntax, which was risky when
subcommand name was misspelled even by people who know what the
command does.  I think we struck a good balance between
usability and safety there.  And I think we can do the same
here.

Perhaps "git filter-branch <Enter>" can be prevented as in the
current implementation while "git filter-branch --foo-filter
foo" can default to HEAD to satisfy both needs.  The command
without any filter is supposed to be mostly no-op (unless you
are trying to rewrite the history with grafts).

  reply	other threads:[~2008-01-30 21:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-30 19:33 [PATCH] filter-branch: assume HEAD if no revision supplied Brandon Casey
2008-01-30 20:35 ` Johannes Schindelin
2008-01-30 21:03   ` Junio C Hamano [this message]
2008-01-30 23:35     ` Brandon Casey
2008-01-31  0:13       ` [PATCH 1/2] filter-branch: only print usage information when no arguments supplied Brandon Casey
2008-01-31  1:34         ` Junio C Hamano
2008-01-31  2:05           ` Brandon Casey
2008-01-31  2:44             ` Junio C Hamano
     [not found]       ` <1201738186-28132-1-git-send-email-casey@nrlssc.navy.mil>
2008-01-31  0:15         ` [PATCH 2/2] git-filter-branch.sh: don't use --default when calling rev-list Brandon Casey
2008-01-31  0:49           ` Johannes Schindelin
2008-01-31  1:35             ` Brandon Casey
2008-01-31  9:17               ` Andreas Ericsson
2008-01-31  9:27                 ` Junio C Hamano
2008-01-31 11:07                   ` Johannes Schindelin
2008-01-31  0:16       ` [PATCH] filter-branch: assume HEAD if no revision supplied Johannes Schindelin
2008-01-31  0:20         ` Brandon Casey
2008-01-31  0:41       ` [PATCH] filter-branch docs: remove brackets so not to imply revision arg is optional Brandon Casey
2008-01-31  1:22         ` Junio C Hamano
2008-01-31  1:53           ` Johannes Schindelin
2008-01-31 16:29           ` Brandon Casey
2008-01-31 21:53             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vk5lrgh56.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=casey@nrlssc.navy.mil \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).