Hi, On Wed, 30 Jan 2008, Brandon Casey wrote: > Junio C Hamano wrote: > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 :) But then you would have to keep the test for $#, but enhance it like this: case "$#,$filter_env,$filter_tree,$filter_index,$filter_parent,\ $filter_msg,$filter_commit,$filter_tag_name,$filter_subdir" in 0,,,,,cat,'git commit-tree "$@"',) usage esac Yes, it's ugly. Another method would be having the test _before_ the while loop. ;-) Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
