From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Wed, 30 Jan 2008 23:35:03 GMT
Subject: Re: [PATCH] filter-branch: assume HEAD if no revision supplied
Message-ID: <47A109A7.1070502@nrlssc.navy.mil>
In-Reply-To: <7vk5lrgh56.fsf@gitster.siamese.dyndns.org>

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

The goal should be consistency in the user interface. New users will
always get confused. Lack of consistency could cause confusion for
experienced users. I sent a patch because it was intuitive to me for
filter-branch to operate on HEAD based on my git experience, and I was
surprised when it did not. For porcelain that take a revision argument
it seems common to default to HEAD.

I think the stash case is a little bit different because it was
actually causing problems for experienced users. A minor typo would
bite experienced people from time to time.

In that same consistency vein, I wonder if a user would be surprised
that 'git filter-branch' prints usage information but 'git filter-branch --'
operates on HEAD? Maybe the following patch would be better than the
compromise solution. (following in another email)

-brandon

PS. Please s/format-patch/filter-branch/ if I missed any. I keep
doing that.