Re: [PATCH] Add ls-files --eol-staged, --eol-worktree
From: "Torsten Bögershausen"
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
I think that this last generic 'txt' should be explicit, e.g. 'txt-no-eols',
so that the categories are explicit and mutually exclusive.
Also, does this need a documentation update for the options, and can the
distinction between txt and bin be documented /referenced.
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, &stats);
+ if (is_binary(size, &stats))
+ return("bin ");
+ else if (stats.cr != stats.crlf)
+ return("bin ");
+ else if (stats.crlf && (stats.crlf == stats.lf))
+ return("txt-crlf");
+ else if (stats.crlf && stats.lf)
+ return("txt-mix ");
+ else if (stats.lf)
+ return("txt-lf ");
+ else
+ return("txt ");
+}
+
+const char *get_convert_stats_ascii(const char *path, int flags, size_t
hint)
+{
+ const char *ret = "";
+ if (flags & GET_CONVERT_STATS_ASCII_BLOB) {
+ unsigned long sz;
+ void *data = read_blob_data_from_cache(path, &sz);
+ ret = gather_stats_ascii(data, sz);
+ if (data)
+ free(data);
+ } else if (flags & GET_CONVERT_STATS_ASCII_WT){
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_read_file(&sb, path, hin
Re: git tag --contains now takes a long time
On Sun, Oct 18, 2015 at 2:58 AM, Junio C Hamano wrote: > 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. I'll resend the patch then with the changed commit message. Thanks. -- 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 v2] 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. In ref-filter we have two implementations for filtering refs when the '--contains' option is used. Although they do the same thing, one is optimized for filtering branches and the other for tags (borrowed from branch.c and tag.c respectively) and the 'filter->with_commit_tag_algo' bit decides which algorithm must be used. Maybe we'd want to unify these eventually. When we ported tag.c to use ref-filter APIs we missed out on setting the 'filter->with_commit_tag_algo' bit. As reported by Jerry Snitselaar, this causes the '--contains' 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: Matthieu Moy Tested-by: Jerry Snitselaar Signed-off-by: Karthik Nayak --- 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] Fix missing brackets in worktree usage
H, I'm just starting out with development for Git. Found this super easy to fix,
so here is a patch :)
Sidhant Sharma (1):
builtin/worktree.c: Fix usage message
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.6.2
>From 6b9bc79b698d4c9e1a0f74c37887caf2a05f9978 Mon Sep 17 00:00:00 2001
From: Sidhant Sharma
Date: Sun, 18 Oct 2015 13:29:02 +0530
Subject: [PATCH] builtin/worktree.c: Fix usage message
Mark as optional in worktree command line usage.
Signed-off-by: Sidhant Sharma
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.2
--
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] Fix worktree usage message
Mark as optional in worktree command line usage.
Hi, just starting out with development for Git. Found this one super easy to
fix,
so made a patch :)
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.2
--
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: [Feature Request] git blame showing only revisions from git rev-list --first-parent
On Tue, Sep 15, 2015 at 06:05:39AM -0400, Jeff King wrote: > It seems like nobody is actually that interested in what "blame > --first-parent --reverse" does in the first place, though, and there's > no reason for its complexity to hold up vanilla --first-parent. So what > do you think of: ... > Combining "--reverse" with "--first-parent" is more > complicated, and will probably involve cooperation from > revision.c. Since the desired semantics are not even clear, > let's punt on this for now, but explicitly disallow it to > avoid confusing users (this is not really a regression, > since it did something nonsensical before). Hi. I might be late for this discussion, but I seem to have a case when blame --reverse --first-parent seems to work. Consider the folowing history (from left ro right): +-D1-+ +--->C1-->C2-+ \ / \ \ A0->A1>A2---..-->A3-->A4-->A5 \/ +->B1-->B2-+ , and a line was removed in B2. Then, blame --reverse returns D1 for this line, which is, while technically correct, absolutely useless to find real place where the line was removed. But blame --reverse --first-parent seems to return A1, which is much more useful and actually what I would expect to return. I tried it recently with 2.3-something and it seems to work as expected. Was it the behavior you mentioned as nonsensical or you have some other examples? So please may I ask to not kill this completely. As about the issue mentioned by Junio, it could fail loudly if the requested range is not a first-parent chain. -- Max -- 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] Fix worktree usage message
On Sun, Oct 18, 2015 at 04:32:24PM +0530, Sidhant Sharma wrote:
> Mark as optional in worktree command line usage.
Thank you for the patch.
Can you also explain why you mark it as optional in the commit message?
That way it's clear why this patch is needed.
>
> Hi, just starting out with development for Git. Found this one super easy to
> fix,
> so made a patch :)
These kind of comments don't belong in the commit message. You could add
them below the first three ---. That way, they will not be part of the
commit history.
>
> ---
> builtin/worktree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 71bb770..33d2d37 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -10,7 +10,7 @@
> #include "refs.h"
>
> static const char * const worktree_usage[] = {
> - N_("git worktree add [] "),
> + N_("git worktree add [] []"),
> N_("git worktree prune []"),
> NULL
> };
> --
> 2.6.2
> --
> 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
[PATCH] Fix worktree usage message
Mark optional in worktree command line usage to maintain consistency
with man pages.
Reported-by: ch3co...@gmail.com
Signed-off-by: Sidhant Sharma
---
It was reported here: http://marc.info/?l=git&m=144514145804787&w=2
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.2
--
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: How to rebase when some commit hashes are in some commit messages
On Thursday 15 October 2015 09:44:59 Francois-Xavier Le Bail wrote: > >> On Tue, 13 Oct 2015 10:50:40 +0200 > >> Francois-Xavier Le Bail wrote: > >>> >> For example, if I rebase the following commits, I would want that > >>> >> if the commit hash 222... become 777..., > >>> >> the message > >>> >> "Update test output for " > >>> >> become > >>> >> "Update test output for 777..." > >>> >> > >>> >> Is it possible currently? And if yes how? The code review system Gerrit (highly recommended!) uses a commit-hook to adds a trailer line to every commit message, e.g.: Change-Id: Id8269a1aa4a2c7a1a584b23b01d63259410c4e85 This Change-Id is used to identify a change even if the change gets amended or rebased and thus is represented in a different commit. So if you're using Gerrit you can refer to changes instead of commits and use the Change-Id. Even if you don't use Gerrit you can still use its commit-hook to write the Change-Id trailers. Regards, Thomas Koch -- 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-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?
On Sat, Oct 10, 2015 at 12:45 PM, Noam Postavsky wrote: > I noticed that git-credential-cache--daemon quits on SIGHUP. This > seems like surprising behaviour for a daemon. Would it be acceptable > to change it to ignore SIGHUP? ping? -- 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: How to rebase when some commit hashes are in some commit messages
On Mon, Oct 12, 2015 at 9:59 PM, Francois-Xavier Le Bail wrote: > Hello, > > [I try some search engines without success, perhaps I have missed something]. > > For example, if I rebase the following commits, I would want that if > the commit hash 222... become 777..., > the message > "Update test output for " > become > "Update test output for 777..." > > Is it possible currently? And if yes how? This isn't strictly speaking an answer to your question (others have done that), but in my workflow if I have a patch series where I want to refer to commits inside the series, and I know I'm going to rebase it I work around this by just using the subject line of the commit as an ID. E.g. in the message I'll say something like "See my 'commit.c: Avoid segfaults on OSX' commit for details". Then I can just find that with git log --grep. -- 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] Fix worktree usage message
On Sun, Oct 18, 2015 at 8:15 AM, Sidhant Sharma wrote:
> Mark optional in worktree command line usage to maintain consistency
> with man pages.
Thanks for the patch. To clarify that it is the in-code usage string
which is incorrect, rather than the man page, how about something like
the following as commit message instead?
worktree: usage: denote as optional with 'add'
Although 1eb07d8 (worktree: add: auto-vivify new branch when
is omitted, 2015-07-06) updated the documentation when
became optional, it neglected to update the in-code
usage message. Fix this oversight.
> Reported-by: ch3co...@gmail.com
>
> Signed-off-by: Sidhant Sharma
Citing the reporter is a nice touch, but drop the blank line between
it and the sign-off.
> ---
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 71bb770..33d2d37 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -10,7 +10,7 @@
> #include "refs.h"
>
> static const char * const worktree_usage[] = {
> - N_("git worktree add [] "),
> + N_("git worktree add [] []"),
> N_("git worktree prune []"),
> NULL
> };
> --
> 2.6.2
--
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
Eric Sunshine writes: > 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? Interesting thought. When somebody rewrites "rebase -i" in C, nobody needs to count lines in "stripspace" output. The rewritten "rebase -i" would internally run strbuf_stripspace() and the question becomes what is the best way to let that code find out how many lines the result contains. When viewed from that angle, I agree that "stripspace --count" does not add anything to further the goal of helping "rebase -i" to move to C. Adding strbuf_count_lines() that counts the number of lines in the given strbuf (if there is no such helper yet; I didn't check), though. >> +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? Good point here, too. If we were to add strbuf_count_lines() helper, whoever adds that function needs to take a possible incomplete line at the end into account. Thanks for your comments. -- 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
Torsten Bögershausen writes: > 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 This _may_ be readable by who implemented it, but I cannot tell what you are trying to say above; "like this" does not help me at all deciphering. Do I get the above after doing this? $ >empty $ >empty2 $ git ls-files --eol-worktree empty empty_file empty2 empty_file or do you mean this? $ >empty_file $ >empty_file2 $ git ls-files --eol-worktree empty empty_file empty_file2 or do you produce output one path at a time? $ >empty_file $ >empty_file2 $ git ls-files --eol-worktree empty empty_file empty empty_file2 > txt text_file_with_no_eol_at_all Does it help to have this category at all? This gives the user an indication that this file consists on a single incomplete line and differentiates it from a file with the same single line with LF or CR/LF line ending. What happens when I prepend to these three files another copy of the same line with LF or CR/LF line ending? You get 6 variations: 1. line LF line 2. line LF line LF 3. line LF line CRLF 4. line CRLF line 5. line CRLF line LF 6. line CRLF line CRLF If you say 1 and 2 are with LF, 4 and 6 are with CRLF, eveyrything else is mixed, then you are losing the distinction between 1 and 2 (and 4 and 6) that you made when the files were a single liner (with or without the incomplete line ending). Is that desirable? I wonder if it would be easier for the scripts that process the output from this command to handle if the report said what combination of _three_ possible line-ending is used. i.e. does the file contain a line that ends with LF? does the file contain a line that ends with CRLF? does the file contain a line with missing EOL? > 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 is even worse than the "like this" above ;-) -- 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: [Feature Request] git blame showing only revisions from git rev-list --first-parent
Max Kirillov writes: > I might be late for this discussion, but I seem to have > a case when blame --reverse --first-parent seems to work. I think during the discussion we already established that there are cases where the mode happens to do the right thing (the most trivial is a completely linear history). I do not strongly object to enabling the mode when it is safe to enable (i.e. it can be proven to work and produce a sensible and meaningful result); patches welcome to enable it when it can be shown that it is safe; "to disable it only when it can be shown that it is meaningless" is a different way to state the same thing. -- 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-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?
Noam Postavsky writes: > On Sat, Oct 10, 2015 at 12:45 PM, Noam Postavsky > wrote: >> I noticed that git-credential-cache--daemon quits on SIGHUP. This >> seems like surprising behaviour for a daemon. Would it be acceptable >> to change it to ignore SIGHUP? > > ping? Thanks for pinging. I guess this either fell in the cracks while people were busy discussing other topics, or nobody agreed with the reasoning behind the change, or perhaps a bit of both. In any case, it is a prodent thing to ping on the thread after a week or so, which is what you did. Very much appreciated. I cannot speak for the person who was primarily responsible for designing this behaviour, but I happen to agree with the current behaviour in the situation where it was designed to be used. Upon the first use in your session, the "daemon" is auto-spawned, you can keep talking with that same instance during your session, and you do not have to do anything special to shut it down when you log out. Isn't that what happens here? If this were "when you start the system you start this free-standing daemon once, and it will stay around until it gets shut down. If you are staying around in logged-in state is immaterial" kind of daemon, I'd expect it, upon being killed with HUP, to do something useful, like re-reading its configuration file, and continue, instead of dying. Perhaps you can tweak the system to get both, by making it continue upon HUP by default, but teaching it an option not to (i.e. the current behaviour). Pass that option when spawn_daemon() in credential-cache.c starts the daemon. When using the daemon as a free-standing one (against the way its documentation expects you to---see "git help credential-cache--daemon"), you do not pass that option and your "daemon" will ignore HUP. Hmm? -- 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
Junio C Hamano writes: > If you say 1 and 2 are with LF, 4 and 6 are with CRLF, eveyrything > else is mixed, then you are losing the distinction between 1 and 2 > (and 4 and 6) that you made when the files were a single liner (with > or without the incomplete line ending). Is that desirable? Continuing this line of thought further. My answer is "it may not be desirable, but it is sufficient to decide what line ending to use when I am adding a new line to the existing contents". That is, to a file with a single incomplete line, I can add my new line with either LF or CRLF and the resulting one will become LF (or CRLF) that ends in an incomplete line. To a file whose lines consistently use LF, I can only add my new line with LF, whether the original ends in an incomplete line. So from that point of view,... > I wonder if it would be easier for the scripts that process the > output from this command to handle if the report said what > combination of _three_ possible line-ending is used. i.e. does the > file contain a line that ends with LF? does the file contain a line > that ends with CRLF? does the file contain a line with missing EOL? ... instead of saying there are three possible line-endings, we can stick to two, i.e. "is it text or binary" followed by "among two possible endings, which ones are used", i.e. text text-lf text-crlf text-lf-crlf which matches the last four lines of what you had in the "like this" example (and I prefer "mixed" over "lf-crlf"). So I am OK with the categorization after all with respect to the possible incomplete line at the end. But if that is what the feature is designed for, the documentation must say it very clearly, i.e. "this is to allow you decide what line ending to use when you add a new line to the existing contents" or something. And viewed from that angle, there is no reason to special-case an empty line. Knowing "binary" is important because you want to be able to say "whether LF or CRLF, you do *not* want to add your new line to this binary file."; "empty" is just like "text"---you can use either and get a coherent result. So I'd suggest sticking to these classification tokens: binary text crlf mixed lf The "adding my line at the beginning of the file" script can do something like this using them (here I am simplifying by making your feature available to "git get-eol" command that takes a single path and does your computation): case "$(git get-eol file)" in text | lf) printf "%s\n" "$mine" ;; crlf) printf "%s\r\n" "$mine" ;; *) # that is 'binary' or 'mixed' die "do not muck with the contents of file" ;; esac cat file Also this points at another direction of using the three independent line ending conventions I suggested earlier. What you want to append your lines? You would want to know if the file ends with an incomplete line, so you would rather want to be told with a set of categories like this instead: binary incomplete incomplete,crlf incomplete,mixed incomplete,lf crlf mixed lf Note that an empty file will get an empty string as the grouping above, as it does not have any line ending (i.e. no crlf/mixed/lf), does not end with an incomplete line and is not a binary file. And the using script would become: existing=$(git get-eol file) eol='\n' case ",$existing" in ,binary | *,mixed) die "do not muck with the contents of file" ;; ,*crlf) eol='\r\n' ;; esac cat file case "$existing," in incomplete,*) printf "$eol" ;; esac printf "%s$eol" "$mine" -- 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
Torsten Bögershausen writes: > 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 Two unrelated (to the issues raised in other review responses) issues in the UI: - While I can see how the new feature would be useful, I am not convinced that it is a good idea to add it to ls-files. Does the option work well with other existing options like -s, -t, etc? Does it make sense to combine it with other options like -m, -d, etc? I have this suspicion that "check-attr", "check-ignore", etc. may give a better model that fits this feature better, i.e. "git check-eol". - When you have an operation that works on contents in the working tree, the established command line convention to alter the operation to work on contents in the index is with "--cached", and the operation by default would work on the contents in the working tee without "--worktree". See gitcli(7). If I were doing this as part of "ls-files", I would add a new "--get-eol" option that inspects the working tree, and make "--get-eol --cached" do the same for the contents in the index, for consistency. If I were doing "git check-eol", then the default mode of the operation would read from the working tree, and "git check-eol --cached" would read from the index. If the operation can work on both the contents in the index and in the working tree at the same time, we use "--index" instead of "--cached", but I do not think it applies here (only a small number of commands work on both to begin with, e.g. "apply"). -- 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 00/10] port branch.c to use ref-filter's printing options
On Tue, Oct 13, 2015 at 12:37 AM, Matthieu Moy wrote: > Junio C Hamano writes: > >> If you design a new infrastructure to help refactoring early >> (i.e. before adding many copies of code that need to be cleaned up >> later), it would make the work of reviewing of the design of the >> helper and refactoring using that helper smaller, not larger. > > But most of the code concerned is already reviewed. The first instances > of the pattern to refactor is already in next. With a real time machine, > we could go back in past, refactor and then have cleaner series, but > with Git as our only tool we can't ;-). > > The current series will just add one more instance of sub-optimal code, > it isn't hard to review. Inserting new code before them would make the > interdiff far bigger. > Sorry for the delay, was a bit busy with college work. For the most part I've been trying to integrate the %(upstream) and its options 'track', 'trachshort' and 'short' so we could implement %(upstream:track,nobracket) or %(upstream:nobracket,track). While doing so I realized I was moving a lot of code around and this had me thinking it's perhaps easier to do the cleaning up first as Junio suggested. Maybe then it'd be simpler to do implement this rather than move code around now and then move code around when we implement the parsing methods we spoke about earlier? -- 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
problem with modification time of packfiles
git (2.6.1) sometimes updates the modification time of a packfile, even if it has not changed at all. On my system this triggers quite expensive an d unnecessary backup operations, which I would prefer to avoid. Is there a simple way to keep the mtime of packfiles fixed, once they are created? Apparently the undesired mtime update is done in sha1_file.c:freshen_file() which is called (indirectly) by write_sha1_file(). However I did not understand, why this is done. Any clarification and pointers, how mtime can be kept constant would be appreciated. Thanks, Andreas -- 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-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?
On Sun, Oct 18, 2015 at 1:58 PM, Junio C Hamano wrote: > I cannot speak for the person who was primarily responsible for > designing this behaviour, but I happen to agree with the current > behaviour in the situation where it was designed to be used. Upon > the first use in your session, the "daemon" is auto-spawned, you can > keep talking with that same instance during your session, and you do > not have to do anything special to shut it down when you log out. Oh, hmm this does makes sense. Now that I think of the log out case, I think ignoring the SIGHUP would be the wrong thing for us too. > Isn't that what happens here? I think our problem is that when Emacs creates the "git push" process with a pty[1], it somehow puts that process in its own new session, so when "git push" finishes it takes the daemon down with it. But seeing it like this, it seems clear that the problem is from the Emacs side. [1]: and using pipes instead of a pty doesn't allow entering the password: https://github.com/magit/magit/issues/2309#issuecomment-147101903 -- 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
On 17.10.2015 19:46, Jiang Xin wrote: > 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/ I try it, but result is the same. $ rmdir c $ git check-ignore -v c/ .gitignore:1:* c/ $ mkdir c $ git check-ignore -v c/ .gitignore:2:!*/ c/ Behavior depends on whether c/ directory exists beforehand. -- 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: problem with modification time of packfiles
On Sun, Oct 18, 2015 at 10:37:55PM +0100, Andreas Amann wrote: > git (2.6.1) sometimes updates the modification time of a packfile, even if it > has not changed at all. > > On my system this triggers quite expensive an d unnecessary backup > operations, which I would prefer to avoid. Is there a simple way to > keep the mtime of packfiles fixed, once they are created? > > Apparently the undesired mtime update is done in > sha1_file.c:freshen_file() which is called (indirectly) by > write_sha1_file(). However I did not understand, why this is done. > > Any clarification and pointers, how mtime can be kept constant would be > appreciated. This is required to avoid deleting items that might still be needed. The commit message for the commit that introduced that function is as follows: write_sha1_file: freshen existing objects When we try to write a loose object file, we first check whether that object already exists. If so, we skip the write as an optimization. However, this can interfere with prune's strategy of using mtimes to mark files in progress. For example, if a branch contains a particular tree object and is deleted, that tree object may become unreachable, and have an old mtime. If a new operation then tries to write the same tree, this ends up as a noop; we notice we already have the object and do nothing. A prune running simultaneously with this operation will see the object as old, and may delete it. We can solve this by "freshening" objects that we avoid writing by updating their mtime. The algorithm for doing so is essentially the same as that of has_sha1_file. Therefore we provide a new (static) interface "check_and_freshen", which finds and optionally freshens the object. It's trivial to implement freshening and simple checking by tweaking a single parameter. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano Perhaps implementing a backup strategy based on content instead of mtime would be more successful. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: PGP signature
Re: [PATCH v2 00/10] port branch.c to use ref-filter's printing options
Karthik Nayak writes: > ... While doing so I realized I was moving a lot of code around > and this had me thinking it's perhaps easier to do the cleaning up > first as Junio suggested. > > Maybe then it'd be simpler to do implement this rather than move > code around now and then move code around when we implement the > parsing methods we spoke about earlier? When I suggested the approach, I hadn't have done any of what you actually did, so I was primarily talking out of "hunch" (perhaps that is what some people call "taste") but I expected something like that may happen ;-). Right now, you practically own the topic, in the sense that nobody seems to be in a very urgent need to compete with you in parallel to implement what we have discussed before you do, so I personally would suggest whichever order you feel more comfortable and less error-prone. 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
[PATCH] worktree: usage: denote as optional with 'add'
Although 1eb07d8 (worktree: add: auto-vivify new branch when
is omitted, 2015-07-06) updated the documentation when
became optional, it neglected to update the in-code
usage message. Fix this oversight.
Reported-by: ch3co...@gmail.com
Signed-off-by: Sidhant Sharma
---
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 71bb770..33d2d37 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -10,7 +10,7 @@
#include "refs.h"
static const char * const worktree_usage[] = {
- N_("git worktree add [] "),
+ N_("git worktree add [] []"),
N_("git worktree prune []"),
NULL
};
--
2.6.2
--
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 18/10/15 21:00, Junio C Hamano wrote: Torsten Bögershausen writes: 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 Two unrelated (to the issues raised in other review responses) issues in the UI: - While I can see how the new feature would be useful, I am not convinced that it is a good idea to add it to ls-files. Does the option work well with other existing options like -s, -t, etc? Does it make sense to combine it with other options like -m, -d, etc? I have this suspicion that "check-attr", "check-ignore", etc. may give a better model that fits this feature better, i.e. "git check-eol". (This should answer all comments, thanks everybody @Erics Sunshine: Thanks for the review, dropped you from cc list because web.de can't find an MX record) I like this idea: binary text crlf mixed lf $ git ls-files --eol-staged -s [snip] 100644 981f810e80008d878d6a5af1331c89dc093c5927 0 txt-lf worktree.c - $ rm Documentation/RelNotes/2.7.0.txt $ echo "/* */" >>builtin/ls-files.c $ ls-files -m --eol-worktree emptyDocumentation/RelNotes/2.7.0.txt txt-lf builtin/ls-files.c --- (The empty is a bug, thanks Eric) -- $ ./git-ls-files --eol-worktree -t [snip] $ H txt-lf zlib.c - My understanding is that the eol options work togther with the existing option, as long as it makes sense (but see below) "git check-attr" will even report attributes for a file, that doesn't even exist. "git ls-files is a command which by default operates on the staged area, unless I mis-understand it. And that is the main purpose: Tell me how which line endings your staged files have, and I can tell you that you may consider to normalize these files because "git status", "git blame" consider these files as changed. (From that point of view, "git ls-files --eol" could be the way to report the staged eols. But then users would ask: but why can't you tell me what I have in my worktree ? "git ls-files --eol-worktree" could be the answer (or "git ls-files -o --eol-worktree" ) I was thinking about adding "git check-eol", but didn't want to introduce just another command, as the syntax and options (-z, -o -x -X) overlap much with ls-files Is it the common understanding to add a new command is the best solution ? -- 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
Torsten Bögershausen writes: > I like this idea: > > binary > text > crlf > mixed > lf If you really like it, it would mean that my attempt to use Socratic method to enlighten you why the above is not a good idea failed X-<. > > $ git ls-files --eol-staged -s > [snip] > 100644 981f810e80008d878d6a5af1331c89dc093c5927 0 txt-lf worktree.c Does it even make sense to give --eol-worktree in this case? > My understanding is that the eol options work togther with the existing > option, > as long as it makes sense (but see below) > > "git check-attr" will even report attributes for a file, that doesn't even > exist. Both "ls-files -o/-i" talk about untracked paths, so that is not a very useful and valid objection, is it? > "git ls-files is a command which by default operates on the staged > area, unless I mis-understand it. It is even worse than that. It is true that "ls-files [-s]" is about "--cached" and there is no equivalent to show the working tree version. But "-t", "-d", etc. are not about the state in the index nor the state in the working tree. They are about the relationship between these two states. What the new operation wants to do, if I understand correctly, is either check the blob contents in the working tree or in the index, which is not a good fit with what the rest of "ls-files" does for exactly that reason. The inability to mix -s with --eol-worktree is another natural consequence of this. > I was thinking about adding "git check-eol", but didn't want to > introduce just another command, Between adding a new command that does one thing well and whose user interaction is coherent with the rest of the system, and adding a new operation mode to an existing command and makes the user interaction of that existing command more incoherent by introducing two variants --foo and --foo-worktree when there is no existing option that has similar variant pair, I'd say we prefer to see a new command. The -z output, and --stdin input are what we would want to have for the new command, but I do not think we want it to know -o, -x or -X. You would instead pipe output from ls-files with these options to the new command run with the --stdin option. -- 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] worktree: usage: denote as optional with 'add'
Sidhant Sharma writes:
> Although 1eb07d8 (worktree: add: auto-vivify new branch when
> is omitted, 2015-07-06) updated the documentation when
> became optional, it neglected to update the in-code
> usage message. Fix this oversight.
>
> Reported-by: ch3co...@gmail.com
> Signed-off-by: Sidhant Sharma
> ---
Thanks.
I'll add "Helped-by: Eric Sunshine " and
queue.
> builtin/worktree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 71bb770..33d2d37 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -10,7 +10,7 @@
> #include "refs.h"
>
> static const char * const worktree_usage[] = {
> - N_("git worktree add [] "),
> + N_("git worktree add [] []"),
> N_("git worktree prune []"),
> NULL
> };
> --
> 2.6.2
--
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 PULL] l10n updates for 2.6 maint branch
Jiang Xin writes: > 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(-) Thanks, pulled directly to 'maint'. -- 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
