[PATCH] graph: Fix log's graph's colors when merging branches.
From bdbefc100ceba66a70f540dfe2b1b09b0869f7ab Mon Sep 17 00:00:00 2001
From: Hemmo Nieminen hemmo.niemi...@iki.fi
Date: Wed, 16 Oct 2013 11:28:50 +0300
Subject: [PATCH] graph: Fix log's graph's colors when merging branches.
The log's graph's colors were off sometimes when merging several
branches. For example in the graph depicted below, the '-.' part
following the asterisk was colored with incorrect colors. This was
caused by the fact that the leftmost branches, not part of the merge,
were not taken into account when calculating the column numbers
(colors).
| | Merge of http://members.cox.net/junkio/git-jc.git
| |
| *-. commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e
| |\ \ \ \ Merge: fc54a9c 9e30dd7 c4b83e6 6602659 b28858b
| | | | | | Author: Junio C Hamano jun...@cox.net
Signed-off-by: Hemmo Nieminen hemmo.niemi...@iki.fi
---
graph.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/graph.c b/graph.c
index b24d04c..6404331 100644
--- a/graph.c
+++ b/graph.c
@@ -801,10 +801,10 @@ static int graph_draw_octopus_merge(struct git_graph *graph,
int num_dashes =
((graph-num_parents - dashless_commits) * 2) - 1;
for (i = 0; i num_dashes; i++) {
- col_num = (i / 2) + dashless_commits;
+ col_num = (i / 2) + dashless_commits + graph-commit_index;
strbuf_write_column(sb, graph-new_columns[col_num], '-');
}
- col_num = (i / 2) + dashless_commits;
+ col_num = (i / 2) + dashless_commits + graph-commit_index;
strbuf_write_column(sb, graph-new_columns[col_num], '.');
return num_dashes + 1;
}
--
1.8.4.1
Re: [PATCH] graph: Fix log's graph's colors when merging branches.
On Thu, Oct 17, 2013 at 09:52:09AM +0300, Hemmo Nieminen wrote:
The log's graph's colors were off sometimes when merging several
branches. For example in the graph depicted below, the '-.' part
following the asterisk was colored with incorrect colors. This was
caused by the fact that the leftmost branches, not part of the merge,
were not taken into account when calculating the column numbers
(colors).
| | Merge of http://members.cox.net/junkio/git-jc.git
| |
| *-. commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e
| |\ \ \ \ Merge: fc54a9c 9e30dd7 c4b83e6 6602659 b28858b
| | | | | | Author: Junio C Hamano jun...@cox.net
Signed-off-by: Hemmo Nieminen hemmo.niemi...@iki.fi
It took me a minute to spot the problem when I tested this, but you're
right that there is a bug and I agree that the patch below is the right
fix.
Perhaps a better commit message will help others looking at this, maybe
something like this?
graph: fix coloring around octopus merges
When drawing the graph of an octopus merge, we draw a horizontal
line from parents 3 and above into the asterisk representing the
commit. The sections of this line should be colored to match the
graph lines coming in from above.
However, if the commit is not in the left-most column we do not take
into account the columns to the left of the commit when calculating
these colors. Fix this by adding the appropriate offset to the
column index used for calculating the color.
---
Commit 211232b (Octopus merge of the following five patches.,
2005-05-05) in git.git's history exhibits this problem.
The section below the --- does not become part of the commit message,
when the patch is added to Git, but is used for notes that might help
reviewers.
---
graph.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/graph.c b/graph.c
index b24d04c..6404331 100644
--- a/graph.c
+++ b/graph.c
@@ -801,10 +801,10 @@ static int graph_draw_octopus_merge(struct git_graph
*graph,
int num_dashes =
((graph-num_parents - dashless_commits) * 2) - 1;
for (i = 0; i num_dashes; i++) {
- col_num = (i / 2) + dashless_commits;
+ col_num = (i / 2) + dashless_commits + graph-commit_index;
strbuf_write_column(sb, graph-new_columns[col_num], '-');
}
- col_num = (i / 2) + dashless_commits;
+ col_num = (i / 2) + dashless_commits + graph-commit_index;
strbuf_write_column(sb, graph-new_columns[col_num], '.');
return num_dashes + 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] diffcore-rename.c: Estimate filename similarity for rename detection
On rename detection like command git diff -M ..., rename is detected
based on file similarities. This file similarities are calculated based
on the contents of file. And, if the similarities of contents are the
same, filename is taken into account.
But, the similarity of filename is calculated just whether the basename
is the same or not, and always returns just one or zero.
So, for example, if there are multiple same files in the diff-ing commits,
the result of rename detection is almost random, without taking into account
the similarity of filename.
Calculate filename similarities, and use the result to compare file similarity
in case contents similarities are the same.
Use Sorensen-Dice coefficient of bigrams in strings to calculate filename
similarities because it take into account all part of the filenames, and time
complexity is O(N), assuming N is the length of filenames.
---
diffcore-rename.c | 81 +++
1 file changed, 64 insertions(+), 17 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 6c7a72f..355ea6d 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -96,26 +96,51 @@ static struct diff_rename_src *register_rename_src(struct
diff_filepair *p)
return (rename_src[first]);
}
-static int basename_same(struct diff_filespec *src, struct diff_filespec *dst)
+static int estimate_filename_similarity(struct diff_filespec *src, struct
diff_filespec *dst)
{
- int src_len = strlen(src-path), dst_len = strlen(dst-path);
- while (src_len dst_len) {
- char c1 = src-path[--src_len];
- char c2 = dst-path[--dst_len];
- if (c1 != c2)
- return 0;
- if (c1 == '/')
- return 1;
+ /*
+* Calculate similarity between src path and dst path using
+* Sorensen-Dice coefficient of bigrams in strings
+*/
+ const char *src_path = src-path;
+ const char *dst_path = dst-path;
+ size_t src_len = strlen(src_path);
+ size_t dst_len = strlen(dst_path);
+ static uint16_t src_bigram[256][256];
+ int i;
+ int bigrams_number = 0;
+ int similarity;
+
+ for (i=0; isrc_len; i++) {
+ int c1 = ((unsigned char*)src_path)[i];
+ int c2 = ((unsigned char*)src_path)[i + 1];
+ src_bigram[c1][c2] ++;
+ }
+ for (i=0; idst_len; i++) {
+ int c1 = ((unsigned char*)dst_path)[i];
+ int c2 = ((unsigned char*)dst_path)[i + 1];
+ if (src_bigram[c1][c2] 0) {
+ src_bigram[c1][c2] --;
+ bigrams_number ++;
+ }
+ }
+ similarity = MAX_SCORE * 2 * bigrams_number / (src_len + dst_len);
+
+/* Clean up src_bigram */
+ for (i=0; isrc_len; i++) {
+ int c1 = ((unsigned char*)src_path)[i];
+ int c2 = ((unsigned char*)src_path)[i + 1];
+ src_bigram[c1][c2] = 0;
}
- return (!src_len || src-path[src_len - 1] == '/')
- (!dst_len || dst-path[dst_len - 1] == '/');
+
+ return similarity;
}
struct diff_score {
int src; /* index in rename_src */
int dst; /* index in rename_dst */
unsigned short score;
- short name_score;
+ unsigned short name_score;
};
static int estimate_similarity(struct diff_filespec *src,
@@ -228,7 +253,7 @@ static void record_rename_pair(int dst_index, int
src_index, int score)
*/
static int score_compare(const void *a_, const void *b_)
{
- const struct diff_score *a = a_, *b = b_;
+ struct diff_score *a = (struct diff_score *)a_, *b = (struct diff_score
*)b_;
/* sink the unused ones to the bottom */
if (a-dst 0)
@@ -236,8 +261,23 @@ static int score_compare(const void *a_, const void *b_)
else if (b-dst 0)
return -1;
- if (a-score == b-score)
+ if (a-score == b-score){
+ if(a-score == 0)
+ return 0;
+ /* Calculate name_score only when both score is the same */
+ if(a-name_score == USHRT_MAX){
+ struct diff_filespec *two = rename_dst[a-dst].two;
+ struct diff_filespec *one = rename_src[a-src].p-one;
+ a-name_score = estimate_filename_similarity(one, two);
+ }
+ if(b-name_score == USHRT_MAX){
+ struct diff_filespec *two = rename_dst[b-dst].two;
+ struct diff_filespec *one = rename_src[b-src].p-one;
+ b-name_score = estimate_filename_similarity(one, two);
+ }
+
return b-name_score - a-name_score;
+ }
return b-score - a-score;
}
@@ -282,7 +322,7 @@ static int find_identical_files(struct file_similarity *src,
score =
Re: What's cooking in git.git (Oct 2013, #03; Wed, 16)
Am 16.10.2013 23:43, schrieb Junio C Hamano: * kb/fast-hashmap (2013-09-25) 6 commits - fixup! diffcore-rename.c: simplify finding exact renames - diffcore-rename.c: use new hash map implementation - diffcore-rename.c: simplify finding exact renames - diffcore-rename.c: move code around to prepare for the next patch - buitin/describe.c: use new hash map implementation - add a hashtable implementation that supports O(1) removal I posted a much more complete v3 [1], but somehow missed Jonathan's fixup! commit. Btw., the test suite didn't catch the uninitialized variable, neither on mingw nor linux nor with valgrind. Is there a way to run tests with STACK_POISON or something? [1] http://thread.gmane.org/gmane.comp.version-control.git/235644 -- 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: [RFC/PATCH] checkout: allow dwim for branch creation for git checkout $branch --
Junio C Hamano gits...@pobox.com writes: Did anything further happen to this discussion? Is v3 the version with agreement among the list members I just should pick up? v3 ( http://thread.gmane.org/gmane.comp.version-control.git/235409/focus=235408 ) is the last version I sent, and I got no feedback on it, so I guess it's ready for you to pick. Thanks, -- 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: [RFC/PATCH] doc: git-foo was obsoleted several years ago
W dniu 2013-10-16 23:38, Junio C Hamano pisze: Felipe Contrerasfelipe.contre...@gmail.com writes: [...] I recall that I wanted to see this change happen myself long time ago, and suspect that there may have been some reason that prevented us from doing so. I might have found that AsciiDoc back then did not like the input if the headline name git-checkout(1) did not match the filename git-checkout.txt and the command in the NAME section git-checkout, or links linkgit:git-checkout[1] from other pages couldn't have SP there, or something silly like that. Also doesn't our build infrastructure slurp the one-line description git-checkout - Checkout a branch ... from these files and expect a dash to be there? In short, I personally do prefer to see dashless form at the top of the manpage, if it does not break other things, and there may need changes necessary to avoid breaking other things may to files other than these documentation-proper source files. diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index ca118ac..8d98383 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -1,9 +1,9 @@ -git-checkout(1) +git checkout(1) === I wonder if it wouldn't be better to leave as is, in dashed form, as the manpage file name is git-checkout.1, and this manpage is invoked as man git-checkout, not man git checkout or man 'git checkout'. NAME -git-checkout - Checkout a branch or paths to the working tree +git checkout - Checkout a branch or paths to the working tree SYNOPSIS ... But change this, as we use this command as git checkout, not as git-checkout. -- Jakub Narębski -- 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: [RFC/PATCH] doc: git-foo was obsoleted several years ago
On Thu, Oct 17, 2013 at 1:13 PM, Jakub Narębski jna...@gmail.com wrote: Felipe Contrerasfelipe.contre...@gmail.com writes: diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index ca118ac..8d98383 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -1,9 +1,9 @@ -git-checkout(1) +git checkout(1) === I wonder if it wouldn't be better to leave as is, in dashed form, as the manpage file name is git-checkout.1, and this manpage is invoked as man git-checkout, not man git checkout or man 'git checkout'. This is partly true, as you can also run it with `git checkout --help` -- 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://www.tayga.pro/tmp/pbfdx.htm
[PATCH v2] diffcore-rename.c: Estimate filename similarity for rename detection
On rename detection like command git diff -M ..., rename is detected
based on file similarities. This file similarities are calculated based
on the contents of file. And, if the similarities of contents are the
same, filename is taken into account.
But, the similarity of filename is calculated just whether the basename
is the same or not, and always returns just one or zero.
So, for example, if there are multiple same files in the diff-ing commits,
the result of rename detection is almost random, without taking into account
the similarity of filename.
Calculate filename similarities, and use the result to compare file similarity
in case contents similarities are the same.
Use Sorensen-Dice coefficient of bigrams in strings to calculate filename
similarities because it take into account all part of the filenames, and time
complexity is O(N), assuming N is the length of filenames.
Signed-off-by: Tsuneo Yoshioka yoshiokatsu...@gmail.com
---
diffcore-rename.c | 81 +++
1 file changed, 64 insertions(+), 17 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 6c7a72f..355ea6d 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -96,26 +96,51 @@ static struct diff_rename_src *register_rename_src(struct
diff_filepair *p)
return (rename_src[first]);
}
-static int basename_same(struct diff_filespec *src, struct diff_filespec *dst)
+static int estimate_filename_similarity(struct diff_filespec *src, struct
diff_filespec *dst)
{
- int src_len = strlen(src-path), dst_len = strlen(dst-path);
- while (src_len dst_len) {
- char c1 = src-path[--src_len];
- char c2 = dst-path[--dst_len];
- if (c1 != c2)
- return 0;
- if (c1 == '/')
- return 1;
+ /*
+* Calculate similarity between src path and dst path using
+* Sorensen-Dice coefficient of bigrams in strings
+*/
+ const char *src_path = src-path;
+ const char *dst_path = dst-path;
+ size_t src_len = strlen(src_path);
+ size_t dst_len = strlen(dst_path);
+ static uint16_t src_bigram[256][256];
+ int i;
+ int bigrams_number = 0;
+ int similarity;
+
+ for (i=0; isrc_len; i++) {
+ int c1 = ((unsigned char*)src_path)[i];
+ int c2 = ((unsigned char*)src_path)[i + 1];
+ src_bigram[c1][c2] ++;
+ }
+ for (i=0; idst_len; i++) {
+ int c1 = ((unsigned char*)dst_path)[i];
+ int c2 = ((unsigned char*)dst_path)[i + 1];
+ if (src_bigram[c1][c2] 0) {
+ src_bigram[c1][c2] --;
+ bigrams_number ++;
+ }
+ }
+ similarity = MAX_SCORE * 2 * bigrams_number / (src_len + dst_len);
+
+/* Clean up src_bigram */
+ for (i=0; isrc_len; i++) {
+ int c1 = ((unsigned char*)src_path)[i];
+ int c2 = ((unsigned char*)src_path)[i + 1];
+ src_bigram[c1][c2] = 0;
}
- return (!src_len || src-path[src_len - 1] == '/')
- (!dst_len || dst-path[dst_len - 1] == '/');
+
+ return similarity;
}
struct diff_score {
int src; /* index in rename_src */
int dst; /* index in rename_dst */
unsigned short score;
- short name_score;
+ unsigned short name_score;
};
static int estimate_similarity(struct diff_filespec *src,
@@ -228,7 +253,7 @@ static void record_rename_pair(int dst_index, int
src_index, int score)
*/
static int score_compare(const void *a_, const void *b_)
{
- const struct diff_score *a = a_, *b = b_;
+ struct diff_score *a = (struct diff_score *)a_, *b = (struct diff_score
*)b_;
/* sink the unused ones to the bottom */
if (a-dst 0)
@@ -236,8 +261,23 @@ static int score_compare(const void *a_, const void *b_)
else if (b-dst 0)
return -1;
- if (a-score == b-score)
+ if (a-score == b-score){
+ if(a-score == 0)
+ return 0;
+ /* Calculate name_score only when both score is the same */
+ if(a-name_score == USHRT_MAX){
+ struct diff_filespec *two = rename_dst[a-dst].two;
+ struct diff_filespec *one = rename_src[a-src].p-one;
+ a-name_score = estimate_filename_similarity(one, two);
+ }
+ if(b-name_score == USHRT_MAX){
+ struct diff_filespec *two = rename_dst[b-dst].two;
+ struct diff_filespec *one = rename_src[b-src].p-one;
+ b-name_score = estimate_filename_similarity(one, two);
+ }
+
return b-name_score - a-name_score;
+ }
return b-score - a-score;
}
@@ -282,7 +322,7 @@ static int
Re: pack corruption post-mortem
Jeff King p...@peff.net writes: On Wed, Oct 16, 2013 at 09:41:16AM -0600, Martin Fick wrote: I have nightmares about this sort of thing every now and then, and we even experience some corruption here and there that needs to be fixed (mainly missing objects when we toy with different git repack arguments). I cannot help but wonder, how we can improve git further to either help diagnose or even fix some of these problems? More inline below... In general, I don't think we know enough about patterns of recovery corruption to say which commands would definitely be worth implementing. Part of the reason I wrote this up is to document this one case. But this is the first time in 7 years of git usage that I've had to do this. So I'd feel a little bit better about sinking time into it after seeing a few more cases and realizing where the patterns are. There was one area in our Documentation/ set we used to use to keep this kind of message almost as-is; perhaps this message fits there? -- 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: Windows performance / threading file access
Am 16.10.2013 00:22, schrieb pro-logic: I also get fairly slow performance out of the checkout / reset operations on windows. This discussion got me trying to work out what's taking so long on windows. To help I used killcache [1] to flush the HDD cache and Very Sleepy [2] to profile the code. I couldn't use the GIT_TRACE_PERFORMANCE [3] patch as that seems to only work on script commands, and in my case I just get a result of 335 seconds git reset --hard head from the log. The trace_performance functions require manual instrumentation of the code sections you want to measure, e.g. like this [1]. Output looks like this for a full WebKit checkout (Win7 x64, Core i7 860, WD VelociRaptor 300, NTFS, no virus scanner, no luafv, no defragger): trace: at entry.c:128, time: 135.786 s: write_entry::create trace: at entry.c:129, time: 101.6 s: write_entry::stream trace: at entry.c:130, time: 0 s: write_entry::read trace: at entry.c:131, time: 0 s: write_entry::convert trace: at entry.c:132, time: 0 s: write_entry::write trace: at entry.c:133, time: 4.71825 s: write_entry::close trace: at compat/mingw.c:2150, time: 5.68786 s: mingw_lstat (called 661660 times) trace: at compat/mingw.c:2151, time: 259.219 s: command: c:\git\msysgit\git\git-checkout.exe -f HEAD After running killcache I ran very sleepy connected to git, and according to the profile: 95.5% of the time is spent in do_lstat (mingw.c) / NtQueryFullAttributeFile (ntdll) Very Sleepy confirmed my numbers from above: lstat was always much smaller than create/stream/read/write. Could you post details about your test setup? Are you still using WebKit for your tests? For fun, not knowing if I would break anything or not (it probably does), I wrapped the entire unpack_trees method in the fscache [4] and the total git reset --hard head time fell from 335 seconds to 28 seconds, a 11x improvement. Hmmm...this doesn't work for me at all. Fscache isn't updated during checkout, so lstat-checks whether creating a file or directory succeeded will fail. $ git config core.fscache true $ time git checkout -f HEAD Unlink of file 'Examples' failed. Should I try again? (y/n) n warning: unable to unlink Examples: Permission denied fatal: cannot create directory at 'Examples': Permission denied Karsten [1] https://github.com/kblees/git/commit/b8eca278 -- 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] graph: Fix log's graph's colors when merging branches.
Hi,
On 09:13 Thu 17 Oct, John Keeping wrote:
It took me a minute to spot the problem when I tested this, but you're
right that there is a bug and I agree that the patch below is the right
fix.
Perhaps a better commit message will help others looking at this, maybe
something like this?
Updated the patch. Attaching it here.
--
Best Regards
Hemmo Nieminen
From 46b7ae56e08bc8ca9c29697da2c1210bd2a242b0 Mon Sep 17 00:00:00 2001
From: Hemmo Nieminen hemmo.niemi...@iki.fi
Date: Wed, 16 Oct 2013 11:28:50 +0300
Subject: [PATCH v2] graph: fix coloring around octopus merges
When drawing the graph of an octopus merge, we draw a horizontal line
from parents 3 and above into the asterisk representing the commit. The
sections of this line should be colored to match the graph lines coming
in from above.
However, if the commit is not in the left-most column we do not take
into account the columns to the left of the commit when calculating
these colors. Fix this by adding the appropriate offset to the column
index used for calculating the color.
Signed-off-by: Hemmo Nieminen hemmo.niemi...@iki.fi
---
Notes:
Commit 211232b (Octopus merge of the following five patches.,
2005-05-05) in git.git's history exhibits this problem.
graph.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/graph.c b/graph.c
index b24d04c..6404331 100644
--- a/graph.c
+++ b/graph.c
@@ -801,10 +801,10 @@ static int graph_draw_octopus_merge(struct git_graph *graph,
int num_dashes =
((graph-num_parents - dashless_commits) * 2) - 1;
for (i = 0; i num_dashes; i++) {
- col_num = (i / 2) + dashless_commits;
+ col_num = (i / 2) + dashless_commits + graph-commit_index;
strbuf_write_column(sb, graph-new_columns[col_num], '-');
}
- col_num = (i / 2) + dashless_commits;
+ col_num = (i / 2) + dashless_commits + graph-commit_index;
strbuf_write_column(sb, graph-new_columns[col_num], '.');
return num_dashes + 1;
}
--
1.8.4.1
Re: [PATCH 07/10] receive-pack: request for packv4 if it's the preferred version
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: This is the only plumbing command that is controlled by core.preferredPackVersion so far. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/technical/protocol-capabilities.txt | 4 builtin/receive-pack.c| 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index be09792..32153cd 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -226,4 +226,8 @@ this capability, the server may send a pack version 4. The server can choose to send pack version 2 even if the client accepts this capability. +The receive-pack server advertises this capability if it wants to +receive the pack in format version 4 and the client should send in +this format. Technically, if it can and if it wants to receive is more correct, as a v4 capable receiving end can choose to pretend it does not understand v4 by not sending this capability. Also a v4 incapable receiver would not advertise it even if it _wants_ to receive. So in practice, we see this header only from a receiver that wants to receive v4, which makes the above statement accurate in a twisted way. There needs a bit more explanation on the should part, especially because this is very unusual and unlike all the other capabilities, which are offered as more freedom of choices without preference on the advertising side. Rationale (i.e. reduce load on the receiving end) and ramifications of non-compliance (e.g. the receiver may choose to fail the push when its load is too high) are good things to guide third-party implementors to do the right thing. This capability does not include multi-base tree support. diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index e3eb5fc..288b0bc 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -130,10 +130,11 @@ static void show_ref(const char *path, const unsigned char *sha1) if (sent_capabilities) packet_write(1, %s %s\n, sha1_to_hex(sha1), path); else - packet_write(1, %s %s%c%s%s agent=%s\n, + packet_write(1, %s %s%c%s%s%s agent=%s\n, sha1_to_hex(sha1), path, 0, report-status delete-refs side-band-64k quiet, prefer_ofs_delta ? ofs-delta : , + core_default_pack_version == 4 ? packv4 : , git_user_agent_sanitized()); sent_capabilities = 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
Для эффективного обучения
Ваши языковые навыки поразят Вас самих
http://kuhny.com.ua/components/com_contact/ndavv.htm
NЇВцьrИyњшиbВXЌЖЧЇvи^)оК{.nЧ+З иЇЖЁмЈ}ЉВЦ
zкj:+vЈОЋъчzZ+Ъ+zfЃЂЗhЇ~лiџћрzЙ ЎwЅЂИ?ЈшкЂ)пЂf
Charity Event!
Good day friend, Its a year now since we won the EuroMillions Lottery of £148,656,000 pounds sterling. To verify, you can watch our YouTube video here http://www.youtube.com/watch?v=4lgIpsIe3a4 Recently,my wife Gillian suggested that we commence an end of year charity event by giving out part of our winnings to selected individuals which will help improve the standard of living among the less privileged. She mentioned this in course of interview here http://www.youtube.com/watch?v=vKLXpPkznZw If you receive this Message it means YOU have been selected to benefit from our Lottery winnings. This sounds unbelievable?? We won't blame you if you think so but note that this is not a bogus message but authenticated and directly from us,the Bayfords. You can choose to send a reply to our email (adrian-gill...@hvc.rr.com) for more details or discard message if not interested. Congratulations. Sincerely, Adrian and Gillian Bayford. -- 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 v3 1/2] checkout: allow dwim for branch creation for git checkout $branch --
Matthieu Moy matthieu@imag.fr writes:
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 0f57397..9edd9c3 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -863,6 +863,13 @@ static const char *unique_tracking_name(const char
*name, unsigned char *sha1)
return NULL;
}
+static int error_invalid_ref(const char *arg, int has_dash_dash, int
argcount)
+{
+ if (has_dash_dash)
+ die(_(invalid reference: %s), arg);
+ return argcount;
+}
This is somewhat unfortunate; it pretends to be a reusable helper by
being a separate function, but it is not very reusable (see below).
@@ -917,19 +934,32 @@ static int parse_branchname_arg(int argc, const char
**argv,
arg = @{-1};
if (get_sha1_mb(arg, rev)) {
+ /*
+ * Either case (3) or (4), with something not being
+ * a commit, or an attempt to use case (1) with an
+ * invalid ref.
+ */
+ int try_dwim = dwim_new_local_branch_ok;
+
+ if (check_filename(NULL, arg) !has_dash_dash)
+ try_dwim = 0;
+ /*
+ * Accept git checkout foo and git checkout foo --
+ * as candidates for dwim.
+ */
+ if (!(argc == 1 !has_dash_dash)
+ !(argc == 2 has_dash_dash))
+ try_dwim = 0;
+
+ if (try_dwim) {
const char *remote = unique_tracking_name(arg, rev);
Up to this point, the updated code makes very good sense.
if (!remote)
- return argcount;
+ return error_invalid_ref(arg, has_dash_dash,
argcount);
The original that returned argcount from here were unnecessarily
misleading in the first place. It saw git checkout foo where foo
does not refer to an object nor a filesystem entity and there was no
unique refs/remotes/*/foo; it wanted to return 0 to tell the
caller that it consumed zero arguments as branch names.
And the updated code is even more obscure. This calling site makes
it look as if it is an error to have no unique refs/remotes/*/foo
at this point of the code by naming the helper function error_*(),
but it is an error in some case and not in others.
if (!remote) {
if (has_dash_dash)
die(_(...));
return 0;
}
would be a lot more understandable.
The only reason you have conditional die() here (and on the else
side of this if statement) is because you delayed the die that was
at a much earlier point in the original. And the only reason you
created the unfortunate helper function is because you need to deal
with that delayed decision to die now in two places.
So it may be even cleaner to read if you did it this way:
if (get_sha1_mb(...)) {
/*
* The first token is not a valid rev; we should
* ordinarily error out if git checkout foo --
* if foo is not a valid rev, but first see if
* we can auto-create foo to continue...
*/
int recover_with_dwim = dwim_new_local_branch_ok;
... decide if we want to recover_with_dwim ...
if (recover_with_dwim) {
const char *remote = unique_tracking_name(arg, rev);
if (remote) {
*new_branch = arg;
arg = remote;
} else {
/* no; arg cannot be salvaged */
recover_with_dwim = 0;
}
}
if (!recover_with_dwim) {
if (has_dash_dash)
die(_(invalid ref %s, arg);
return 0; /* we saw no branch/commit */
}
/* otherwise we made a successful recovery */
}
--
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] mv: Fix spurious warning when moving a file in presence of submodules
Jens Lehmann wrote: In commit 0656781fa git mv learned to update the submodule path in the .gitmodules file when moving a submodule in the work tree. But since that commit update_path_in_gitmodules() gets called no matter if we moved a submodule or a regular file, which is wrong and leads to a bogus warning when moving a regular file in a repo containing a .gitmodules file: warning: Could not find section in .gitmodules where path=filename [...] Reported-by: Matthieu Moy matthieu@grenoble-inp.fr Signed-off-by: Jens Lehmann jens.lehm...@web.de --- [...] And this is the fix for it, which I believe is stuff for maint. Thanks again, and sorry to leave this hanging. I had some vague ideas for improvement: * style nits: test is a little long, making it hard to take in at a glance; tests tend to try to avoid pipelines to avoid losing the exit code from git commands; usual style is to use test instead of [ consistently * would be nice to have another test that makes sure the move a file, not submodule case keeps working But those can easily happen as changes on top, and as you mentioned, it's probably worth someone interested (e.g., me :)) making a pass to clean up the style of the rest of the script anyway. The patch as-is is obviously good. Thanks again for the quick diagnosis and fix. Reviewed-by: Jonathan Nieder jrnie...@gmail.com -- 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-users] Problem using detached worktrees with commands implemented in scripts
From: Junio C Hamano gits...@pobox.com wor...@alum.mit.edu (Dale R. Worley) writes: In general, Git commands on a repository with a detached worktree can be executed by cd'ing into the directory containing the .git directory, ... Eh? News to me; it might happened to have appeared to work by accident, but that is not by design. I must admit I've never seen the design (and I personally doubt that the design has ever been written down). But at least the following commands work correctly on a detached worktree if the current directory contains the .git directory, because I am using them in a production manner: git add git cat-file git commit git commit-tree git config git gc git log git ls-tree git reset git rev-list git update-ref In my situation, the worktree is not, in my mind, dependent on the repository; the repository is intended to keep backups of the contents of the directories that are worktree. Indeed, one could establish several detached repositories to back up different subsets of the same worktree. So it is conceptually natural to execute Git in the repository directory. And, after all, the current directory identifies the repository and the repository contains a pointer to the worktree. Not exporting GIT_DIR variable in sh-setup was done not by accident but as a very deliberate design choice, IIRC. The intention of my change is that it appears that all of the failures of my use pattern are when the command is implemented by a shell script, and it appears that all shell scripts initially invoke git-sh-setup. The change specifically detects my use pattern and, for the remainder of the script, changes the use pattern into a pattern closely related to the one that Junio documents: - export GIT_DIR that points at the correct .git directory; - GIT_WORK_TREE is left unset - set the current directory to the top of the working tree Perhaps the change should also set GIT_WORK_TREE. I haven't noticed setting GIT_WORK_TREE to be necessary for git filter-branch, but perhaps that is coincidental. It seems to me that this change would uniformly support the use pattern I use without affecting Git's behavior in any other case. Dale -- 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 v6] diff.c: keep arrow(=) on show_stats()'s shortened filename part to make rename visible.
Yoshioka Tsuneo yoshiokatsu...@gmail.com writes:
git diff -M --stat can detect rename and show renamed file name like
foofoofoo = barbarbar.
Before this commit, this output is shortened always by omitting left most
part like ...foo = barbarbar. So, if the destination filename is too long,
source filename putting left or arrow can be totally omitted like
...barbarbar, without including any of foofoofoo =.
In such a case where arrow symbol is omitted, there is no way to know
whether the file is renamed or existed in the original.
Make sure there is always an arrow, like ...foo = ...bar.
The output can contain curly braces('{','}') for grouping.
So, in general, the output format is pfx{mid_a = mid_b}sfx
To keep arrow(=), try to omit pfx as long as possible at first
because later part or changing part will be the more important part.
If it is not enough, shorten mid_a, mid_b, and sfx trying to
have the maximum length the same because those will be equally important.
I somehow find this solid wall of text extremely hard to
read. Adding a blank line as a paragraph break may make it easier to
read, perhaps.
Also it is customary in our history to omit the full-stop from the
patch title on the Subject: line.
+ name_len = pfx-len + a_mid-len + b_mid-len + sfx-len + strlen(arrow)
+ + (use_curly_braces ? 2 : 0);
+
+ if (name_len = name_width) {
+ /* Everthing fits in name_width */
+ return;
+ }
Logic up to this point seems good; drop {} around a single statement
return;, i.e.
if (name_len = name_width)
return; /* everything fits */
+ } else {
+ if (pfx-len strlen(dots)) {
+ /*
+ * Just omitting left of '{' is not enough
+ * name will be ...{SOMETHING}SOMETHING
+ */
+ strbuf_reset(pfx);
+ strbuf_addstr(pfx, dots);
+ }
(mental note) ... otherwise, i.e. with a short common prefix, the
final result will be ab{SOMETHING}SOMETHING, which is also fine
for the purpose of the remainder of this function.
+ }
+ }
+
+ /* available length for a_mid, b_mid and sfx */
+ len = name_width - strlen(arrow) - (use_curly_braces ? 2 : 0);
+
+ /* a_mid, b_mid, sfx will be have the same max, including
ellipsis(...). */
+ part_length[0] = a_mid-len;
+ part_length[1] = b_mid-len;
+ part_length[2] = sfx-len;
+
+ qsort(part_length, sizeof(part_length)/sizeof(part_length[0]),
sizeof(part_length[0])
+ , compare_size_t_descending_order);
In our code, comma does not come at the beginning of continued
line.
+ if (part_length[1] + part_length[1] + part_length[2] = len) {
+ /*
+ * {...foofoo = barbar}file
+ * There is only one omitted part.
+ */
+ max_part_len = len - part_length[1] - part_length[2];
It would be clearer to explicitly set remainder to zero here, and
omit the initialization of the variable. That would make what the
three parts of if/elseif/else do more consistent.
+ } else if (part_length[2] + part_length[2] + part_length[2] = len) {
+ /*
+ * {...foofoo = ...barbar}file
+ * There are 2 omitted parts.
+ */
+ max_part_len = (len - part_length[2]) / 2;
+ remainder_part_len = (len - part_length[2]) - max_part_len * 2;
+ } else {
+ /*
+ * {...ofoo = ...rbar}...file
+ * There are 3 omitted parts.
+ */
+ max_part_len = len / 3;
+ remainder_part_len = len - (max_part_len) * 3;
+ }
I am not sure if distributing the burden of truncation equally to
three parts so that the resulting pieces are of similar lengths is
really a good idea. Between these two
{...SourceDirectory = ...nationDirectory}...ileThatWasMoved
{...ceDirectory = ...ionDirectory}nameOfTheFileThatWasMoved
that attempt to show that the file nameOfTheFileThatWasMoved was
moved from the longSourceDirectory to the DestinationDirectory, the
latter is much more informative, I would think.
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 2f327b7..03d6371 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -156,4 +156,16 @@ test_expect_success 'rename pretty print common prefix
and suffix overlap' '
test_i18ngrep d/f/{ = f}/e output
'
+test_expect_success 'rename of very long path shows =' '
+ mkdir long_dirname_that_does_not_fit_in_a_single_line
+ mkdir another_extremely_long_path_but_not_the_same_as_the_first
+ cp path1 long_dirname*/
+ git add long_dirname*/path1
+ test_commit add_long_pathname
+ git mv long_dirname*/path1
Re: [RFC/PATCH] doc: git-foo was obsoleted several years ago
Jakub Narębski jna...@gmail.com writes: W dniu 2013-10-16 23:38, Junio C Hamano pisze: I recall that I wanted to see this change happen myself long time ago,... In short, I personally do prefer to see dashless form at the top of the manpage, if it does not break other things, and there may need changes necessary to avoid breaking other things may to files other than these documentation-proper source files. ... I wonder if it wouldn't be better to leave as is, in dashed form, ... But change this, as we use this command as git checkout, not as git-checkout. Yes, that is what I meant by dashless form at the top of the manpage, if it does not break other things. man git-cat-file is one of other things. -- 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 v3] Add core.mode configuration
From: Jonathan Nieder jrnie...@gmail.com Philip Oakley wrote: Would this be a good time to suggest a specific wording should be proposed (or a reminder of what was proposed repeated) for the documentation of this option. It will be the documentation that users will refer to when they need to know, rather than the list discussions. It's not clear to me that this config item is a good idea. My point was that the arguments had been rehearsed and explored, and that it was possibly a suitable time for Filippe to update any commit message and config item documentation so that the proposal can be judged. What is the intended use? If someone wants to test that their scripts will continue to work with git 2.0, wouldn't testing a 2.0 release candidate (or the current state of the 'jch' branch until one exists) be the simplest way to do that? If someone just likes the proposed behavior changes and wants to start using them right away, maybe we can help them by releasing 2.0 sooner ;-), or by advertising the fairly simple changes in commandline usage to get the new behaviors: In terms of moving forward, there needs to be a balance between being stuck in the old world of the 60's, and being projected into the bright new world of the 20's (OK so I have exaggerated a bit there ;-). It's always been a case of different strokes for different folks - there will be folk who will try such an option (in an honest manner), who may not be aware of branches that are outside of the regular pu / next / master / maint branches which the project publicises. Rather than letting the email discussion degenerate by going round in circles to the usual end point, having a clarifying proposal (hopefully well balanced) would at least allow a cleaner understanding and decision. Instead of git add, use git add -A. When using git add -u or git add -A from a subdirectory of the toplevel, specify git add -u . explicitly unless you want it to apply to the whole tree (in which case use git add -u :/). Instead of letting git push guess, name the branch you want to push: git push origin master. Or set '[push] default = simple' in your configuration. Pass --prefix to git svn clone. The downside of configuration like the proposed core.next is that it is hard to explain (What do you mean that I can't roll back to the pre-2.0 behavior in Git 2.0 by setting this configuration setting to an appropriate value?), users or scripts can rely on it, and configuration variables tend to accumulate and never be removed. If we really want a run-time switch for this, I suspect an appropriately named environment variable would work better, since we have a history of being able to remove those without alarming people. My two cents, 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: [PATCH v2 00/14] Officially start moving to the term 'staging area'
Felipe Contreras felipe.contre...@gmail.com writes: Junio, can you make an exception and reply to this thread? The change to move away from the term the index has been suggested many times since many years ago, it is an extremely important change to users, and all the Git developers agree it must be done. It must be done is different from any change is good, as long as it introduces more instances of word 'stage'. As we established, we do not seem to be able to do a sensible design discussion with you without wasting time for nothing, I won't directly comment on that patch series, at least for now. However, since you asked, I would share a couple of comments regarding the index, cache and staging area. (1) Staging area. The phrase staging area is not an everyday phrase or common CS lingo, and that unfortunately makes it a suboptimal choice of words especially to those of us, to whom a large portion of their exposure to the English language is through the command words we use when we talk to our computers. I personally do not mind explaining the index is like a staging area, where an army piles up ammunition to a temporary dump before starting a major campaign. to native speakers, though ;-). The index can also be thought of like the buffer cache, where new contents of files are kept before they are committed to disk platter. At least, non-native speaker with CS background would understand that, much better than the index (no, I am not saying that we should call it the cache; I am just saying the index is not a good word, but we may need to find a better word than the staging area). The noun phrase staging area and the verb to stage are good (especially when we do not worry too much about us foreigners), but we need to make sure stage is not mistaken as a noun when used in a context that talks about the index as a whole, to avoid confusion with the use of the word stage long established since http://thread.gmane.org/gmane.comp.version-control.git/231/focus=286 to call ours stage#2, etc. (2) cached vs index. I think this is the more major issue between the two issues (the other one being why do we force people to say 'index'?). Some commands take --cached, some others take --index, some take both. What these two mean are documented in gitcli manual page, but that is far from sufficient. The users can get confused by this UI mistake in different ways. * We do need to have git apply that mimics patch (i.e. works only to a working tree files, or even outside Git repository) without any option, git apply --mode1 that only applies the change to the index, and git apply --mode2 that applies the change to both the index and the working tree. No renaming of the index does not change this need to have three different mode of operation. It was a major UI mistake to call one of the modes --cached and another --index, because there is no way, other than rote learning, for people to choose the one between the two depending that is right for the situation they face. If --cached were called --index-only, it might have been a lot more learnable (and then --index could be renamed to --index-and-working-tree at the same time to reduce the confusion further). Alternatively, with the synonym --staged for --cached already in place for git diff, we could introduce --staged-and-working-tree as a synonym for --index to achieve the same effect (of course we need to find a way to shorten -and-working-tree part in a sensible way). * git grep barfs when given --index, even though it does accept --cached and searches the patterns in contents that are in the index. This is technically correct, as the command does not search both in the index and in the working tree, but again, there is no way other than rote learning for users to tell that --cached is the correct one to use, even after they know that they want to search in the index (I already called it a major UI mistake, didn't I?). A new synonym --staged for --cached may be able to alleviate the confusion somewhat, given especially that git diff already knows --staged as a synonym for --cached. I think a better end result will come if we taught git grep --index to actually search the patterns both in the index and in the working tree at the same time. There is no logical reason from the end user's point of view that git grep --index (aka git grep --staged-and-working-tree) needs to fail; if we make the --mode2 to mean to work on both the index and the working tree for any Git command when it makes sense, things will be more consistent, and it certainly makes sense to ask git grep to work on both the index and the working tree. We do allow git grep -e pattern tree-ish-1 tree-ish-2 to search in multiple data sources already, so it can be seen as a logical extension. * git diff --index [TREE-ISH] has exactly the same issue as git
Re: [PATCH v3] build: add default aliases
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Jeff King p...@peff.net writes: It seems[1] that some people define ci as commit -a, and some people define st as status -s or even status -sb. These option variants aside. Just like thinking that committing must be the same as publishing, it is a cvs/svn induced braindamage to think that checking in must be the same as committing. The former is a sign of not understanding the distributed, the latter the index. In a world with both check-in and commit as two words usable to denote possibly different concepts, it may make sense to say you check-in the current status of the working tree files into the index, in order to make commits out of it later. Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are just wrong. So you are saying they are just ignorant. I am sick of seeing my word twisted, especially when they were not even addressed to you (see the message's primary recipients list). Those who want to type git ci due to their familiarity with svn ci are not wrong; they can do so if they choose. Let's try again (see below). Now, if you are commenting on the aliases, that would mean you are not against the idea of aliaes per se, but more about values of those aliases. So if we agreed on the right values, you would welcome this patch. Is that correct? No. I agree with the issue the message I was replying to raised. The alias mechanism is a way to help users to define their own convenient short-cut. If you want to say git ci to mean git commit (and not git commit -a or something else), define it for your own use, and stop there, without getting in the way of other people. That is why I see an attempt to add hard-coded set of aliases as a move in the wrong direction. A set of hard-coded alias that _officially_ declares that checkin is an equivalent to commit has another issue. It will close the door for us to later add git checkin that may mean something different from git commit, and that is another reason why I do not agree with the patch under discussion in this thread. A checkin that is an operation that checks-in the current contents to the index is one example of an action other than committing that the word may make sense for, because git checkout README.txt is about checking out of the index, its logical opposite checkin could be about checking into the index. -- 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 v6] diff.c: keep arrow(=) on show_stats()'s shortened filename part to make rename visible.
Yoshioka Tsuneo yoshiokatsu...@gmail.com writes: Before this commit, this output is shortened always by omitting left most part like ...foo = barbarbar. So, if the destination filename is too long, source filename putting left or arrow can be totally omitted like ...barbarbar, without including any of foofoofoo =. This is an explanation much easier to understand than the one in the previous iteration. 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: My patches
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Such a review comment and the discussion that follows it after a patch is posted is an essential part of the collaborative development process in this community and it has helped the quality of our end product. We unfortunately saw time and again that the process rarely works when the discussion involves your patches. No, you did not. What you saw was a person that unlike a trained dog, argued against you. And apparently your definition of a good discussion is one in which the other person just does what you say, and doesn't argue back. That is so untrue that it is not even funny. If the ultimate goal of your whining is to spread misinformation to make you look like a victim, you are not worth talking to. Contributors often make sensible counter-arguments and/or explain the rationale better than they did in their original messages, and then receive a Thanks for a dose of sanity (or an equivalent phrased in different ways). -- 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
cherry-pick generates bogus conflicts on removed files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a commit I am trying to cherry pick that removes a number of files. It seems to generate conflicts for those files that have been modified on this branch since the common ancestor. Since they are being removed, I don't care about what changes have been made on this branch, just remove them. Even git cherry-pick -Xtheirs does not help. How can I avoid these conflicts, or accept the deletions? I tried git add -u, but that seems to take my version rather than accept the deletion, and there is no -u switch to git rm. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSYEFlAAoJEJrBOlT6nu75kSEIAMjqXl6nhfEhIMC66Zh4W/y0 MZ/+acDUNdvpCDtEpf9nPIFBQUKxdqAhUg0qYLSOvdvhQIvxkgo6nMo15MAA5Dd/ jNPZD78m0qwvNooUhFiHdqSEwob+2ntA9/VVP+LgCsRcK6BUqHs1Z3MKbe4vXPYr +/bs11daxcnHH81aXOwRcOlUZRsG+yCDQiD9qjhPyv0BCCdS9splC+R7JZy4VaYb 6GQ03G7oY0yFGV9UAOXD1OqDwVPc30tinXlCM2GaBQNc11IQzpi813nEyxTOaf3Z P5BXXH5ZzDNQS5F6Dn/VVNM6MMxVugIgGJafd4EkJiRHw4fIcUCX3/aeDoEDHlc= =uy2D -END PGP SIGNATURE- -- 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-users] Problem using detached worktrees with commands implemented in scripts
wor...@alum.mit.edu (Dale R. Worley) writes:
I must admit I've never seen the design (and I personally doubt that
the design has ever been written down). But at least the following
commands work correctly on a detached worktree if the current
directory contains the .git directory, because I am using them in a
production manner:
git add
If you have this:
/repositories/proj.git/{refs,objects,...}
/working/trees/proj-wt1/
where proj-wt1 is a working tree for that proj.git repository, the
idea was to set these:
GIT_DIR=/repositories/proj.git
GIT_WORK_TREE=/working/trees/proj-wt1
export GIT_DIR GIT_WORK_TREE
and then working in /working/trees/proj-wt1 or any of its
subdirectory should work as if you did not have these two
environment variables and had /working/trees/proj-wt1/.git instead
of /repositories/proj.git as the repository. To make that use case
work was the motivation behind these environment variables.
Side note: without GIT_WORK_TREE environment (or
core.worktree), there is no way to tell where the top level
is, so you were limited to always be at the top level of
your working tree if you used GIT_DIR to refer to a
repository that is not embedded in your working tree. There
were some changes in this area, but I do not recall the
details offhand.
Now, when you say the cwd contains the .git directory, do you mean
cd /repositories
git add ../working/trees/proj-wt1/file
updates file in the /repositories/proj.git/index? Or do you mean
this?
cd /repositories/proj.git
git add ../../working/trees/proj-wt1/file
Or this?
cd /repositories
edit ../working/trees/proj-wt1/file
git add file
Most of the commands you listed do not need to look at the actual
working tree files, so I would expect e.g. git log or git log
paths... to work but I am wondering what your definition of works
with respect to the pathspecs, especially when you talk about
starting Git command _outside_ the working tree (whether the working
tree has its repository embedded in it is not very relevant).
--
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-users] Problem using detached worktrees with commands implemented in scripts
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: ... and the detection process for 'toplevel' may not work properly when in a separated work-tree environment. Without GIT_WORK_TREE exported to point at the top-level, there is nothing that lets us detect it, as the working tree does not have .git directory to tell us to stop, no? No, but not in that way. My point (to Dale) was, as you state, that the cd to top level was (IIUC) the probable causes of the fault, and that a documentation update would probably be appropriate for the discussion on exporting GIT_WORK_TREE, and that it would specifically mention those git commands that needed to cd to top level, and hence would not work in such an environment. (I wasn't sure where the appropriate cd to top level function was) An explanation here on the list wouldn't solve the problems for others who are yet to make the same mistake, hence the implied suggestion. Philip -- 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: What's cooking in git.git (Oct 2013, #03; Wed, 16)
Karsten Blees karsten.bl...@gmail.com writes: Am 16.10.2013 23:43, schrieb Junio C Hamano: * kb/fast-hashmap (2013-09-25) 6 commits - fixup! diffcore-rename.c: simplify finding exact renames - diffcore-rename.c: use new hash map implementation - diffcore-rename.c: simplify finding exact renames - diffcore-rename.c: move code around to prepare for the next patch - buitin/describe.c: use new hash map implementation - add a hashtable implementation that supports O(1) removal I posted a much more complete v3 [1], but somehow missed Jonathan's fixup! commit. Thanks; I'll replace the above with v3 and squash the fix-up 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: [RFC/PATCH] checkout: allow dwim for branch creation for git checkout $branch --
Matthieu Moy matthieu@grenoble-inp.fr writes: v3 ( http://thread.gmane.org/gmane.comp.version-control.git/235409/focus=235408 ) is the last version I sent, and I got no feedback on it, so I guess it's ready for you to pick. Thanks; done with s/pick/nitpick/ ;-). -- 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-users] Problem using detached worktrees with commands implemented in scripts
Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: ... and the detection process for 'toplevel' may not work properly when in a separated work-tree environment. Without GIT_WORK_TREE exported to point at the top-level, there is nothing that lets us detect it, as the working tree does not have .git directory to tell us to stop, no? No, but not in that way. My point (to Dale) was, as you state, that the cd to top level was (IIUC) the probable causes of the fault, and that a documentation update would probably be appropriate for the discussion on exporting GIT_WORK_TREE, and that it would specifically mention those git commands that needed to cd to top level, and hence would not work in such an environment. (I wasn't sure where the appropriate cd to top level function was) An explanation here on the list wouldn't solve the problems for others who are yet to make the same mistake, hence the implied suggestion. I understand what you mean by these last two lines. It was unclear to me which part of our documentation needs updating and how, and that was (and still is) what I was primarily interested in finding out. -- 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: What's cooking in git.git (Oct 2013, #03; Wed, 16)
Junio C Hamano gits...@pobox.com writes: Karsten Blees karsten.bl...@gmail.com writes: Am 16.10.2013 23:43, schrieb Junio C Hamano: * kb/fast-hashmap (2013-09-25) 6 commits - fixup! diffcore-rename.c: simplify finding exact renames - diffcore-rename.c: use new hash map implementation - diffcore-rename.c: simplify finding exact renames - diffcore-rename.c: move code around to prepare for the next patch - buitin/describe.c: use new hash map implementation - add a hashtable implementation that supports O(1) removal I posted a much more complete v3 [1], but somehow missed Jonathan's fixup! commit. Thanks; I'll replace the above with v3 and squash the fix-up in. Interestingly, v3 applied on 'maint' and then merged to 'master' seems to break t3600 and t7001 with a coredump. It would conflict with es/name-hash-no-trailing-slash-in-dirs that has been cooking in 'next', too; the resolution might be trivial but I didn't look too deeply into it. -- 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-users] Problem using detached worktrees with commands implemented in scripts
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: ... and the detection process for 'toplevel' may not work properly when in a separated work-tree environment. Without GIT_WORK_TREE exported to point at the top-level, there is nothing that lets us detect it, as the working tree does not have .git directory to tell us to stop, no? No, but not in that way. My point (to Dale) was, as you state, that the cd to top level was (IIUC) the probable causes of the fault, and that a documentation update would probably be appropriate for the discussion on exporting GIT_WORK_TREE, and that it would specifically mention those git commands that needed to cd to top level, and hence would not work in such an environment. (I wasn't sure where the appropriate cd to top level function was) An explanation here on the list wouldn't solve the problems for others who are yet to make the same mistake, hence the implied suggestion. I understand what you mean by these last two lines. It was unclear to me which part of our documentation needs updating and how, and that was (and still is) what I was primarily interested in finding out. I was expecting that the places would be in git(1) [git.txt] and config(1) [config.txt], in the enironment variables GIT_WORK_TREE section and core.worktree sections repectively. However what the right text would be hasn't been fully determined yet, as it should be clear about which commands don't follow the stated 'rules'. Dale's use case does appear to be stretching... Philip -- 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: cherry-pick generates bogus conflicts on removed files
Phillip Susi ps...@ubuntu.com writes: I have a commit I am trying to cherry pick that removes a number of files. It seems to generate conflicts for those files that have been modified on this branch since the common ancestor. Correct. Without inspecting them, you would not know what you would be losing by blindly resolving to removal, hence we do not auto-resolve one side removed, the other side changed to a removal. That does not need to mean that we should not make it easier for the user to say resolve these 'one side removed, the other side changed' paths to removal. add -u will be a way to say Record the changes I made to my working tree files to the index. So presumably rm -f those files that the other branch removed git add -u would be one way to do so. Of course, you can also use git rm directly, i.e. git rm -f those files that the other branch removed -- 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 v3] Add core.mode configuration
Jonathan Nieder wrote: Philip Oakley wrote: Would this be a good time to suggest a specific wording should be proposed (or a reminder of what was proposed repeated) for the documentation of this option. It will be the documentation that users will refer to when they need to know, rather than the list discussions. It's not clear to me that this config item is a good idea. What is the intended use? If someone wants to test that their scripts will continue to work with git 2.0, wouldn't testing a 2.0 release candidate There is no 2.0 release candidate, and the window between the first 2.0 rc and 2.0 final is limited, such person might not have the time do such testing in that window. Moreover, it's not just to test their scripts, but also their fingers. (or the current state of the 'jch' branch until one exists) That doesn't work for the vast majority of users who do not compile Git. If someone just likes the proposed behavior changes and wants to start using them right away, maybe we can help them by releasing 2.0 sooner ;-) So basically you are advocating for another v1.6 fiasco, where users start complaining about the new behaviors *after* the release has been made, and their user experience has been broken. Is that the case? , or by advertising the fairly simple changes in commandline usage to get the new behaviors: Instead of git add, use git add -A. When using git add -u or git add -A from a subdirectory of the toplevel, specify git add -u . explicitly unless you want it to apply to the whole tree (in which case use git add -u :/). Instead of letting git push guess, name the branch you want to push: git push origin master. Or set '[push] default = simple' in your configuration. Pass --prefix to git svn clone. I don't get why you don't understand something so simple about human nature. Every teach knows that you don't just give a lecture, even if the student understands what you explained, most likely (s)he would not learn it until after doing excercises. 99% of our users have not read the release notes about the 2.0 changes, 98% will not read that advertizement you just said, 90% of those who read it will only get noise, and the ones that read and understand it, might change their minds once they experience it. That's why in every game conference they don't just explain to you the new game, they let you play it, only then the end users can give an honest opinion about the game. Perhaps it's unfortunate, but our users are human, and that's how humans work. We don't know if our users would be OK with the 2.0 changes, it's only after they have given it a try that they can honestly say, and it's better to give them as much time as possible and make it easier for them to try. The downside of configuration like the proposed core.next is that it is hard to explain (What do you mean that I can't roll back to the pre-2.0 behavior in Git 2.0 by setting this configuration setting to an appropriate value?), It is not hard to explain. core.mode = next enables the proposed behavior for the next major version of Git (v2.0), which might change. core.mode = current (the default) enables the behavior of the current version of Git (v1.x). It is implied that there's no core.mode = previous, but it can be explicitly stated. users or scripts can rely on it, and configuration variables tend to accumulate and never be removed. Not this one, because this one makes it clear that is volatile (although probably not that much). If we really want a run-time switch for this, I suspect an appropriately named environment variable would work better, since we have a history of being able to remove those without alarming people. The fact that B has done the job in the past, doesn't mean it would do the job better than A in the future. -- Felipe Contreras -- 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 v3] build: add default aliases
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Jeff King p...@peff.net writes: It seems[1] that some people define ci as commit -a, and some people define st as status -s or even status -sb. These option variants aside. Just like thinking that committing must be the same as publishing, it is a cvs/svn induced braindamage to think that checking in must be the same as committing. The former is a sign of not understanding the distributed, the latter the index. In a world with both check-in and commit as two words usable to denote possibly different concepts, it may make sense to say you check-in the current status of the working tree files into the index, in order to make commits out of it later. Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are just wrong. So you are saying they are just ignorant. I am sick of seeing my word twisted, especially when they were not even addressed to you (see the message's primary recipients list). When you send messages to a public mailing list, even if not addressed to that mailing list, is with the expectation that other people in that mailing list will reply. When you say something is a sign of not understanding, that means ignorance, and there's nothing bad about that, we are all ignorant about many things. Those who want to type git ci due to their familiarity with svn ci are not wrong; they can do so if they choose. I never suggested they were wrong, you suggested they were ignorant. And this is being used by you as reason *not* to use ci as an alias for commit by default. Now, if you are commenting on the aliases, that would mean you are not against the idea of aliaes per se, but more about values of those aliases. So if we agreed on the right values, you would welcome this patch. Is that correct? No. I agree with the issue the message I was replying to raised. The alias mechanism is a way to help users to define their own convenient short-cut. If you want to say git ci to mean git commit (and not git commit -a or something else), define it for your own use, and stop there, without getting in the way of other people. A set of default aliases doesn't get in the way of other people either. That's why all VCS tools have them, and none of them have a problem. That is why I see an attempt to add hard-coded set of aliases as a move in the wrong direction. They are not hard-coded, they are configurable. A set of hard-coded alias that _officially_ declares that checkin is an equivalent to commit has another issue. No. Nobody said anything about check-in, it's ci, which could be CommIt. And you are conveniently ignoring all the other possible aliases for commit. It will close the door for us to later add git checkin that may mean something different from git commit, and that is another reason why I do not agree with the patch under discussion in this thread. A checkin that is an operation that checks-in the current contents to the index is one example of an action other than committing that the word may make sense for, because git checkout README.txt is about checking out of the index, its logical opposite checkin could be about checking into the index. Nobody said anything about a check-in. This is a red herring. Absolultely nothing you have said in this second half has anything to do with the question I asked. I asked specifically about the idea of aliases, independently of their actual values, and all you have done is argue against the value of a single alias: ci. -- Felipe Contreras -- 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: My patches
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Such a review comment and the discussion that follows it after a patch is posted is an essential part of the collaborative development process in this community and it has helped the quality of our end product. We unfortunately saw time and again that the process rarely works when the discussion involves your patches. No, you did not. What you saw was a person that unlike a trained dog, argued against you. And apparently your definition of a good discussion is one in which the other person just does what you say, and doesn't argue back. That is so untrue that it is not even funny. It is true, and there's penty of evidence that proves it. Every single time that you get mad at me, it's because I disagree with you. Contributors often make sensible counter-arguments and/or explain the rationale better than they did in their original messages, and then receive a Thanks for a dose of sanity (or an equivalent phrased in different ways). Yes, when there's an agreement, so you are basically proving what I said. I disagree with you, you disagree with me, and that means I'm the problem. In any healthy collaborative project that simply means there was a disagreement, and that's that. -- Felipe Contreras -- 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 v7] diff.c: keep arrow(=) on show_stats()'s shortened filename part to make rename visible
git diff -M --stat can detect rename and show renamed file name like
foofoofoo = barbarbar.
Before this commit, this output is shortened always by omitting left most
part like ...foo = barbarbar. So, if the destination filename is too long,
source filename putting left or arrow can be totally omitted like
...barbarbar, without including any of foofoofoo =.
In such a case where arrow symbol is omitted, there is no way to know
whether the file is renamed or existed in the original.
Make sure there is always an arrow, like ...foo = ...bar.
The output can contain curly braces('{','}') for grouping.
So, in general, the output format is pfx{mid_a = mid_b}sfx
To keep arrow(=), try to omit pfx as long as possible at first
because later part or changing part will be the more important part.
If it is not enough, shorten mid_a, mid_b, and sfx trying to
have the same maximum length, but as long as filename part of sfx
is kept.
Signed-off-by: Tsuneo Yoshioka yoshiokatsu...@gmail.com
Test-added-by: Thomas Rast tr...@inf.ethz.ch
---
diff.c | 184 +++--
t/t4001-diff-rename.sh | 12
2 files changed, 174 insertions(+), 22 deletions(-)
diff --git a/diff.c b/diff.c
index a04a34d..cdf59c0 100644
--- a/diff.c
+++ b/diff.c
@@ -1258,11 +1258,13 @@ static void fn_out_consume(void *priv, char *line,
unsigned long len)
}
}
-static char *pprint_rename(const char *a, const char *b)
+static void find_common_prefix_suffix(const char *a, const char *b,
+ struct strbuf *pfx,
+ struct strbuf *a_mid, struct strbuf *b_mid,
+ struct strbuf *sfx)
{
const char *old = a;
const char *new = b;
- struct strbuf name = STRBUF_INIT;
int pfx_length, sfx_length;
int pfx_adjust_for_slash;
int len_a = strlen(a);
@@ -1272,10 +1274,9 @@ static char *pprint_rename(const char *a, const char *b)
int qlen_b = quote_c_style(b, NULL, NULL, 0);
if (qlen_a || qlen_b) {
- quote_c_style(a, name, NULL, 0);
- strbuf_addstr(name, = );
- quote_c_style(b, name, NULL, 0);
- return strbuf_detach(name, NULL);
+ quote_c_style(a, a_mid, NULL, 0);
+ quote_c_style(b, b_mid, NULL, 0);
+ return;
}
/* Find common prefix */
@@ -1322,17 +1323,146 @@ static char *pprint_rename(const char *a, const char
*b)
if (b_midlen 0)
b_midlen = 0;
- strbuf_grow(name, pfx_length + a_midlen + b_midlen + sfx_length + 7);
- if (pfx_length + sfx_length) {
- strbuf_add(name, a, pfx_length);
+ strbuf_add(pfx, a, pfx_length);
+ strbuf_add(a_mid, a + pfx_length, a_midlen);
+ strbuf_add(b_mid, b + pfx_length, b_midlen);
+ strbuf_add(sfx, a + len_a - sfx_length, sfx_length);
+}
+
+/*
+ * Omit each parts to fix in name_width.
+ * Formatted string is pfx{a_mid = b_mid}sfx.
+ * At first, omit pfx as long as possible.
+ * If it is not enough, omit a_mid, b_mid, sfx by tring to set the
length of
+ * those 3 parts(including ...) to the same, but keeping filename part of
sfx.
+ * Ex:
+ * foofoofoo = barbarbar
+ * will be like
+ * ...foo = ...bar.
+ * long_parent{foofoofoo = barbarbar}path/filename
+ * will be like
+ * ...parent{...foofoo = ...barbar}.../filename
+ */
+static void rename_omit(struct strbuf *pfx,
+ struct strbuf *a_mid, struct strbuf *b_mid,
+ struct strbuf *sfx,
+ int name_width)
+{
+ static const char arrow[] = = ;
+ static const char dots[] = ...;
+ int use_curly_braces = (pfx-len 0) || (sfx-len 0);
+ size_t name_len;
+ size_t max_part_len = 0;
+ size_t remainder_part_len = 0;
+ size_t left, right;
+ size_t sfx_minlen;
+ char *sfx_last_slash;
+ size_t max_sfx_len;
+
+ name_len = pfx-len + a_mid-len + b_mid-len + sfx-len + strlen(arrow)
+ + (use_curly_braces ? 2 : 0);
+
+ if (name_len = name_width)
+ return; /* everything fits in name_width */
+
+ if (use_curly_braces) {
+ if (strlen(dots) + (name_len - pfx-len) = name_width) {
+ /*
+* Just omitting left of '{' is enough
+* Ex: ...aaa{foofoofoo = bar}file
+*/
+ strbuf_splice(pfx, 0, name_len - name_width +
strlen(dots), dots, strlen(dots));
+ return;
+ } else {
+ if (pfx-len strlen(dots)) {
+ /*
+* Just omitting left of '{' is not enough
+* name will be ...{SOMETHING}SOMETHING
+*/
+
Re: [PATCH v6] diff.c: keep arrow(=) on show_stats()'s shortened filename part to make rename visible.
Hello Junio
Thank you very much for the reviewing.
I try to fix the issues, and posted the updated patch as [PATCH v7].
I am not sure if distributing the burden of truncation equally to
three parts so that the resulting pieces are of similar lengths is
really a good idea. Between these two
{...SourceDirectory = ...nationDirectory}...ileThatWasMoved
{...ceDirectory = ...ionDirectory}nameOfTheFileThatWasMoved
that attempt to show that the file nameOfTheFileThatWasMoved was
moved from the longSourceDirectory to the DestinationDirectory, the
latter is much more informative, I would think.
In the [PATCH v7], I changed to keep filename part of suffix to handle
above case, but not always keep directory part because I feel totally
keeping all part of long suffix including directory name may cause output like:
…{… = …}…ongPath1/LongPath2/nameOfTheFileThatWasMoved
And, above may be worse than:
...{...ceDirectory = …ionDirectory}.../nameOfTheFileThatWasMoved
I think.
Thank you !
---
Tsuneo Yoshioka (吉岡 恒夫)
yoshiokatsu...@gmail.com
On Oct 17, 2013, at 10:29 PM, Junio C Hamano gits...@pobox.com wrote:
Yoshioka Tsuneo yoshiokatsu...@gmail.com writes:
git diff -M --stat can detect rename and show renamed file name like
foofoofoo = barbarbar.
Before this commit, this output is shortened always by omitting left most
part like ...foo = barbarbar. So, if the destination filename is too long,
source filename putting left or arrow can be totally omitted like
...barbarbar, without including any of foofoofoo =.
In such a case where arrow symbol is omitted, there is no way to know
whether the file is renamed or existed in the original.
Make sure there is always an arrow, like ...foo = ...bar.
The output can contain curly braces('{','}') for grouping.
So, in general, the output format is pfx{mid_a = mid_b}sfx
To keep arrow(=), try to omit pfx as long as possible at first
because later part or changing part will be the more important part.
If it is not enough, shorten mid_a, mid_b, and sfx trying to
have the maximum length the same because those will be equally important.
I somehow find this solid wall of text extremely hard to
read. Adding a blank line as a paragraph break may make it easier to
read, perhaps.
Also it is customary in our history to omit the full-stop from the
patch title on the Subject: line.
+name_len = pfx-len + a_mid-len + b_mid-len + sfx-len + strlen(arrow)
++ (use_curly_braces ? 2 : 0);
+
+if (name_len = name_width) {
+/* Everthing fits in name_width */
+return;
+}
Logic up to this point seems good; drop {} around a single statement
return;, i.e.
if (name_len = name_width)
return; /* everything fits */
+} else {
+if (pfx-len strlen(dots)) {
+/*
+ * Just omitting left of '{' is not enough
+ * name will be ...{SOMETHING}SOMETHING
+ */
+strbuf_reset(pfx);
+strbuf_addstr(pfx, dots);
+}
(mental note) ... otherwise, i.e. with a short common prefix, the
final result will be ab{SOMETHING}SOMETHING, which is also fine
for the purpose of the remainder of this function.
+}
+}
+
+/* available length for a_mid, b_mid and sfx */
+len = name_width - strlen(arrow) - (use_curly_braces ? 2 : 0);
+
+/* a_mid, b_mid, sfx will be have the same max, including
ellipsis(...). */
+part_length[0] = a_mid-len;
+part_length[1] = b_mid-len;
+part_length[2] = sfx-len;
+
+qsort(part_length, sizeof(part_length)/sizeof(part_length[0]),
sizeof(part_length[0])
+ , compare_size_t_descending_order);
In our code, comma does not come at the beginning of continued
line.
+if (part_length[1] + part_length[1] + part_length[2] = len) {
+/*
+ * {...foofoo = barbar}file
+ * There is only one omitted part.
+ */
+max_part_len = len - part_length[1] - part_length[2];
It would be clearer to explicitly set remainder to zero here, and
omit the initialization of the variable. That would make what the
three parts of if/elseif/else do more consistent.
+} else if (part_length[2] + part_length[2] + part_length[2] = len) {
+/*
+ * {...foofoo = ...barbar}file
+ * There are 2 omitted parts.
+ */
+max_part_len = (len - part_length[2]) / 2;
+remainder_part_len = (len - part_length[2]) - max_part_len * 2;
+} else {
+/*
+ * {...ofoo = ...rbar}...file
+ * There are 3 omitted parts.
+ */
+max_part_len = len / 3;
+remainder_part_len = len - (max_part_len) * 3;
+}
Re: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too
Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com The setting of denyDeleteCurrent applies to both bare and non-bare repositories. Correct the description on this point, and expand it to provide some background justification for the current behavior and describe the full suite of settings. Signed-off-by: Brandon Casey draf...@gmail.com --- Documentation/config.txt | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c3f7002..3d416ec 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1993,8 +1993,15 @@ receive.denyDeletes:: the ref. Use this to prevent such a ref deletion via a push. receive.denyDeleteCurrent:: - If set to true, git-receive-pack will deny a ref update that - deletes the currently checked out branch of a non-bare repository. + If set to true or refuse, git-receive-pack will deny a ref update + that deletes the currently checked out branch of a non-bare repository, + or the default branch in a bare repository. i.e. the branch + that HEAD refers to. It reads just fine without the part that you found the need for clarification with i.e., i.e. or the branch that HEAD points at in a bare repository. without introducing a new word default branch that is not defined in the glossary. + Deleting the current branch from a remote will + cause the HEAD symbolic ref to become dangling and will result in the + next clone from it to not check out anything. This sentence tells truth but does not fit in the logic flow in the paragraph. I am reading it as primarily meant to be an explanation why it would be a good idea to apply this seemingly non-bare only option (implied by current in its name---it is so rare for a bare repository to repoint its HEAD that the concept of current does not mesh well with a bare one) to a bare one. It may be a good thing to have, but the thought-process may flow better if it is made as a FYI after the main text, i.e. If set to true or refuse, `git-receive-pack` will deny a ref update that deletes the branch that HAED points at. If set to warn, ... If set to false or ignore, ... Defaults to refuse. + Deleting the branch that HEAD points at will cause the HEAD symbolic ref to become dangling. This causes the next commit to become a root commit, disconnected from the old history, in a non-bare repository. It also causes the next clone from such a repository (either bare or non-bare) not to check out anything. perhaps? -- 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/14] Officially start moving to the term 'staging area'
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio, can you make an exception and reply to this thread? The change to move away from the term the index has been suggested many times since many years ago, it is an extremely important change to users, and all the Git developers agree it must be done. It must be done is different from any change is good, as long as it introduces more instances of word 'stage'. As we established, we do not seem to be able to do a sensible design discussion with you without wasting time for nothing, I won't directly comment on that patch series, at least for now. However, since you asked, I would share a couple of comments regarding the index, cache and staging area. (1) Staging area. The phrase staging area is not an everyday phrase or common CS lingo, and that unfortunately makes it a suboptimal choice of words especially to those of us, to whom a large portion of their exposure to the English language is through the command words we use when we talk to our computers. That's because Git is the only command tool that has such a concept. I personally do not mind explaining the index is like a staging area, where an army piles up ammunition to a temporary dump before starting a major campaign. to native speakers, though ;-). If you agree that explaining to users the index is like a staging area, then why just not call it the staging area? Moreover, a staging area is not just a temporary dump, it is used in preparation for something specific, and you might need to remove certain weapons in place of better ones suited for the mission, that's why the word staging is used. The index can also be thought of like the buffer cache, where new contents of files are kept before they are committed to disk platter. A buffer and a cache are two very different things used for two very different purposes, and the term cache doesn't apply to the index. At least, non-native speaker with CS background would understand that, much better than the index (no, I am not saying that we should call it the cache; I am just saying the index is not a good word, but we may need to find a better word than the staging area). All right, so that's progress; you do accept the index is not a good term. Now, if you don't think staging area is a good term, do you have any that is better? This has been discussed for several years, and nobody has come up with a better term, in fact, the vast majority of people prefer the term staging area, and it is already used in online documentation, including the ProGit book. It seems inside and outside the Git project, the term has already been chosen. Do you honestly think somebody is just suddenly going to come up with a better term? How long do we have to wait before we decide X is the best term we could come up with? One year? Two years? Ten years? Or do you just want to wait until we have the perfect term, which might be never. The noun phrase staging area and the verb to stage are good (especially when we do not worry too much about us foreigners), but we need to make sure stage is not mistaken as a noun when used in a context that talks about the index as a whole, to avoid confusion with the use of the word stage long established since http://thread.gmane.org/gmane.comp.version-control.git/231/focus=286 to call ours stage#2, etc. Lets assume that staging area is not the best option, even though after years of discussion nobody has come up with a better one. How would a different term solve the problem you state above? If we use the term commit draft, we still could have people saying draft # 2. So is there any term that would avoid this problem, and is it really important to worry about such a marginal problem? Regardless of the term used, we can make sure it's not used in that context, so I don't understand how that argument goes against staging area. We can make sure staging area is not used to denote the different index files. Is this the *only* argument you have against the term staging area? (2) cached vs index. I think this is the more major issue between the two issues (the other one being why do we force people to say 'index'?). Some commands take --cached, some others take --index, some take both. What these two mean are documented in gitcli manual page, but that is far from sufficient. The users can get confused by this UI mistake in different ways. * We do need to have git apply that mimics patch (i.e. works only to a working tree files, or even outside Git repository) without any option, git apply --mode1 that only applies the change to the index, and git apply --mode2 that applies the change to both the index and the working tree. No renaming of the index does not change this need to have three different mode of operation. It was a major UI mistake to call one of the modes --cached and another --index, because
Re: [git-users] Problem using detached worktrees with commands implemented in scripts
From: Philip Oakley philipoak...@iee.org From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: ... and the detection process for 'toplevel' may not work properly when in a separated work-tree environment. Without GIT_WORK_TREE exported to point at the top-level, there is nothing that lets us detect it, as the working tree does not have .git directory to tell us to stop, no? No, but not in that way. My point (to Dale) was, as you state, that the cd to top level was (IIUC) the probable causes of the fault, and that a documentation update would probably be appropriate for the discussion on exporting GIT_WORK_TREE, and that it would specifically mention those git commands that needed to cd to top level, and hence would not work in such an environment. (I wasn't sure where the appropriate cd to top level function was) An explanation here on the list wouldn't solve the problems for others who are yet to make the same mistake, hence the implied suggestion. I understand what you mean by these last two lines. It was unclear to me which part of our documentation needs updating and how, and that was (and still is) what I was primarily interested in finding out. I was expecting that the places would be in git(1) [git.txt] and config(1) [config.txt], in the enironment variables GIT_WORK_TREE section and core.worktree sections repectively. However what the right text would be hasn't been fully determined yet, as it should be clear about which commands don't follow the stated 'rules'. Dale's use case does appear to be stretching... Philip A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh directly uses `git rev-parse --show-toplevel`, which simply returns work_tree (static char *work_tree; in environment.c, with comment /* This is set by setup_git_dir_gently() and/or git_default_config() */), apparently without a check for the GIT_WORK_TREE. One option may be to either protect the cd_to_toplevel code with a check of `git rev-parse --local-env-vars` to see if GIT_WORK_TREE is present. Or create `git rev-parse --work-dir` to match `--git-dir`. This would be a code level fix. This makes the assumption that if a deteched GIT_WORK_TREE is set then it is the top level. In terms of command scripts that use git-sh-setup.sh we have a longish list, so a full list in the documentation is probably unreasonable (which suggests that a code fix would be more apprpriate) commands: git-am git-bisect git-filter-branch git-instaweb git-lost-found git-merge-one-file git-mergetool git-pull git-quiltimport git-rebase git-repack git-request-pull git-stash git-submodule git-web--browse git\contrib\*various* Philip -- 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 v6] diff.c: keep arrow(=) on show_stats()'s shortened filename part to make rename visible.
Yoshioka Tsuneo yoshiokatsu...@gmail.com writes:
In the [PATCH v7], I changed to keep filename part of suffix to handle
above case, but not always keep directory part because I feel totally
keeping all part of long suffix including directory name may cause output
like:
…{… = …}…ongPath1/LongPath2/nameOfTheFileThatWasMoved
And, above may be worse than:
...{...ceDirectory = …ionDirectory}.../nameOfTheFileThatWasMoved
I think.
I am not sure if I agree.
Losing LongPath2 part may be more significant data loss than losing
a single bit that says the change is a rename, as the latter may not
quite tell us what these two directories were anyway.
--
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-users] Problem using detached worktrees with commands implemented in scripts
Philip Oakley wrote: A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh directly uses `git rev-parse --show-toplevel`, which simply returns work_tree (static char *work_tree; in environment.c, with comment /* This is set by setup_git_dir_gently() and/or git_default_config() */), apparently without a check for the GIT_WORK_TREE. Getting closer. :) The usual way to use GIT_WORK_TREE is along with GIT_DIR. That takes you into the setup_explicit_git_dir() codepath, which does respect GIT_WORK_TREE as it should. (setup_discovered_git_dir does, too.) The strange behavior you ran into is that unlike, say, git-pull.sh and git-am.sh, filter-branch does not set SUBDIRECTORY_OK, store the prefix from 'git rev-parse --show-prefix', and then cd_to_toplevel at the top of the script. In other words, nobody bothered to make it work from anywhere other than the toplevel of the worktree to begin with, and nobody wanted it enough to fix it later. Hope that helps, 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: [PATCH] Documentation/config.txt: denyDeleteCurrent applies to bare repos too
On Thu, Oct 17, 2013 at 3:23 PM, Junio C Hamano gits...@pobox.com wrote: Brandon Casey bca...@nvidia.com writes: From: Brandon Casey draf...@gmail.com The setting of denyDeleteCurrent applies to both bare and non-bare repositories. Correct the description on this point, and expand it to provide some background justification for the current behavior and describe the full suite of settings. Signed-off-by: Brandon Casey draf...@gmail.com --- Documentation/config.txt | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c3f7002..3d416ec 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1993,8 +1993,15 @@ receive.denyDeletes:: the ref. Use this to prevent such a ref deletion via a push. receive.denyDeleteCurrent:: - If set to true, git-receive-pack will deny a ref update that - deletes the currently checked out branch of a non-bare repository. + If set to true or refuse, git-receive-pack will deny a ref update + that deletes the currently checked out branch of a non-bare repository, + or the default branch in a bare repository. i.e. the branch + that HEAD refers to. It reads just fine without the part that you found the need for clarification with i.e., i.e. or the branch that HEAD points at in a bare repository. without introducing a new word default branch that is not defined in the glossary. Either way is fine with me. The phrase the branch that HEAD points at applies to either a bare or non-bare repo though, so the i.e. was directed at both parts of the preceding sentence. Guess we haven't defined an alternative way to say the branch that HEAD points at for a bare repository à la currently checked out branch for a non-bare repository. + Deleting the current branch from a remote will + cause the HEAD symbolic ref to become dangling and will result in the + next clone from it to not check out anything. This sentence tells truth but does not fit in the logic flow in the paragraph. I am reading it as primarily meant to be an explanation why it would be a good idea to apply this seemingly non-bare only option (implied by current in its name---it is so rare for a bare repository to repoint its HEAD that the concept of current does not mesh well with a bare one) to a bare one. Yep, that's the correct reading: as an explanation for why this should apply to bare repos as well as non-bare. It may be a good thing to have, but the thought-process may flow better if it is made as a FYI after the main text, i.e. If set to true or refuse, `git-receive-pack` will deny a ref update that deletes the branch that HAED points at. If set to warn, ... If set to false or ignore, ... Defaults to refuse. + Deleting the branch that HEAD points at will cause the HEAD symbolic ref to become dangling. This causes the next commit to become a root commit, disconnected from the old history, in a non-bare repository. It also causes the next clone from such a repository (either bare or non-bare) not to check out anything. perhaps? Yes, much better as a note following the main text. Thanks. -Brandon -- 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: What's cooking in git.git (Oct 2013, #03; Wed, 16)
Am 17.10.2013 23:07, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
Karsten Blees karsten.bl...@gmail.com writes:
Am 16.10.2013 23:43, schrieb Junio C Hamano:
* kb/fast-hashmap (2013-09-25) 6 commits
- fixup! diffcore-rename.c: simplify finding exact renames
- diffcore-rename.c: use new hash map implementation
- diffcore-rename.c: simplify finding exact renames
- diffcore-rename.c: move code around to prepare for the next patch
- buitin/describe.c: use new hash map implementation
- add a hashtable implementation that supports O(1) removal
I posted a much more complete v3 [1], but somehow missed Jonathan's fixup!
commit.
Thanks; I'll replace the above with v3 and squash the fix-up in.
Interestingly, v3 applied on 'maint' and then merged to 'master'
seems to break t3600 and t7001 with a coredump.
It would conflict with es/name-hash-no-trailing-slash-in-dirs that
has been cooking in 'next', too; the resolution might be trivial but
I didn't look too deeply into it.
I've pushed a rebased version to
https://github.com/kblees/git/commits/kb/hashmap-v3-next
(no changes yet except for Jonathan's fixup in #04 and merge resolution).
The coredumps are caused by my patch #10, which free()s cache_entries when they
are removed, in combination with submodule.c::stage_updated_gitmodules
(5fee9952 submodule.c: add .gitmodules staging helper functions), which
removes a cache_entry, then modifies and re-adds the (now) free()d memory.
Can't we just use add_file_to_cache here (which replaces cache_entries by
creating a copy)?
diff --git a/submodule.c b/submodule.c
index 1905d75..e388487 100644
--- a/submodule.c
+++ b/submodule.c
@@ -116,30 +116,7 @@ int remove_path_from_gitmodules(const char *path)
void stage_updated_gitmodules(void)
{
- struct strbuf buf = STRBUF_INIT;
- struct stat st;
- int pos;
- struct cache_entry *ce;
- int namelen = strlen(.gitmodules);
-
- pos = cache_name_pos(.gitmodules, namelen);
- if (pos 0) {
- warning(_(could not find .gitmodules in index));
- return;
- }
- ce = active_cache[pos];
- ce-ce_flags = namelen;
- if (strbuf_read_file(buf, .gitmodules, 0) 0)
- die(_(reading updated .gitmodules failed));
- if (lstat(.gitmodules, st) 0)
- die_errno(_(unable to stat updated .gitmodules));
- fill_stat_cache_info(ce, st);
- ce-ce_mode = ce_mode_from_stat(ce, st.st_mode);
- if (remove_cache_entry_at(pos) 0)
- die(_(unable to remove .gitmodules from index));
- if (write_sha1_file(buf.buf, buf.len, blob_type, ce-sha1))
- die(_(adding updated .gitmodules failed));
- if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE))
+ if (add_file_to_cache(.gitmodules, 0))
die(_(staging updated .gitmodules failed));
}
--
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] fr.po translation 100% complete
Hi, Junio The following changes since commit 1d25dd416f08f39042d23340db380f28abb81962: Update draft release notes to 1.8.5 (2013-10-16 12:27:45 -0700) are available in the git repository at: git://github.com/git-l10n/git-po master Jean-Noel Avila (1): l10n: fr.po: 2135/2135 messages translated po/fr.po | 5560 -- 1 files changed, 3193 insertions(+), 2367 deletions(-) -- Jiang Xin -- 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
