subject:"git list files"

[PATCH 21/21] t3080: tests for git-list-files

2015-02-08 Thread Nguyễn Thái Ngọc Duy

Helped-by: Eric Sunshine 
Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 t/t3080-list-files.sh (new +x) | 134 +
 1 file changed, 134 insertions(+)
 create mode 100755 t/t3080-list-files.sh

diff --git a/t/t3080-list-files.sh b/t/t3080-list-files.sh
new file mode 100755
index 000..01b9662
--- /dev/null
+++ b/t/t3080-list-files.sh
@@ -0,0 +1,134 @@
+#!/bin/sh
+
+test_description='git list-files test'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+   mkdir dir &&
+   touch file dir/file &&
+   git init gitlink &&
+   ( cd gitlink && test_commit foo ) &&
+   git add file dir/file gitlink &&
+   git commit -qm1
+'
+
+test_expect_success 'LS_COLORS env variable' '
+   LS_COLORS="rs=0:fi=31:di=32" \
+   git list-files --color=always | test_decode_color | \
+   grep -v gitlink >actual &&
+   cat >expected <<-\EOF &&
+   dir
+   file
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'color.ls.*' '
+   test_config color.ls.file red &&
+   test_config color.ls.directory green &&
+   test_config color.ls.submodule yellow &&
+   git list-files --color=always | test_decode_color >actual &&
+       cat >expected <<-\EOF &&
+   dir
+   file
+   gitlink
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'column output' '
+   COLUMNS=20 git list-files --column=always >actual &&
+   cat >expected <<-\EOF &&
+   dir  gitlink
+   file
+       EOF
+   test_cmp expected actual &&
+   git list-files -1 >actual &&
+   cat >expected <<-\EOF &&
+   dir
+   file
+   gitlink
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success '--max-depth' '
+   git list-files --max-depth=1 >actual &&
+   cat >expected <<-\EOF &&
+       dir/file
+   file
+   gitlink
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'recursive' '
+   git list-files -R >actual &&
+   cat >expected <<-\EOF &&
+   dir/file
+   file
+   gitlink
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'globbing' '
+   git list-files "f*" >actual &&
+   cat >expected <<-\EOF &&
+   file
+   EOF
+   test_cmp expected actual &&
+   git list-files "**/f*" >actual &&
+   cat >expected <<-\EOF &&
+   dir/file
+   file
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'no dups' '
+   test_when_finished "git checkout file" &&
+   echo dirty >>file &&
+   git list-files -m file >actual &&
+   echo "file" >expected &&
+   test_cmp expected actual &&
+   git list-files -cm file >actual &&
+   echo "C file" >expected &&
+   test_cmp expected actual &&
+   git list-files -tcm file >actual &&
+   test_cmp expected actual
+'
+
+test_expect_success '--classify' '
+   git list-files -F >actual &&
+   cat >expected <<-\EOF &&
+   dir/
+   file
+   gitlink&
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'diff-cached' '
+   test_when_finished "git checkout file" &&
+   echo dirty >>file &&
+   git add file &&
+   git list-files -M >actual &&
+   echo "file" >expected &&
+   test_cmp expected actual
+'
+
+test_expect_success 'unmerged files' '
+   git ls-files --stage file >index-info &&
+   sed "s/ 0/ 2/;s/file/unmerged/" index-info | git update-index 
--index-info &&
+   sed "s/ 0/ 3/;s,file,dir/unmerged," index-info | git update-index 
--index-info &&
+   git list-files -u >actual &&
+   cat >expected <<-\EOF &&
+   dir
+   unmerged
+   EOF
+   test_cmp expected actual
+'
+
+test_done
-- 
2.3.0.rc1.137.g477eb31

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/21] t3080: tests for git-list-files

2015-01-28 Thread Duy Nguyen

On Wed, Jan 28, 2015 at 11:44 AM, Michael Blume  wrote:
> Test 3 is failing on my mac:
>
> expecting success:
> test_config color.ls.file red &&
> test_config color.ls.directory green &&
> test_config color.ls.submodule yellow &&
> git list-files --color=always >actual &&
> test_cmp "$TEST_DIRECTORY"/t3080/color_ls actual
>
> --- /Users/michael.blume/workspace/git/t/t3080/color_ls 2015-01-28
> 04:40:23.0 +
> +++ actual 2015-01-28 04:42:59.0 +
> @@ -1,3 +1,3 @@
> -dir
> -file
> -gitlink
> +dir
> +file
> +gitlink

Urgh.. colors do not send well over plain text.. I just realized we
have test_decode_color to convert colors to text descriptions.. will
fix..

Anyway, I think i may know why it fails. I suppose  the env variable
LS_COLORS is not defined, or defined as empty in your shell?
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/21] t3080: tests for git-list-files

2015-01-28 Thread Junio C Hamano

Michael Blume  writes:

> Test 3 is failing on my mac:
>
> expecting success:
> test_config color.ls.file red &&
> test_config color.ls.directory green &&
> test_config color.ls.submodule yellow &&
> git list-files --color=always >actual &&
> test_cmp "$TEST_DIRECTORY"/t3080/color_ls actual
>
> --- /Users/michael.blume/workspace/git/t/t3080/color_ls 2015-01-28
> 04:40:23.0 +
> +++ actual 2015-01-28 04:42:59.0 +
> @@ -1,3 +1,3 @@
> -dir
> -file
> -gitlink
> +dir
> +file
> +gitlink
> not ok 3 - color.ls.*

Same here on Ubuntu.

Regardless of the breakage in the code that violates the expectation
of this test, I do not think you would want to have test_cmp compare
coloured output directly without using test_decode_color.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/21] t3080: tests for git-list-files

2015-01-28 Thread Michael Blume

On Wed, Jan 28, 2015 at 2:19 AM, Duy Nguyen  wrote:
> On Wed, Jan 28, 2015 at 11:44 AM, Michael Blume  wrote:
>> Test 3 is failing on my mac:
>>
>> expecting success:
>> test_config color.ls.file red &&
>> test_config color.ls.directory green &&
>> test_config color.ls.submodule yellow &&
>> git list-files --color=always >actual &&
>> test_cmp "$TEST_DIRECTORY"/t3080/color_ls actual
>>
>> --- /Users/michael.blume/workspace/git/t/t3080/color_ls 2015-01-28
>> 04:40:23.0 +
>> +++ actual 2015-01-28 04:42:59.0 +
>> @@ -1,3 +1,3 @@
>> -dir
>> -file
>> -gitlink
>> +dir
>> +file
>> +gitlink
>
> Urgh.. colors do not send well over plain text.. I just realized we
> have test_decode_color to convert colors to text descriptions.. will
> fix..
>
> Anyway, I think i may know why it fails. I suppose  the env variable
> LS_COLORS is not defined, or defined as empty in your shell?
> --
> Duy


In case it helps:
https://www.dropbox.com/s/zsm3xgulmsl3rqm/Screenshot%202015-01-28%2009.46.57.png?dl=0

Also no, LS_COLORS is not defined

$ echo $LS_COLORS

$
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/21] t3080: tests for git-list-files

2015-01-27 Thread Michael Blume

Test 3 is failing on my mac:

expecting success:
test_config color.ls.file red &&
test_config color.ls.directory green &&
test_config color.ls.submodule yellow &&
git list-files --color=always >actual &&
test_cmp "$TEST_DIRECTORY"/t3080/color_ls actual

--- /Users/michael.blume/workspace/git/t/t3080/color_ls 2015-01-28
04:40:23.0 +
+++ actual 2015-01-28 04:42:59.0 +
@@ -1,3 +1,3 @@
-dir
-file
-gitlink
+dir
+file
+gitlink
not ok 3 - color.ls.*
#
# test_config color.ls.file red &&
# test_config color.ls.directory green &&
# test_config color.ls.submodule yellow &&
# git list-files --color=always >actual &&
# test_cmp "$TEST_DIRECTORY"/t3080/color_ls actual
#

On Sun, Jan 25, 2015 at 11:20 AM, Eric Sunshine  wrote:
> On Sun, Jan 25, 2015 at 7:37 AM, Nguyễn Thái Ngọc Duy  
> wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy 
>> ---
>> diff --git a/t/t3080-list-files.sh b/t/t3080-list-files.sh
>> new file mode 100755
>> index 000..6313dd9
>> --- /dev/null
>> +++ b/t/t3080-list-files.sh
>> +test_expect_success 'no dups' '
>> +   echo dirty >>file &&
>
> To leave a clean slate for subsequent tests, would it make sense to
> restore 'file' to a clean state via test_when_finished()?
>
>> +   git list-files -m file >actual &&
>> +   echo "file" >expected &&
>> +   test_cmp expected actual &&
>> +   git list-files -cm file >actual &&
>> +   echo "C file" >expected &&
>> +   test_cmp expected actual &&
>> +   git list-files -tcm file >actual &&
>> +   test_cmp expected actual
>> +'
>> +
>> +test_expect_success 'diff-cached' '
>> +   echo dirty >>file &&
>> +   git add file &&
>
> Ditto here?
>
>> +   git list-files -M >actual &&
>> +   echo "file" >expected &&
>> +   test_cmp expected actual
>> +'
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/21] t3080: tests for git-list-files

2015-01-25 Thread Eric Sunshine

On Sun, Jan 25, 2015 at 7:37 AM, Nguyễn Thái Ngọc Duy  wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
> diff --git a/t/t3080-list-files.sh b/t/t3080-list-files.sh
> new file mode 100755
> index 000..6313dd9
> --- /dev/null
> +++ b/t/t3080-list-files.sh
> +test_expect_success 'no dups' '
> +   echo dirty >>file &&

To leave a clean slate for subsequent tests, would it make sense to
restore 'file' to a clean state via test_when_finished()?

> +   git list-files -m file >actual &&
> +   echo "file" >expected &&
> +   test_cmp expected actual &&
> +   git list-files -cm file >actual &&
> +   echo "C file" >expected &&
> +   test_cmp expected actual &&
> +   git list-files -tcm file >actual &&
> +   test_cmp expected actual
> +'
> +
> +test_expect_success 'diff-cached' '
> +   echo dirty >>file &&
> +   git add file &&

Ditto here?

> +   git list-files -M >actual &&
> +   echo "file" >expected &&
> +   test_cmp expected actual
> +'
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 21/21] t3080: tests for git-list-files

2015-01-25 Thread Nguyễn Thái Ngọc Duy

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 t/t3080-list-files.sh (new +x) | 122 +
 t/t3080/color_ls (new) |   3 +
 t/t3080/ls_colors (new)|   2 +
 3 files changed, 127 insertions(+)
 create mode 100755 t/t3080-list-files.sh
 create mode 100644 t/t3080/color_ls
 create mode 100644 t/t3080/ls_colors

diff --git a/t/t3080-list-files.sh b/t/t3080-list-files.sh
new file mode 100755
index 000..6313dd9
--- /dev/null
+++ b/t/t3080-list-files.sh
@@ -0,0 +1,122 @@
+#!/bin/sh
+
+test_description='git list-files test'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+   mkdir dir &&
+   touch file dir/file &&
+   git init gitlink &&
+   ( cd gitlink && test_commit foo ) &&
+   git add file dir/file gitlink &&
+   git commit -qm1
+'
+
+test_expect_success 'LS_COLORS env variable' '
+   LS_COLORS="rs=0:fi=31:di=32" \
+   git list-files --color=always | grep -v gitlink >actual &&
+   test_cmp "$TEST_DIRECTORY"/t3080/ls_colors actual
+'
+
+test_expect_success 'color.ls.*' '
+       test_config color.ls.file red &&
+   test_config color.ls.directory green &&
+   test_config color.ls.submodule yellow &&
+       git list-files --color=always >actual &&
+   test_cmp "$TEST_DIRECTORY"/t3080/color_ls actual
+'
+
+test_expect_success 'column output' '
+   COLUMNS=20 git list-files --column=always >actual &&
+   cat >expected <<-\EOF &&
+   dir  gitlink
+   file
+   EOF
+   test_cmp expected actual &&
+   git list-files -1 >actual &&
+   cat >expected <<-\EOF &&
+   dir
+   file
+   gitlink
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success '--max-depth' '
+   git list-files --max-depth=1 >actual &&
+   cat >expected <<-\EOF &&
+   dir/file
+       file
+   gitlink
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'recursive' '
+   git list-files -R >actual &&
+   cat >expected <<-\EOF &&
+   dir/file
+   file
+   gitlink
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'globbing' '
+   git list-files "f*" >actual &&
+   cat >expected <<-\EOF &&
+   file
+   EOF
+   test_cmp expected actual &&
+   git list-files "**/f*" >actual &&
+   cat >expected <<-\EOF &&
+   dir/file
+       file
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'no dups' '
+   echo dirty >>file &&
+   git list-files -m file >actual &&
+   echo "file" >expected &&
+   test_cmp expected actual &&
+   git list-files -cm file >actual &&
+   echo "C file" >expected &&
+   test_cmp expected actual &&
+   git list-files -tcm file >actual &&
+   test_cmp expected actual
+'
+
+test_expect_success '--classify' '
+   git list-files -F >actual &&
+   cat >expected <<-\EOF &&
+   dir/
+   file
+   gitlink&
+   EOF
+   test_cmp expected actual
+'
+
+test_expect_success 'diff-cached' '
+   echo dirty >>file &&
+   git add file &&
+   git list-files -M >actual &&
+   echo "file" >expected &&
+   test_cmp expected actual
+'
+
+test_expect_success 'unmerged files' '
+   git ls-files --stage file >index-info &&
+   sed "s/ 0/ 2/;s/file/unmerged/" index-info | git update-index 
--index-info &&
+   sed "s/ 0/ 3/;s,file,dir/unmerged," index-info | git update-index 
--index-info &&
+   git list-files -u >actual &&
+   cat >expected <<-\EOF &&
+   dir
+   unmerged
+   EOF
+   test_cmp expected actual
+'
+
+test_done
diff --git a/t/t3080/color_ls b/t/t3080/color_ls
new file mode 100644
index 000..47f77ad
--- /dev/null
+++ b/t/t3080/color_ls
@@ -0,0 +1,3 @@
+[32mdir[m
+[31mfile[m
+[33mgitlink[m
diff --git a/t/t3080/ls_colors b/t/t3080/ls_colors
new file mode 100644
index 000..423c016
--- /dev/null
+++ b/t/t3080/ls_colors
@@ -0,0 +1,2 @@
+[32mdir[m
+[31mfile[m
-- 
2.2.0.84.ge9c7a8a

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/19] Add git-list-files

2014-12-02 Thread Jeff King

On Tue, Dec 02, 2014 at 06:45:52PM +0700, Duy Nguyen wrote:

> > As a side note, I wonder if it would be sensible to whitelist some
> > commands as porcelain, and allow aliases to override them (either
> > entirely, or just to add-in some options).
> 
> Agreed. Maybe not all porcelain (some like git-branch almost functions
> like plumbing).

Yeah, many things straddle the plumbing/porcelain line (e.g., "commit"
is porcelain, but it's basically the only sane way for scripts to make a
commit, so many use it). So I'd pick just a few things that should be
safe to override.

> We also need away to stop alias (e.g. in scripts).

Do we? I think the point of allowing this only for porcelain is that you
do not have to care about scripts. That is, a script running "git ls"
would get whatever the user's preferences are for "ls" output. A script
parsing the output of "ls" deserves whatever crap it gets.

> In scripts I can specify full path to a command to make sure I won't
> hit an alias. I guess we can't do the same here. The closet to "full
> path" is git-cmd form, as opposed to "git cmd" form) but I think we
> don't want to bring back git-cmd. Maybe just a "git --no-alias cmd"
> and GIT_NO_ALIAS..

Yeah, I think "--no-alias"/GIT_NO_ALIAS would work. But the problem is
one of compatibility. Scripts are not written to specify no-alias, so
you cannot just turn on the override-commands-with-aliases feature
immediately (and likewise, scripts have little incentive to bother
annotating their calls if it the override feature is not enabled).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/19] Add git-list-files

2014-12-02 Thread Michael J Gruber

Jeff King schrieb am 02.12.2014 um 06:42:
> On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
> 
>> This is something else that's been sitting in my tree for a while now.
>> It adds "git list-files", intended to be aliased as "ls" with your
>> favourite display options.
> 
> When I read the subject, I thought "why isn't this called git-ls?". Then
> when I read this paragraph, I thought "if the point is for everybody to
> make their own ls alias, why do we need list-files at all, instead of
> just adding options to ls-files"?
> 
> I'll let you decide which (if any) you'd like to answer. :)
> 
> My guesses:
> 
>   1. If it were "git-ls", it would stomp on existing aliases people have
>  constructed.
> 
>   2. If it is a wrapper around ls-files, then the options may be
>  constrained; ls-files already squats on useful options like "-d"
>  (which, if we are matching traditional ls, is more like our "-t").
> 
> I somewhat feel like (1) can be mitigated by the fact that your command
> is what people were probably trying to approximate with their aliases,
> and that as porcelain it should be very configurable (so they should be
> able to accomplish the same things as their aliases). But I dunno. I do
> not have an "ls" alias, so I am biased. :)
> 
> As a side note, I wonder if it would be sensible to whitelist some
> commands as porcelain, and allow aliases to override them (either
> entirely, or just to add-in some options).
> 
> -Peff
> 

I'd like to second all that ("+1", "like").

User friendly listing of files in the git repo is dearly needed, and
following names and default behaviour of mv/cp/ls is a way to follow the
principle of least surprise.

While "ls" might be an alias for many, I'm sure "stage" was for quite a
few people, too. We should be able to take any new name for new command,
regardless of aliases people may be using.

Allowing to alias at least porcelain commands, at least to the extent of
adding default options, is something we've talked about before and which
would have prevented us from the increasing bloat by the default
changing config knobs. "git -c ..." somehow took us down the other road.

I'm still dreaming of a git future where either "git foo --bar=baz" is
equivalent to "git -c foo.bar=baz foo" (i.e. unify the naming), or we
are simply able to alias "foo" to "foo --bar=baz" if that is what we
like as default (i.e. get rid of many of the special config knobs).

Right now, we have two "sets of options" with often differing names.

Also, we could ship a few commonly used aliases (such as co=checkout,
ci=commit, st=status) which could be overriden easily.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/19] Add git-list-files, a user friendly version of ls-files and more

2014-12-02 Thread Duy Nguyen

On Tue, Dec 2, 2014 at 9:50 AM, Eric Sunshine  wrote:
> On Sunday, November 30, 2014, Nguyễn Thái Ngọc Duy  wrote:
>>
>> This is more user friendly version of ls-files:
>>
>> * it's automatically colored and columnized
>> * it refreshes the index like all porcelain commands
>> * it defaults to non-recursive behavior like ls
>> * :(glob) is on by default so '*.c' means a.c but not a/b.c, use
>>   '**/*.c' for that.
>> * auto pager
>>
>> The name 'ls' is not taken. It is left for the user to make an alias
>> with better default options.
>
> I understand that your original version was named git-ls and that you
> renamed it to git-list-files in order to leave 'ls' available so users
> can create an 'ls' alias specifying their own default options. Would
> it make sense, however, to restore the name to git-ls and allow users
> to set default options via a config variable instead? Doing so would
> make the short-and-sweet git-ls command work for all users
> out-of-the-box, which might be well appreciated by Unix users.

Or I just make git-ls the first alias shipped by default.. I don't
really like using config var to define default options. Sounds like a
workaround to our alias. Jeff raised it elsewhere in this thread:

http://thread.gmane.org/gmane.comp.version-control.git/260423/focus=260538
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/19] Add git-list-files

2014-12-02 Thread Duy Nguyen

On Tue, Dec 2, 2014 at 12:42 PM, Jeff King  wrote:
> On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> This is something else that's been sitting in my tree for a while now.
>> It adds "git list-files", intended to be aliased as "ls" with your
>> favourite display options.
>
> When I read the subject, I thought "why isn't this called git-ls?". Then
> when I read this paragraph, I thought "if the point is for everybody to
> make their own ls alias, why do we need list-files at all, instead of
> just adding options to ls-files"?
>
> I'll let you decide which (if any) you'd like to answer. :)
>
> My guesses:
>
>   1. If it were "git-ls", it would stomp on existing aliases people have
>  constructed.

Yes, Matthew Moy (I think) at least had this git-ls alias and he did
complain. Also we could not agree on what should be the good defaults
for git-ls if it's built in.

>   2. If it is a wrapper around ls-files, then the options may be
>  constrained; ls-files already squats on useful options like "-d"
>  (which, if we are matching traditional ls, is more like our "-t").

Also right. I want to keep option names close to GNU ls.

> As a side note, I wonder if it would be sensible to whitelist some
> commands as porcelain, and allow aliases to override them (either
> entirely, or just to add-in some options).

Agreed. Maybe not all porcelain (some like git-branch almost functions
like plumbing).

We also need away to stop alias (e.g. in scripts). In scripts I can
specify full path to a command to make sure I won't hit an alias. I
guess we can't do the same here. The closet to "full path" is git-cmd
form, as opposed to "git cmd" form) but I think we don't want to bring
back git-cmd. Maybe just a "git --no-alias cmd" and GIT_NO_ALIAS..

And if  people now can override standard commands, I think it makes
sense to ship a default alias set (with lower priority than
user-defined aliases). After all people need to check twice if the
command they type really means what they think it is..
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/19] Add git-list-files

2014-12-02 Thread Duy Nguyen

On Tue, Dec 2, 2014 at 3:02 AM, Junio C Hamano  wrote:
> Does this contain a lot of borrowed code or something?  The style
> violation in the patches are unusually high, even compared with your
> other series.

The first one is from coreutils, but I reformatted (and trimmed) to
fit Git. I recall you had a script to spot style violation, right?
Where can I find the script? Else I'll reread CodingGuidlines again
and go through the patch.


> I've tried to fix it up and will push out the result on 'pu' if
> things work OK, but this does not even have tests, so it is unlikely
> that it would break anything but itself ;-)

Heh.. ;) Next version will come with tests. Thanks for the reminder.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/19] Add git-list-files

2014-12-01 Thread Jeff King

On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote:

> This is something else that's been sitting in my tree for a while now.
> It adds "git list-files", intended to be aliased as "ls" with your
> favourite display options.

When I read the subject, I thought "why isn't this called git-ls?". Then
when I read this paragraph, I thought "if the point is for everybody to
make their own ls alias, why do we need list-files at all, instead of
just adding options to ls-files"?

I'll let you decide which (if any) you'd like to answer. :)

My guesses:

  1. If it were "git-ls", it would stomp on existing aliases people have
 constructed.

  2. If it is a wrapper around ls-files, then the options may be
 constrained; ls-files already squats on useful options like "-d"
 (which, if we are matching traditional ls, is more like our "-t").

I somewhat feel like (1) can be mitigated by the fact that your command
is what people were probably trying to approximate with their aliases,
and that as porcelain it should be very configurable (so they should be
able to accomplish the same things as their aliases). But I dunno. I do
not have an "ls" alias, so I am biased. :)

As a side note, I wonder if it would be sensible to whitelist some
commands as porcelain, and allow aliases to override them (either
entirely, or just to add-in some options).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/19] Add git-list-files, a user friendly version of ls-files and more

2014-12-01 Thread Eric Sunshine

On Sunday, November 30, 2014, Nguyễn Thái Ngọc Duy  wrote:
>
> This is more user friendly version of ls-files:
>
> * it's automatically colored and columnized
> * it refreshes the index like all porcelain commands
> * it defaults to non-recursive behavior like ls
> * :(glob) is on by default so '*.c' means a.c but not a/b.c, use
>   '**/*.c' for that.
> * auto pager
>
> The name 'ls' is not taken. It is left for the user to make an alias
> with better default options.

I understand that your original version was named git-ls and that you
renamed it to git-list-files in order to leave 'ls' available so users
can create an 'ls' alias specifying their own default options. Would
it make sense, however, to restore the name to git-ls and allow users
to set default options via a config variable instead? Doing so would
make the short-and-sweet git-ls command work for all users
out-of-the-box, which might be well appreciated by Unix users.

More below.

> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
> diff --git a/Documentation/git-list-files.txt 
> b/Documentation/git-list-files.txt
> new file mode 100644
> index 000..3039e1e
> --- /dev/null
> +++ b/Documentation/git-list-files.txt
> @@ -0,0 +1,80 @@
> +git-list-files(1)
> +===
> +
> +NAME
> +
> +git-list-files - List files
> +
> +SYNOPSIS
> +
> +[verse]
> +'git list-files [options] [...]
> +
> +DESCRIPTION
> +---
> +List files (by default in current working directory) that are in the
> +index. Depending on the chosen options, maybe only modified files in
> +working tree are shown, or untracked files...
> +
> +OPTIONS
> +---
> +-c::
> +--cached::
> +   Show cached files (default)

I realize that this mirrors what is in git-ls-files.txt, but:

s/$/./

> +-d::
> +--deleted::
> +   Show cached files that are deleted on working directory

s/$/./

> +-m::
> +--modified::
> +   Show cached files that have modification on working directory

s/$/./

> +-o::
> +--others::
> +   Show untracked files (and only unignored ones unless -i is

s/-i/`-i`/

> +   specified)

s/$/./

> +-i::
> +--ignored::
> +   Show only ignored files. When showing files in the index,
> +   print only those matched by an exclude pattern. When showing
> +   "other" files, show only those matched by an exclude pattern.
> +
> +-u::
> +--unmerged::
> +   Show unmerged files

s/$/./

> +--color[=]::
> +--no-color::
> +   Color file names. The value must be `always`, `never`, or
> +   `auto`. `--no-color` is equivalent to
> +   `--color=never`. `--color` is equivalent to
> +   `--color=auto`. See configuration variable `color.list-files`
> +   for the default settings.
> +
> +--column[=]::
> +--no-column::
> +   Display files in columns. See configuration variable column.ui

s/column.ui/`column.ui`/

> +   for option syntax. `--column` and `--no-column` without options
> +   are equivalent to 'always' and 'never' respectively.
> +
> +--max-depth=::
> +   For each  given on command line, descend at most 
> +   levels of directories. A negative value means no limit.
> +   This option is ignored if  contains active wildcards.
> +   In other words if "a*" matches a directory named "a*",
> +   "*" is matched literally so --max-depth is still effective.
> +   The default is `--max-depth=0`.
> +
> +::
> +   Files to show. :(glob) magic is enabled and recursion disabled
> +   by default.
> +
> +SEE ALSO
> +
> +linkgit:git-ls-files[1]
> +
> +GIT
> +---
> +Part of the linkgit:git[1] suite
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/19] Add git-list-files

2014-12-01 Thread Junio C Hamano

Does this contain a lot of borrowed code or something?  The style
violation in the patches are unusually high, even compared with your
other series.

I've tried to fix it up and will push out the result on 'pu' if
things work OK, but this does not even have tests, so it is unlikely
that it would break anything but itself ;-)

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/19] Add git-list-files, a user friendly version of ls-files and more

2014-11-30 Thread Nguyễn Thái Ngọc Duy

This is more user friendly version of ls-files:

* it's automatically colored and columnized
* it refreshes the index like all porcelain commands
* it defaults to non-recursive behavior like ls
* :(glob) is on by default so '*.c' means a.c but not a/b.c, use
  '**/*.c' for that.
* auto pager

The name 'ls' is not taken. It is left for the user to make an alias
with better default options.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 .gitignore |  1 +
 Documentation/config.txt   | 10 +
 Documentation/git-list-files.txt (new) | 80 ++
 Makefile   |  1 +
 builtin/ls-files.c | 69 +++--
 command-list.txt   |  1 +
 git.c  |  1 +
 7 files changed, 159 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/git-list-files.txt

diff --git a/.gitignore b/.gitignore
index a052419..9727ecc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -76,6 +76,7 @@
 /git-init-db
 /git-interpret-trailers
 /git-instaweb
+/git-list-files
 /git-log
 /git-ls-files
 /git-ls-remote
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2290c47..74da715 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -940,6 +940,12 @@ color.status.::
to red). The values of these variables may be specified as in
color.branch..
 
+color.list-files::
+   A boolean to enable/disable color in the output of
+   linkgit:git-list-files[1]. May be set to `always`, `false` (or
+   `never`) or `auto` (or `true`), in which case colors are used
+   only when the output is to a terminal. Defaults to false.
+
 color.ls.::
Use customized color for file name colorization. If not set
and the environment variable LS_COLORS is set, color settings
@@ -1012,6 +1018,10 @@ column.clean::
Specify the layout when list items in `git clean -i`, which always
shows files and directories in columns. See `column.ui` for details.
 
+column.list-files::
+   Specify whether to output tag listing in `git list-files` in columns.
+   See `column.ui` for details.
+
 column.status::
Specify whether to output untracked files in `git status` in columns.
See `column.ui` for details.
diff --git a/Documentation/git-list-files.txt b/Documentation/git-list-files.txt
new file mode 100644
index 000..3039e1e
--- /dev/null
+++ b/Documentation/git-list-files.txt
@@ -0,0 +1,80 @@
+git-list-files(1)
+===
+
+NAME
+
+git-list-files - List files
+
+SYNOPSIS
+
+[verse]
+'git list-files [options] [...]
+
+DESCRIPTION
+---
+List files (by default in current working directory) that are in the
+index. Depending on the chosen options, maybe only modified files in
+working tree are shown, or untracked files...
+
+OPTIONS
+---
+-c::
+--cached::
+   Show cached files (default)
+
+-d::
+--deleted::
+   Show cached files that are deleted on working directory
+
+-m::
+--modified::
+   Show cached files that have modification on working directory
+
+-o::
+--others::
+   Show untracked files (and only unignored ones unless -i is
+   specified)
+
+-i::
+--ignored::
+   Show only ignored files. When showing files in the index,
+   print only those matched by an exclude pattern. When showing
+   "other" files, show only those matched by an exclude pattern.
+
+-u::
+--unmerged::
+   Show unmerged files
+
+--color[=]::
+--no-color::
+   Color file names. The value must be `always`, `never`, or
+   `auto`. `--no-color` is equivalent to
+   `--color=never`. `--color` is equivalent to
+   `--color=auto`. See configuration variable `color.list-files`
+   for the default settings.
+
+--column[=]::
+--no-column::
+   Display files in columns. See configuration variable column.ui
+   for option syntax. `--column` and `--no-column` without options
+   are equivalent to 'always' and 'never' respectively.
+
+--max-depth=::
+   For each  given on command line, descend at most 
+   levels of directories. A negative value means no limit.
+   This option is ignored if  contains active wildcards.
+   In other words if "a*" matches a directory named "a*",
+   "*" is matched literally so --max-depth is still effective.
+   The default is `--max-depth=0`.
+
+::
+   Files to show. :(glob) magic is enabled and recursion disabled
+   by default.
+
+SEE ALSO
+
+linkgit:git-ls-files[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Makefile b/Makefile
index 459121d..23a0751 100644
--- a/Makefile
+++ b/Makefile
@@ -587,6 +587,7 @@ BUILT_INS += git-cherry-pick$X
 BUILT_INS += git-format-patch$X
 BUILT_INS += git-fsck-objects$X
 BUILT_INS += git-init$X
+BUILT_INS += git-li

[PATCH 00/19] Add git-list-files

2014-11-30 Thread Nguyễn Thái Ngọc Duy

This is something else that's been sitting in my tree for a while now.
It adds "git list-files", intended to be aliased as "ls" with your
favourite display options.

As you can guess it's a friendlier version (and pretty close to GNU
ls) of ls-files. On one hand, I think this is a nice addition. On the
other hand, code bloat. Last version on the list is

http://thread.gmane.org/gmane.comp.version-control.git/244530/focus=245464

Nguyễn Thái Ngọc Duy (19):
  ls_colors.c: add $LS_COLORS parsing code
  ls_colors.c: parse color.ls.* from config file
  ls_colors.c: add a function to color a file name
  ls_colors.c: highlight submodules like directories
  ls-files: buffer full item in strbuf before printing
  ls-files: add --color to highlight file names
  ls-files: add --column
  ls-files: support --max-depth
  Add git-list-files, a user friendly version of ls-files and more
  list-files: -u does not imply showing stages
  list-files: add -R/--recursive short for --max-depth=-1
  list-files: add -1 short for --no-column
  list-files: add -t back
  list-files: sort output and remove duplicates
  list-files: do not show duplicate cached entries
  list-files: show directories as well as files
  list-files: add -F/--classify
  list-files -F: show submodules with the new indicator '&'
  list-files: -M aka diff-cached

 .gitignore |   1 +
 Documentation/config.txt   |  22 ++
 Documentation/git-list-files.txt (new) |  99 +++
 Documentation/git-ls-files.txt |  20 ++
 Makefile   |   2 +
 builtin/ls-files.c | 415 ---
 color.h|  10 +
 command-list.txt   |   1 +
 git.c  |   1 +
 ls_colors.c (new)  | 496 +
 10 files changed, 1034 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/git-list-files.txt
 create mode 100644 ls_colors.c

-- 
2.2.0.60.gb7b3c64

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 09/18] Add git-list-files, a user friendly version of ls-files and more

2014-03-30 Thread Nguyễn Thái Ngọc Duy

This is more user friendly version of ls-files:

* it's automatically colored and columnized
* it refreshes the index like all porcelain commands
* it defaults to non-recursive behavior like ls
* :(glob) is on by default so '*.c' means a.c but not a/b.c, use
  '**/*.c' for that.
* auto pager

The name 'ls' is not taken. It is left for the user to make an alias
with better default options.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 .gitignore |  1 +
 Documentation/config.txt   | 10 +
 Documentation/git-list-files.txt (new) | 80 ++
 Makefile   |  1 +
 builtin/ls-files.c | 69 +++--
 command-list.txt   |  1 +
 git.c  |  1 +
 7 files changed, 159 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/git-list-files.txt

diff --git a/.gitignore b/.gitignore
index dc600f9..faeac5d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -75,6 +75,7 @@
 /git-init
 /git-init-db
 /git-instaweb
+/git-list-files
 /git-log
 /git-ls-files
 /git-ls-remote
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6bca55e..e07e8bc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -909,6 +909,12 @@ color.status.::
to red). The values of these variables may be specified as in
color.branch..
 
+color.list-files::
+   A boolean to enable/disable color in the output of
+   linkgit:git-list-files[1]. May be set to `always`, `false` (or
+   `never`) or `auto` (or `true`), in which case colors are used
+   only when the output is to a terminal. Defaults to false.
+
 color.ls.::
Use customized color for file name colorization. If not set
and the environment variable LS_COLORS is set, color settings
@@ -981,6 +987,10 @@ column.clean::
Specify the layout when list items in `git clean -i`, which always
shows files and directories in columns. See `column.ui` for details.
 
+column.list-files::
+   Specify whether to output tag listing in `git list-files` in columns.
+   See `column.ui` for details.
+
 column.status::
Specify whether to output untracked files in `git status` in columns.
See `column.ui` for details.
diff --git a/Documentation/git-list-files.txt b/Documentation/git-list-files.txt
new file mode 100644
index 000..3039e1e
--- /dev/null
+++ b/Documentation/git-list-files.txt
@@ -0,0 +1,80 @@
+git-list-files(1)
+===
+
+NAME
+
+git-list-files - List files
+
+SYNOPSIS
+
+[verse]
+'git list-files [options] [...]
+
+DESCRIPTION
+---
+List files (by default in current working directory) that are in the
+index. Depending on the chosen options, maybe only modified files in
+working tree are shown, or untracked files...
+
+OPTIONS
+---
+-c::
+--cached::
+   Show cached files (default)
+
+-d::
+--deleted::
+   Show cached files that are deleted on working directory
+
+-m::
+--modified::
+   Show cached files that have modification on working directory
+
+-o::
+--others::
+   Show untracked files (and only unignored ones unless -i is
+   specified)
+
+-i::
+--ignored::
+   Show only ignored files. When showing files in the index,
+   print only those matched by an exclude pattern. When showing
+   "other" files, show only those matched by an exclude pattern.
+
+-u::
+--unmerged::
+   Show unmerged files
+
+--color[=]::
+--no-color::
+   Color file names. The value must be `always`, `never`, or
+   `auto`. `--no-color` is equivalent to
+   `--color=never`. `--color` is equivalent to
+   `--color=auto`. See configuration variable `color.list-files`
+   for the default settings.
+
+--column[=]::
+--no-column::
+   Display files in columns. See configuration variable column.ui
+   for option syntax. `--column` and `--no-column` without options
+   are equivalent to 'always' and 'never' respectively.
+
+--max-depth=::
+   For each  given on command line, descend at most 
+   levels of directories. A negative value means no limit.
+   This option is ignored if  contains active wildcards.
+   In other words if "a*" matches a directory named "a*",
+   "*" is matched literally so --max-depth is still effective.
+   The default is `--max-depth=0`.
+
+::
+   Files to show. :(glob) magic is enabled and recursion disabled
+   by default.
+
+SEE ALSO
+
+linkgit:git-ls-files[1]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Makefile b/Makefile
index f6a6e14..6104e05 100644
--- a/Makefile
+++ b/Makefile
@@ -584,6 +584,7 @@ BUILT_INS += git-cherry-pick$X
 BUILT_INS += git-format-patch$X
 BUILT_INS += git-fsck-objects$X
 BUILT_INS += git-init$X
+BUILT_INS += git-list-files$X
 BUILT_I

Re: git list files

2013-01-14 Thread Стойчо Слепцов

I went through your initial thread about blame-tree,
and it is really very very (+very) close to answer my question.

Thanks for writing it,
if it comes one day to git, I will use it.

As for:
'I guess people's eyes and brains are trained by the old school "file
boundaries matter" way of thinking'
-- Junio C Hamano
at http://thread.gmane.org/gmane.comp.version-control.git/168323;
http://article.gmane.org/gmane.comp.version-control.git/168333

I think it's not the case, Mr. Hamano.

>From my point of view, it is just to have a quick picture of "what
came from where in this current directory",
which is a normal reaction of human beings, I think.

Speaking of which I can't help thinking that this feature could be
provided by $git rev-list (HEAD) --no-walk -- , just don't stop
at first commit,
but at first commit for each of the paths.

Or maybe diff could have an option to not compare against a specific point,
but actually do his job and go downstears and find where the
_diff_erence for _each_ path happened finally.

(... applicable for $git status -l (--list) --porcelain ... but thats
a whim, sorry.)

Anyway,
thank you all for your time, it was a real pleasure for me,
Blind.

2013/1/14 Jeff King :
> On Sun, Jan 13, 2013 at 11:08:32PM -0800, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>>
>> > As far as I recall, that script works. However, I have a pure-C
>> > blame-tree implementation that is much faster, which may also be of
>> > interest. I need to clean up and put a few finishing touches on it to
>> > send it to the list, but it has been in production at GitHub for a few
>> > months. You can find it here:
>> >
>> >   git://github.com/peff/git jk/blame-tree
>>
>> Oh, neat.  Would that make sense as an item in
>> ?
>
> I'd rather finish cleaning it up and actually get it merged. It's on my
> todo list.
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git list files

2013-01-14 Thread Jeff King

On Sun, Jan 13, 2013 at 11:08:32PM -0800, Jonathan Nieder wrote:

> Jeff King wrote:
> 
> > As far as I recall, that script works. However, I have a pure-C
> > blame-tree implementation that is much faster, which may also be of
> > interest. I need to clean up and put a few finishing touches on it to
> > send it to the list, but it has been in production at GitHub for a few
> > months. You can find it here:
> >
> >   git://github.com/peff/git jk/blame-tree
> 
> Oh, neat.  Would that make sense as an item in
> ?

I'd rather finish cleaning it up and actually get it merged. It's on my
todo list.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git list files

2013-01-13 Thread Jonathan Nieder

Jeff King wrote:

> As far as I recall, that script works. However, I have a pure-C
> blame-tree implementation that is much faster, which may also be of
> interest. I need to clean up and put a few finishing touches on it to
> send it to the list, but it has been in production at GitHub for a few
> months. You can find it here:
>
>   git://github.com/peff/git jk/blame-tree

Oh, neat.  Would that make sense as an item in
?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git list files

2013-01-13 Thread Jeff King

On Sun, Jan 13, 2013 at 09:56:02AM -0800, Jonathan Nieder wrote:

> > lets, say the equivalent of the $ls -d b* within git.git root directory
> > would look like:
> >
> > 
> > 98746061 jrnieder 2010-08-12 17:11 Standardize-do-.-while-0-style   base85.c
> > c43cb386 pclouds  2012-10-26 22:53 Move-estimate_bisect_steps-to-li bisect.c
> > efc7df45 pclouds  2012-10-26 22:53 Move-print_commit_list-to-libgit bisect.h
> > 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.c
> > 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.h
> > ebcfa444 gitster  2012-07-23 20:56 Merge-branch-jn-block-sha1   
> > block-sha1
> 
> You might like Peff's or Jakub's tree blame script.  The newest version
> I can find is
> 
>  http://thread.gmane.org/gmane.comp.version-control.git/168323

As far as I recall, that script works. However, I have a pure-C
blame-tree implementation that is much faster, which may also be of
interest. I need to clean up and put a few finishing touches on it to
send it to the list, but it has been in production at GitHub for a few
months. You can find it here:

  git://github.com/peff/git jk/blame-tree

It's built on the regular diff traversal, just like the perl script you
linked, but doing it all in-process makes things fast.  I also added a
"--max-depth" parameter for diff, so you can do:

  git blame-tree --max-depth=1 -- Documentation

to recurse into the Documentation subdir, but not go into its
subdirectories. One of the things I need to clean up is that my counting
of --max-depth is different from that used by "git grep", and we would
probably want reconcile that.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git list files

2013-01-13 Thread Стойчо Слепцов

thanks alot, Jonathan,
I'll try to search through those scripts.

Blind.

2013/1/13 Jonathan Nieder :
> Hi,
>
> Стойчо Слепцов wrote:
>
>> lets, say the equivalent of the $ls -d b* within git.git root directory
>> would look like:
>>
>> 
>> 98746061 jrnieder 2010-08-12 17:11 Standardize-do-.-while-0-style   base85.c
>> c43cb386 pclouds  2012-10-26 22:53 Move-estimate_bisect_steps-to-li bisect.c
>> efc7df45 pclouds  2012-10-26 22:53 Move-print_commit_list-to-libgit bisect.h
>> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.c
>> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.h
>> ebcfa444 gitster  2012-07-23 20:56 Merge-branch-jn-block-sha1   
>> block-sha1
>
> You might like Peff's or Jakub's tree blame script.  The newest version
> I can find is
>
>  http://thread.gmane.org/gmane.comp.version-control.git/168323
>
> If you use it, let us know how it goes.
>
> Thanks for some food for thought,
> Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git list files

2013-01-13 Thread Стойчо Слепцов

not really,
ls-tree provides the hash of blobs and trees,
what I am searching for is"the last commit"who introduced the blob or tree.

but, hey, thanks for the answer!
Blind

2013/1/13 Matthieu Moy :
> Стойчо Слепцов  writes:
>
>> Hi,
>>
>> I was searching for some git- command to provide me a list of files
>> (in a git directory), same as ls,
>> but showing information from the last commit of the file instead.
>>
>> lets, say the equivalent of the $ls -d b* within git.git root directory
>> would look like:
>
> git ls-tree HEAD
>
> ?
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git list files

2013-01-13 Thread Jonathan Nieder

Hi,

Стойчо Слепцов wrote:

> lets, say the equivalent of the $ls -d b* within git.git root directory
> would look like:
>
> 
> 98746061 jrnieder 2010-08-12 17:11 Standardize-do-.-while-0-style   base85.c
> c43cb386 pclouds  2012-10-26 22:53 Move-estimate_bisect_steps-to-li bisect.c
> efc7df45 pclouds  2012-10-26 22:53 Move-print_commit_list-to-libgit bisect.h
> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.c
> 837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.h
> ebcfa444 gitster  2012-07-23 20:56 Merge-branch-jn-block-sha1   block-sha1

You might like Peff's or Jakub's tree blame script.  The newest version
I can find is

 http://thread.gmane.org/gmane.comp.version-control.git/168323

If you use it, let us know how it goes.

Thanks for some food for thought,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git list files

2013-01-13 Thread Matthieu Moy

Стойчо Слепцов  writes:

> Hi,
>
> I was searching for some git- command to provide me a list of files
> (in a git directory), same as ls,
> but showing information from the last commit of the file instead.
>
> lets, say the equivalent of the $ls -d b* within git.git root directory
> would look like:

git ls-tree HEAD

?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git list files

2013-01-13 Thread Стойчо Слепцов

Hi,

I was searching for some git- command to provide me a list of files
(in a git directory), same as ls,
but showing information from the last commit of the file instead.

lets, say the equivalent of the $ls -d b* within git.git root directory
would look like:


98746061 jrnieder 2010-08-12 17:11 Standardize-do-.-while-0-style   base85.c
c43cb386 pclouds  2012-10-26 22:53 Move-estimate_bisect_steps-to-li bisect.c
efc7df45 pclouds  2012-10-26 22:53 Move-print_commit_list-to-libgit bisect.h
837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.c
837d395a barkalow 2010-01-18 13:06 Replace-parse_blob-with-an-expla blob.h
ebcfa444 gitster  2012-07-23 20:56 Merge-branch-jn-block-sha1   block-sha1
d53a3503 pclouds  2012-06-07 19:05 Remove-i18n-legos-in-notifying-n branch.c
f9a482e6 peff 2012-03-26 19:51 checkout-suppress-tracking-messa branch.h
c566ea13 gitster  2013-01-11 18:34 Merge-branch-jc-merge-blobs  builtin
cf6c52fc gitster  2013-01-10 13:46 Merge-branch-jc-maint-fmt-merge- builtin.h
568508e7 gitster  2011-10-28 14:48 bulk-checkin-replace-fast-import
bulk-checkin.c
568508e7 gitster  2011-10-28 14:48 bulk-checkin-replace-fast-import
bulk-checkin.h
8c3710fd gitster  2012-06-04 11:51 tweak-bundle-verify-of-a-complet bundle.c
b76c561a gitster  2011-10-21 16:04 Merge-branch-jc-unseekable-bundl bundle.h


(pretty the same idea as what we see in github when reviewing a
repository under the "Files" tab.)

Unfortunately I couldn't find any suitable.

As suggested at http://git-scm.com/community I asked my question at
the "Git user mailing list on Google Groups which is a nice place for
beginners to ask about anything",
and one of the valuable answers was:

"Also I wouldn't hesitate to ask this question on the main Git list as
this question appears to be hard-core enough to warrant assisting of
someone knowledgeable about Git internals."

So here I am...

So is there such a command, or I have to build my own script, starting
from, lets say git-rev-list in addition with some diff?

At the beginning I was hoping that $git rev-list HEAD --no-walk
--all-match --  + some git status --porcelain could do the job
for me,
but seems git rev-list, same as git log stops at the first found
matching commit, without to take care that there are still more files
unsatisfied in the list...

isn't it supposed to satisfy all the files in the list when
--all-match --  are given?

Thank you in advance,
Blind.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 21/21] t3080: tests for git-list-files

Re: [PATCH 21/21] t3080: tests for git-list-files

Re: [PATCH 21/21] t3080: tests for git-list-files

Re: [PATCH 21/21] t3080: tests for git-list-files

Re: [PATCH 21/21] t3080: tests for git-list-files

Re: [PATCH 21/21] t3080: tests for git-list-files

[PATCH 21/21] t3080: tests for git-list-files

Re: [PATCH 00/19] Add git-list-files

Re: [PATCH 00/19] Add git-list-files

Re: [PATCH 09/19] Add git-list-files, a user friendly version of ls-files and more

Re: [PATCH 00/19] Add git-list-files

Re: [PATCH 00/19] Add git-list-files

Re: [PATCH 00/19] Add git-list-files

Re: [PATCH 09/19] Add git-list-files, a user friendly version of ls-files and more

Re: [PATCH 00/19] Add git-list-files

[PATCH 09/19] Add git-list-files, a user friendly version of ls-files and more

[PATCH 00/19] Add git-list-files

[PATCH v3 09/18] Add git-list-files, a user friendly version of ls-files and more

Re: git list files

Re: git list files

Re: git list files

Re: git list files

Re: git list files

Re: git list files

Re: git list files

Re: git list files

git list files

27 matches

Site Navigation

Mail list logo

Footer information