From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:14
"Shawn O. Pearce" [off-list ref] writes:
Petr Baudis [off-list ref] wrote:
quoted
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 <redacted>
Acked-by: Shawn O. Pearce <redacted>
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.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:14
Junio C Hamano [off-list ref] wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
Petr Baudis [off-list ref] wrote:
quoted
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 <redacted>
Acked-by: Shawn O. Pearce <redacted>
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.
Perhaps users should just do:
git config --global alias.unmerged 'ls-files -u'
?
Ok, well, maybe git.c should do that for you as a builtin.
--
Shawn.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:14
On Tue, 26 Aug 2008, Junio C Hamano wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
Petr Baudis [off-list ref] wrote:
quoted
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 <redacted>
Acked-by: Shawn O. Pearce <redacted>
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.
Doesn't "git status" tell you that? Or do you want the extra info from the
implicit --stage?
-Daniel
*This .sig left intentionally blank*
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:14
Daniel Barkalow [off-list ref] wrote:
On Tue, 26 Aug 2008, Junio C Hamano wrote:
quoted
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.
Doesn't "git status" tell you that? Or do you want the extra info from the
implicit --stage?
I think he doesn't want to see the other files that are already
merged successfully. git status shows them, git ls-files -u
does not.
--
Shawn.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:45:14
On Tue, 26 Aug 2008, Shawn O. Pearce wrote:
Daniel Barkalow [off-list ref] wrote:
quoted
On Tue, 26 Aug 2008, Junio C Hamano wrote:
quoted
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.
Doesn't "git status" tell you that? Or do you want the extra info from the
implicit --stage?
I think he doesn't want to see the other files that are already
merged successfully. git status shows them, git ls-files -u
does not.
I think it might make sense to support "git status --unmerged" or
something like that, where it filters the output by the tags it would
show.
-Daniel
*This .sig left intentionally blank*
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:17
On Tue, Aug 26, 2008 at 11:25:35AM -0700, Junio C Hamano wrote:
"Shawn O. Pearce" [off-list ref] writes:
quoted
Petr Baudis [off-list ref] wrote:
quoted
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 <redacted>
Acked-by: Shawn O. Pearce <redacted>
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:17
On Thu, Sep 04, 2008 at 12:23:50AM +0200, Petr Baudis wrote:
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?
It just occured to me - what about
git diff --diff-filter=U [--name-status]
or is that too long? (The universal answer being, "you can alias it".
;-)
Petr "Pasky" Baudis