On Tue, Aug 26, 2008 at 11:25:35AM -0700, Junio C Hamano wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > Petr Baudis <pasky@xxxxxxx> wrote: > >> git <tab><tab> still shows way too many commands, some of them > >> are clearly plumbing. This patch hides the plumbing commands > >> liberally (that is, in special cases, users still might want to > >> call one of the hidden commands, a *normal* workflow should never > >> involve these, though - and if it does, we have a UI problem anyway). > >> > >> Signed-off-by: Petr Baudis <pasky@xxxxxxx> > > > > Acked-by: Shawn O. Pearce <spearce@xxxxxxxxxxx> > > > > Though I use git ls-remote at least once every other day to see > > what branches are available on my egit/spearce.git fork. Its ok, > > I guess I can type a few extra characters... > > Revision-requested-by: me > > Unless/until we have an easy way to obtain the information "git-ls-files > -u" gives during conflict resolution, ls-files should stay on the list of > commonly used commands. I started on a patch, but frankly, I hate it. Adding such a filtering to git-status is quite invasive, while I believe that it's simply not worth it - I have yet to encounter a situation with git when simply looking at either git diff or plain git status is impractical to check which files need to be merged yet, so I don't want to expend energy on a patch which is going to be ugly and useless by my belief. If you do insist that we need this functionality, can you please just drop the git ls-files bit from the patch, or should I resend it? Thanks, -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates -- 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
