Re: [PATCH] filter-branch: assume HEAD if no revision supplied

> 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).