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

> Junio C Hamano wrote:
> > 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).
> 
> That's what I was trying to do :)