Re: git tag --contains now takes a long time
On Sat Oct 17 15, Karthik Nayak wrote: On Sat, Oct 17, 2015 at 3:37 AM, Jerry Snitselaar wrote: Is this known and being looked into? I've seen a jump from 12 seconds to over 9 minutes with running git tag --contains on my kernel repo. This wasn't known, thanks for bringing it up. snits ~/dev/linux> git --version git version 2.6.1.145.gb27dacc snits ~/dev/linux> time git tag --contains 825fcfc next-20151012 next-20151013 v4.3-rc5 real9m4.765s user8m56.157s sys 0m2.450s snits ~/dev/linux> git --version git version 2.5.0.275.gac4cc86 snits ~/dev/linux> time git tag --contains 825fcfc next-20151012 next-20151013 v4.3-rc5 real0m12.842s user0m11.536s sys 0m1.098s b7cc53e92c806b73e14b03f60c17b7c29e52b4a4 is the first bad commit commit b7cc53e92c806b73e14b03f60c17b7c29e52b4a4 Author: Karthik Nayak Date: Fri Sep 11 20:36:16 2015 +0530 tag.c: use 'ref-filter' APIs Make 'tag.c' use 'ref-filter' APIs for iterating through refs, sorting and printing of refs. This removes most of the code used in 'tag.c' replacing it with calls to the 'ref-filter' library. Make 'tag.c' use the 'filter_refs()' function provided by 'ref-filter' to filter out tags based on the options set. For printing tags we use 'show_ref_array_item()' function provided by 'ref-filter'. We improve the sorting option provided by 'tag.c' by using the sorting options provided by 'ref-filter'. This causes the test 'invalid sort parameter on command line' in t7004 to fail, as 'ref-filter' throws an error for all sorting fields which are incorrect. The test is changed to reflect the same. Modify documentation for the same. Mentored-by: Christian Couder Mentored-by: Matthieu Moy Signed-off-by: Karthik Nayak Signed-off-by: Junio C Hamano As Junio mentioned I did notice ~13x slower speed. $ git version [12:02:08] git version 2.5.0.275.gac4cc86 $ time git tag --contains HEAD~300 [12:06:03] next-20150924 next-20151016 v4.3-rc1 v4.3-rc2 v4.3-rc3 v4.3-rc4 v4.3-rc5 git tag --contains HEAD~300 2.89s user 0.14s system 99% cpu 3.031 total After applying b7cc53e92c806b73e14b03f60c17b7c29e52b4a4 $ git version [12:07:33] git version 2.5.0.276.gb7cc53e $ time git tag --contains HEAD~300 [12:07:35] next-20150924 next-20151016 v4.3-rc1 v4.3-rc2 v4.3-rc3 v4.3-rc4 v4.3-rc5 ../Git/git tag --contains HEAD~300 38.30s user 0.19s system 99% cpu 38.519 total So I did poke around a little. I think I missed this out on the original commit (b7cc53e92c806b73e14b03f60c17b7c29e52b4a4). diff --git a/builtin/tag.c b/builtin/tag.c index 977a18c..2c5a9f1 100644 --- a/builtin/tag.c +++ b/builtin/tag.c @@ -49,6 +49,7 @@ static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting) format = "%(refname:short)"; verify_ref_format(format); + filter->with_commit_tag_algo = 1; filter_refs(&array, filter, FILTER_REFS_TAGS); ref_array_sort(sorting, &array); After applying this and running the test again, we get: $ git version [12:09:13] git version 2.5.0.276.gb7cc53e.dirty $ time git tag --contains HEAD~300 [12:12:00] next-20150924 next-20151016 v4.3-rc1 v4.3-rc2 v4.3-rc3 v4.3-rc4 v4.3-rc5 ../Git/git tag --contains HEAD~300 2.85s user 0.18s system 99% cpu 3.031 total Could you Squash that in, Junio? -- Regards, Karthik Nayak snits ~/dev/linux> time git tag --contains 825fcfc next-20151012 next-20151013 v4.3-rc5 real0m16.998s user0m12.539s sys 0m1.572s That worked for me. Tested-by: Jerry Snitselaar -- 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 v2 0/4] stripspace: Implement and use --count-lines option
On 2015-10-16 at 18:41:31 +0200, Junio C Hamano wrote: > Tobias Klauser writes: > > Be consistent with the subjects, please. > > > strbuf: make stripspace() part of strbuf > > s/make/make/ ;-) > > > stripspace: Use parse-options for command-line parsing > > s/Use/use/ > > > stripspace: Implement --count-lines option > > s/Implement/implement/ > > > git rebase -i: Use newly added --count-lines option for stripspace > > s/Use/use/ Will adjust all of them to lowercase for v3. Thanks. -- 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 v2 0/4] stripspace: Implement and use --count-lines option
On 2015-10-16 at 18:54:45 +0200, Matthieu Moy wrote: > Tobias Klauser writes: > > > - Split patch 2/3 into two patches: patch 2/4 switches git stripspace > > to use parse-options and patch 3/4 introduces the new option. > > Much better now. > > > - Implement line counting in cmd_stripbuf() instead of (ab-)using > > strbuf_stripspace() for it. > > Also short and sweet, I like it. > > > - Drop -C short option > > - Correct example command output in documentation. > > - Adjust commit messages to not include links to the wiki, fully > > describe the motivation in the commit message instead. > > Good. > > I read the patches again, and the whole series is now > > Reviewed-by: Matthieu Moy Thank you for the review! -- 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 v2 2/4] stripspace: Use parse-options for command-line parsing
On 2015-10-16 at 19:29:35 +0200, Junio C Hamano wrote: > Junio C Hamano writes: > > >> - if (mode == INVAL) > >> - usage(usage_msg); > > > > When given "git stripspace -s blorg", we used to set mode to INVAL > > and then showed the correct usage. But we no longer have a check > > that corresponds to the old INVAL thing, do we? Perhaps check argc > > to detect presence of an otherwise ignored non-option argument > > immediately after parse_options() returns? > > Perhaps like this. Thanks. I'll fold it into v3. > diff --git a/builtin/stripspace.c b/builtin/stripspace.c > index ac1ab3d..a8b7a93 100644 > --- a/builtin/stripspace.c > +++ b/builtin/stripspace.c > @@ -40,8 +40,9 @@ int cmd_stripspace(int argc, const char **argv, const char > *prefix) > OPT_END() > }; > > - argc = parse_options(argc, argv, prefix, options, stripspace_usage, > - PARSE_OPT_KEEP_DASHDASH); > + argc = parse_options(argc, argv, prefix, options, stripspace_usage, 0); > + if (argc) > + usage_with_options(stripspace_usage, options); > > if (mode == STRIP_COMMENTS || mode == COMMENT_LINES) > git_config(git_default_config, NULL); > -- 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 v2 2/4] stripspace: Use parse-options for command-line parsing
On 2015-10-16 at 19:07:34 +0200, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> > Use parse-options to parse command-line options instead of a
> > hand-crafted implementation.
> >
> > This is a preparatory patch to simplify the introduction of the
> > --count-lines option in a follow-up patch.
>
> The second paragraph is probably of much lessor importance than one
> thing you forgot to mention: the users can now use a unique prefix
> of the option and say "stripspace --comment".
I didn't even know about that feature, but now that you've mentioned it
I will certainly make use of it more in the future :) And of course,
I'll adjust the commit message accordingly for v3.
> > +enum stripspace_mode {
> > + STRIP_DEFAULT = 0,
> > + STRIP_COMMENTS,
> > + COMMENT_LINES
> > +};
> >
> > int cmd_stripspace(int argc, const char **argv, const char *prefix)
> > {
> > struct strbuf buf = STRBUF_INIT;
> > - int strip_comments = 0;
> > - enum { INVAL = 0, STRIP_SPACE = 1, COMMENT_LINES = 2 } mode =
> > STRIP_SPACE;
> > -
> > - if (argc == 2) {
> > - if (!strcmp(argv[1], "-s") ||
> > - !strcmp(argv[1], "--strip-comments")) {
> > - strip_comments = 1;
> > - } else if (!strcmp(argv[1], "-c") ||
> > - !strcmp(argv[1], "--comment-lines")) {
> > - mode = COMMENT_LINES;
> > - } else {
> > - mode = INVAL;
> > - }
> > - } else if (argc > 1) {
> > - mode = INVAL;
> > - }
> > -
> > - if (mode == INVAL)
> > - usage(usage_msg);
>
> When given "git stripspace -s blorg", we used to set mode to INVAL
> and then showed the correct usage. But we no longer have a check
> that corresponds to the old INVAL thing, do we? Perhaps check argc
> to detect presence of an otherwise ignored non-option argument
> immediately after parse_options() returns?
Agreed, we should check it. I'll go with the implementation you
suggested in the follow-up message.
> > - if (strip_comments || mode == COMMENT_LINES)
> > + enum stripspace_mode mode = STRIP_DEFAULT;
> > +
> > + const struct option options[] = {
> > + OPT_CMDMODE('s', "strip-comments", &mode,
> > + N_("skip and remove all lines starting with comment
> > character"),
> > + STRIP_COMMENTS),
> > + OPT_CMDMODE('c', "comment-lines", &mode,
> > + N_("prepend comment character and blank to each
> > line"),
> > + COMMENT_LINES),
> > + OPT_END()
> > + };
> > +
> > + argc = parse_options(argc, argv, prefix, options, stripspace_usage,
> > +PARSE_OPT_KEEP_DASHDASH);
>
> What is the point of keep-dashdash here?
Likewise, it shouldn't be there as in your follow-up patch.
--
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 2/3] stripspace: Implement --count-lines option
On 2015-10-16 at 19:35:49 +0200, Junio C Hamano wrote:
> Tobias Klauser writes:
>
> >> So this is your output code, which gives only the number of lines
> >> without the cleaned up result.
> >
> > This should better be a simple printf("%zu\n", lines) I guess?
>
> I think we actively avoid using %z conversion that is only C99.
>
> If you really want to, you could count in size_t and use %lu with
> appropriate casting, which I think is what we do in the rest of the
> codebase.
>
> For this one, I think it is sufficient to just count in int and
> print as int with %d, though.
Ok, will use an int to count and printf("%d\n").
--
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
dead link on manual page
Hi, In the last sentence of page http://www.git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository I found a dead link to page http://www.git-scm.com/book/en/v2/1-git-server/_git_on_the_server (this dead link also appears on the paragraph "Cloning an Existing Repository", half a screen above the end) That should be replaced by: http://www.git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server -- 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 PULL] l10n updates for 2.6 maint branch
Hi Junio, Please pull the following into the maint branch. It includes l10n updates in Russian which missed the update window for 2.6. The following changes since commit 8d530c4d64ffcc853889f7b385f554d53db375ed: Git 2.6-rc3 (2015-09-21 13:26:13 -0700) are available in the git repository at: git://github.com/git-l10n/git-po maint for you to fetch changes up to 82aa9b751fe96c5e55c36819aedea3d47e98bb57: l10n: ru.po: update Russian translation (2015-09-30 18:01:23 +0300) Dimitriy Ryazantcev (1): l10n: ru.po: update Russian translation po/ru.po | 3550 ++ 1 file changed, 1967 insertions(+), 1583 deletions(-) -- 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: submodule: allow submodule directory in gitignore
2015-10-12 14:30 GMT+08:00 Aleksey Komarov : > Hi all! > > I'm sorry if the letter came twice. I have troubles with my post client. > > I want to organize my repository so its submodules would be located at the > root > of repository. I'm trying to create .gitignore to ignore all files and don't > ignore directories at the same time: > > $ cat .gitignore > * > !*/ > > Now, I'm trying to add a submodule to my repository, but fail to understand > why > my .gitignore prevents it from being added. I use the following command to > check > if my submodule will be ignored or not: > > $ git add --dry-run --ignore-missing c/ > > I have noticed that result of this check is different when directory c/ > already > exists and when it still doesn't by the time of the check. > The described behavior is illustrated by the following example: > > $ mkdir git_test > $ cd git_test > $ git init > Initialized empty Git repository in D:/temp/git_test/.git/ > $ echo \* >> .gitignore > $ echo \!\*\/ >> .gitignore > $ git add --dry-run --ignore-missing c/ > The following paths are ignored by one of your .gitignore files: > c/ > Use -f if you really want to add them. > $ mkdir c > $ git add --dry-run --ignore-missing c/ > $ > To check how an entry (c/) is affected by .gitignore in different cases, you can try this command: $ git check-ignore -v c/ -- 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 tag --contains now takes a long time
Karthik Nayak writes: > Could you Squash that in, Junio? The guilty commit is in master, so you'll need a new commit to fix the old one. Can you send a patch with a proper commit message (referencing b7cc53e92c806b73e14b03f60c17b7c29e52b4a4)? We should both have catched this earlier (by review and/or benchmark). Sorry we didn't, and thanks to Jerry for the report. -- 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 tag --contains now takes a long time
On Sat, Oct 17, 2015 at 9:28 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> Could you Squash that in, Junio? > > The guilty commit is in master, so you'll need a new commit to fix the > old one. Can you send a patch with a proper commit message (referencing > b7cc53e92c806b73e14b03f60c17b7c29e52b4a4)? > > We should both have catched this earlier (by review and/or benchmark). > Sorry we didn't, and thanks to Jerry for the report. > Yea, I'm surprised we didn't notice. Either ways, I'll reply with a fix commit :) -- Regards, Karthik Nayak -- 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] tag.c: use the correct algorithm for the '--contains' option
In b7cc53e92c806b73e14b03f60c17b7c29e52b4a4 we port tag.c to use ref-filter APIs for filtering and printing refs. But that commit missed out on setting 'filter->with_commit_tag_algo' which would ensure the correct algorithm is used for the '--contains' option. As reported by Jerry Snitselaar, this causes the option to work way slower than expected, fix this by setting 'filter->with_commit_tag_algo' in tag.c before calling 'filter_refs()'. Mentored-by: Christian Couder Mentored-by: Matthieu Moy Signed-off-by: Karthik Nayak Tested-by: Jerry Snitselaar --- builtin/tag.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/tag.c b/builtin/tag.c index 977a18c..2c5a9f1 100644 --- a/builtin/tag.c +++ b/builtin/tag.c @@ -49,6 +49,7 @@ static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting) format = "%(refname:short)"; verify_ref_format(format); + filter->with_commit_tag_algo = 1; filter_refs(&array, filter, FILTER_REFS_TAGS); ref_array_sort(sorting, &array); -- 2.6.1 -- 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] Add ls-files --eol-staged, --eol-worktree
Make it possible to show the line endings of files.
Files which are staged and/or files in the working tree:
git ls-files --eol-staged
git ls-files --eol-worktree
Both will show an output like this:
emptyempty_file
bin binary_file_or_with_cr_handled_as_binary
txt-crlf text_file_with_crlf
txt-mix text_file_with_crlf_and_lf
txt-lf text_file_with_lf
txt text_file_with_no_eol_at_all
Implementation details:
Make struct text_stat, is_binary() and gather_stats() from convert.c
public, add a new function get_convert_stats_ascii() and use it
in and use them in ls-files.
git ls-files --eol-staged will give a line like this:
Signed-off-by: Torsten Bögershausen
---
This needs to go on top of tb/t0027-crlf
builtin/ls-files.c | 21 +
convert.c | 51 +--
convert.h | 14 ++
3 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index b6a7cb0..c989e94 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -27,6 +27,8 @@ static int show_killed;
static int show_valid_bit;
static int line_terminator = '\n';
static int debug_mode;
+static int show_eol_staged;
+static int show_eol_wt;
static const char *prefix;
static int max_prefix_len;
@@ -68,6 +70,11 @@ static void show_dir_entry(const char *tag, struct dir_entry
*ent)
return;
fputs(tag, stdout);
+ if (show_eol_wt) {
+ printf("%s ", get_convert_stats_ascii(ent->name,
+
GET_CONVERT_STATS_ASCII_WT, 0));
+ }
+
write_name(ent->name);
}
@@ -170,6 +177,14 @@ static void show_ce_entry(const char *tag, const struct
cache_entry *ce)
find_unique_abbrev(ce->sha1,abbrev),
ce_stage(ce));
}
+ if (show_eol_staged) {
+ printf("%s ",
+get_convert_stats_ascii(ce->name,
GET_CONVERT_STATS_ASCII_BLOB, 0));
+ }
+ if (show_eol_wt) {
+ printf("%s ",
get_convert_stats_ascii(ce->name,GET_CONVERT_STATS_ASCII_WT,
+
ce->ce_stat_data.sd_size));
+ }
write_name(ce->name);
if (debug_mode) {
const struct stat_data *sd = &ce->ce_stat_data;
@@ -206,6 +221,10 @@ static void show_ru_info(void)
printf("%s%06o %s %d\t", tag_resolve_undo, ui->mode[i],
find_unique_abbrev(ui->sha1[i], abbrev),
i + 1);
+ if (show_eol_wt) {
+ printf("%s ",
+
get_convert_stats_ascii(path, GET_CONVERT_STATS_ASCII_WT, 0));
+ }
write_name(path);
}
}
@@ -433,6 +452,8 @@ int cmd_ls_files(int argc, const char **argv, const char
*cmd_prefix)
OPT_BIT(0, "directory", &dir.flags,
N_("show 'other' directories' names only"),
DIR_SHOW_OTHER_DIRECTORIES),
+ OPT_BOOL(0, "eol-staged", &show_eol_staged, N_("show line
endings of the staged file")),
+ OPT_BOOL(0, "eol-worktree", &show_eol_wt, N_("show line endings
of the file in work tree")),
OPT_NEGBIT(0, "empty-directory", &dir.flags,
N_("don't show empty directories"),
DIR_HIDE_EMPTY_DIRECTORIES),
diff --git a/convert.c b/convert.c
index 814e814..a1c24cd 100644
--- a/convert.c
+++ b/convert.c
@@ -22,15 +22,7 @@ enum crlf_action {
CRLF_AUTO
};
-struct text_stat {
- /* NUL, CR, LF and CRLF counts */
- unsigned nul, cr, lf, crlf;
-
- /* These are just approximations! */
- unsigned printable, nonprintable;
-};
-
-static void gather_stats(const char *buf, unsigned long size, struct text_stat
*stats)
+void gather_stats(const char *buf, unsigned long size, struct text_stat *stats)
{
unsigned long i;
@@ -76,7 +68,7 @@ static void gather_stats(const char *buf, unsigned long size,
struct text_stat *
/*
* The same heuristics as diff.c::mmfile_is_binary()
*/
-static int is_binary(unsigned long size, struct text_stat *stats)
+int is_binary(unsigned long size, struct text_stat *stats)
{
if (stats->nul)
@@ -95,6 +87,45 @@ static int is_binary(unsigned long size, struct text_stat
*stats)
return 0;
}
+
+const char *gather_stats_ascii(const char *data, unsigned long size)
+{
+ struct text_stat stats;
+ if (!data || !size)
+ return("empty ");
+ gather_stats(data, size, &
Re: [PATCH v2 2/4] stripspace: Use parse-options for command-line parsing
Tobias Klauser writes: > On 2015-10-16 at 19:29:35 +0200, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> >> - if (mode == INVAL) >> >> - usage(usage_msg); >> > >> > When given "git stripspace -s blorg", we used to set mode to INVAL >> > and then showed the correct usage. But we no longer have a check >> > that corresponds to the old INVAL thing, do we? Perhaps check argc >> > to detect presence of an otherwise ignored non-option argument >> > immediately after parse_options() returns? >> >> Perhaps like this. > > Thanks. I'll fold it into v3. Before starting v3, please fetch from me and check what is queued on 'pu'. It may turn out that the fix-ups I did while queuing this round is sufficient, in which case you can just say that instead ;-) Thanks. -- 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 tag --contains now takes a long time
Karthik Nayak writes: > So I did poke around a little. I think I missed this out on the > original commit (b7cc53e92c806b73e14b03f60c17b7c29e52b4a4). > > diff --git a/builtin/tag.c b/builtin/tag.c > index 977a18c..2c5a9f1 100644 > --- a/builtin/tag.c > +++ b/builtin/tag.c > @@ -49,6 +49,7 @@ static int list_tags(struct ref_filter *filter, > struct ref_sorting *sorting) > format = "%(refname:short)"; > > verify_ref_format(format); > + filter->with_commit_tag_algo = 1; > filter_refs(&array, filter, FILTER_REFS_TAGS); > ref_array_sort(sorting, &array); > ... > > Could you Squash that in, Junio? Do we have two implementations that are supposed to compute the same thing, and with the bit set to 1, the faster of these two is used? Is there a reason somebody may want to use the slower one? What difference other than performance does the choice of this bit makes, and why? I think the answers to the above questions deserve to be in the log message (no, I do not think I can "squash it in", rewriting the commit that has already been merged to 'next' and 'master'). Thanks. -- 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 v2 3/4] stripspace: Implement --count-lines option
On Fri, Oct 16, 2015 at 11:16 AM, Tobias Klauser wrote: > Implement the --count-lines options for git stripspace [...] > > This will make it easier to port git-rebase--interactive.sh to C later > on. Is there any application beyond git-rebase--interactive where a --count-lines options is expected to be useful? It's not obvious from the commit message that this change is necessarily a win for later porting of git-rebase--interactive to C since the amount of extra code and support material added by this patch probably outweighs the amount of code a C version of git-rebase--interactive would need to count the lines itself. Stated differently, are the two or three instances of piping through 'wc' in git-rebase--interactive sufficient justification for introducing extra complexity into git-stripspace and its documentation and tests? More below. > Furthermore, add the corresponding documentation and tests. > > Signed-off-by: Tobias Klauser > --- > diff --git a/t/t0030-stripspace.sh b/t/t0030-stripspace.sh > index 29e91d8..9c00cb9 100755 > --- a/t/t0030-stripspace.sh > +++ b/t/t0030-stripspace.sh > @@ -438,4 +438,40 @@ test_expect_success 'avoid SP-HT sequence in commented > line' ' > test_cmp expect actual > ' > > +test_expect_success '--count-lines with newline only' ' > + printf "0\n" >expect && > + printf "\n" | git stripspace --count-lines >actual && > + test_cmp expect actual > +' What is the expected behavior when the input is an empty file, a file with content but no newline, a file with one or more lines but lacking a newline on the final line? Should these cases be tested, as well? > +test_expect_success '--count-lines with single line' ' > + printf "1\n" >expect && > + printf "foo\n" | git stripspace --count-lines >actual && > + test_cmp expect actual > +' > + > +test_expect_success '--count-lines with single line preceeded by empty line' > ' > + printf "1\n" >expect && > + printf "\nfoo" | git stripspace --count-lines >actual && > + test_cmp expect actual > +' > + > +test_expect_success '--count-lines with single line followed by empty line' ' > + printf "1\n" >expect && > + printf "foo\n\n" | git stripspace --count-lines >actual && > + test_cmp expect actual > +' > + > +test_expect_success '--count-lines with multiple lines and consecutive > newlines' ' > + printf "5\n" >expect && > + printf "\none\n\n\nthree\nfour\nfive\n" | git stripspace > --count-lines >actual && > + test_cmp expect actual > +' > + > +test_expect_success '--count-lines combined with --strip-comments' ' > + printf "5\n" >expect && > + printf "\n# stripped\none\n#stripped\n\nthree\nfour\nfive\n" | git > stripspace -s --count-lines >actual && > + test_cmp expect actual > +' > + > test_done > -- > 2.6.1.148.g7927db1 -- 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] Add ls-files --eol-staged, --eol-worktree
On Sat, Oct 17, 2015 at 4:18 PM, Torsten Bögershausen wrote:
> Make it possible to show the line endings of files.
> Files which are staged and/or files in the working tree:
>
> git ls-files --eol-staged
> git ls-files --eol-worktree
>
> Both will show an output like this:
>
> emptyempty_file
> bin binary_file_or_with_cr_handled_as_binary
> txt-crlf text_file_with_crlf
> txt-mix text_file_with_crlf_and_lf
> txt-lf text_file_with_lf
> txt text_file_with_no_eol_at_all
>
> Implementation details:
> Make struct text_stat, is_binary() and gather_stats() from convert.c
> public, add a new function get_convert_stats_ascii() and use it
> in and use them in ls-files.
s/and use it in and use them in/and use them in/
> git ls-files --eol-staged will give a line like this:
"... line like this:" what?
> Signed-off-by: Torsten Bögershausen
> ---
> --- a/builtin/ls-files.c
> +++ b/builtin/ls-files.c
> @@ -68,6 +70,11 @@ static void show_dir_entry(const char *tag, struct
> dir_entry *ent)
> return;
>
> fputs(tag, stdout);
> + if (show_eol_wt) {
> + printf("%s ", get_convert_stats_ascii(ent->name,
> +
>
> GET_CONVERT_STATS_ASCII_WT, 0));
Whitespace-damaged patch?
> + }
Style: unnecessary braces
> +
> write_name(ent->name);
> }
>
> @@ -170,6 +177,14 @@ static void show_ce_entry(const char *tag, const struct
> cache_entry *ce)
>find_unique_abbrev(ce->sha1,abbrev),
>ce_stage(ce));
> }
> + if (show_eol_staged) {
> + printf("%s ",
> +get_convert_stats_ascii(ce->name,
> GET_CONVERT_STATS_ASCII_BLOB, 0));
> + }
> + if (show_eol_wt) {
> + printf("%s ",
> get_convert_stats_ascii(ce->name,GET_CONVERT_STATS_ASCII_WT,
> +
>
> ce->ce_stat_data.sd_size));
> + }
Style: unnecessary braces (both cases)
> write_name(ce->name);
> if (debug_mode) {
> const struct stat_data *sd = &ce->ce_stat_data;
> @@ -206,6 +221,10 @@ static void show_ru_info(void)
> printf("%s%06o %s %d\t", tag_resolve_undo,
> ui->mode[i],
>find_unique_abbrev(ui->sha1[i], abbrev),
>i + 1);
> + if (show_eol_wt) {
> + printf("%s ",
> +
> get_convert_stats_ascii(path, GET_CONVERT_STATS_ASCII_WT, 0));
> + }
Style: unnecessary braces
> write_name(path);
> }
> }
> @@ -433,6 +452,8 @@ int cmd_ls_files(int argc, const char **argv, const char
> *cmd_prefix)
> OPT_BIT(0, "directory", &dir.flags,
> N_("show 'other' directories' names only"),
> DIR_SHOW_OTHER_DIRECTORIES),
> + OPT_BOOL(0, "eol-staged", &show_eol_staged, N_("show line
> endings of the staged file")),
> + OPT_BOOL(0, "eol-worktree", &show_eol_wt, N_("show line
> endings of the file in work tree")),
> OPT_NEGBIT(0, "empty-directory", &dir.flags,
> N_("don't show empty directories"),
> DIR_HIDE_EMPTY_DIRECTORIES),
> --- a/convert.c
> +++ b/convert.c
> @@ -95,6 +87,45 @@ static int is_binary(unsigned long size, struct text_stat
> *stats)
> return 0;
> }
>
> +
Style: unnecessary blank line
> +const char *gather_stats_ascii(const char *data, unsigned long size)
Is this name too generic? This implementation is specialized for
summarizing EOL state, but it is conceivable that there may be other
meaningful textual representations of struct text_stat, as well, so
perhaps this name ought to better reflect the EOL-centric textual
representation of this implementation.
> +{
> + struct text_stat stats;
> + if (!data || !size)
> + return("empty ");
Would it make sense to distinguish between an empty file/blob and one
which was not found?
if (!data)
return "missing";
if (!size)
return "empy";
> + gather_stats(data, size, &stats);
> + if (is_binary(size, &stats))
> + return("bin ");
Style: unnecessary parentheses on 'return'
> + else if (stats.cr != stats.crlf)
Style (nit): unnecessary 'else'
> + return("bin ");
> + else if (stats.crlf && (stats.crlf == stats.lf))
> + return("txt-crlf");
> + else if (stats.crlf && stats.lf)
> + return("txt-mix ");
> +
Re: dead link on manual page
On Sat, Oct 17, 2015 at 6:33 PM, Jaap Droogers wrote: > Hi, Hi Jaap, > In the last sentence of page > http://www.git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository I > found a dead link to page > http://www.git-scm.com/book/en/v2/1-git-server/_git_on_the_server > (this dead link also appears on the paragraph "Cloning an Existing > Repository", half a screen above the end) > > That should be replaced by: > http://www.git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server Yeah, it's a known bug. It has to do with the Atlas HTML build IIRC. See https://github.com/git/git-scm.com/issues/588 -- 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 worktree help inconsistent
Using git 2.6.1 In git command line usage, Please mark optional, the man page is correct. $ git worktree add usage: git worktree add [] or: git worktree prune [] -f, --force checkout even if already checked out in other worktree -bcreate a new branch -Bcreate or reset a branch --detach detach HEAD at named commit But in man page, git worktree add [-f] [--detach] [-b ] [] git worktree prune [-n] [-v] [--expire ] -- 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
допоможіть нашому сайту http://schoolsite.pp.ua/ - будь ласка, відкрийте його для перегляду однієї-двох сторінок
Доброго дня, будь ласка, просимо переглянути наш сайт, якщо це не важко для вас, http://schoolsite.pp.ua/ - будь ласка, відкрийте його для перегляду однієї-двох сторінок, і на будь-якій сторінці один раз натисніть на рекламний банер, який вам найбільш цікавий, це Ваша допомога, щоб ми могли заплатити за хостинг нашого сайту, дякуємо, системний адміністратор ad...@schoolsite.pp.ua http://schoolsite.pp.ua/ hello, our school site require you view, please, if it's not hard for you, http://schoolsite.pp.ua/ - please open it for viewing our site - one or two pages, and on any page, click once on the advertising banner that most interesting for you, it is your help to pay for hosting our school site, thank you system Administrator ad...@schoolsite.pp.ua http://schoolsite.pp.ua/ Здравствуйте, просим просмотреть наш сайт, если это не трудно для вас, http://schoolsite.pp.ua/ - пожалуйста, откройте его для просмотра одной-двух страниц, и на любой странице один раз нажмите на рекламный баннер, который вам наиболее интересен, это Ваша помощь, чтобы мы могли заплатить за хостинг нашего сайта, спасибо системный администратор ad...@schoolsite.pp.ua http://schoolsite.pp.ua/ -- 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
