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