[PATCH 0/1] Add stash entry count summary to short status output

[Sonny Michaud]

this patch adds a header in the same style as the one provided by the --branch 
option when the user supplies both --show-stash and --short.  My attempt at 
creating a new test is broken[1], and I assume my changes could (and, likely 
need to) be improved.  Any assistance would be greatly appreciated; I just 
wanted to get started by hacking first and asking questions later!  
   
   
Thanks,    
Sonny  
   
1. https://travis-ci.org/sonnym/git/builds/266428128

--
>From 9e9ffca5c4ed7dda34cad416c3eb68dc94a78b7e Mon Sep 17 00:00:00 2001 
From: Sonny Michaud   
Date: Sat, 19 Aug 2017 23:46:15 -0400  
Subject: [PATCH 1/1] status: learn to show stash in short output   

This patch extends the functionality of the recently introduced
--show-stash option to the status command, providing a header similar to   
the one displayed when using the --branch option.  
---
 t/t7508-status.sh |  5 +  
 wt-status.c   | 12    
 2 files changed, 17 insertions(+) 

diff --git a/t/t7508-status.sh b/t/t7508-status.sh 
index 43d19a9b2..734001bc6 100755  
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1619,6 +1619,11 @@ test_expect_success 'show stash info with 
"--show-stash"' '   
  
test_i18ngrep "^Your stash currently has 1 entry$" expected_with_stash 
 ' 
   
+test_expect_success 'show stash info with "--show-stash" and "--short"' ' 
+   git status --show-stash --short >expected_with_stash &&
+   test_i18ngrep "Stash entries: 2" expected_with_stash   
+' 
+  
 test_expect_success 'no stash info with "--show-stash --no-show-stash"' ' 
git status --show-stash --no-show-stash >expected_without_stash && 
test_cmp expected_default expected_without_stash   
diff --git a/wt-status.c b/wt-status.c 
index 77c27c511..651bb01f0 100644  
--- a/wt-status.c  
+++ b/wt-status.c  
@@ -1827,6 +1827,15 @@ static void wt_shortstatus_print_tracking(struct 
wt_status *s)   
   
fputc(s->null_termination ? '\0' : '\n', s->fp);   
 } 
   
+static void wt_shortstatus_print_stash_summary(struct wt_status *s)   
+{ 
+   int stash_count = 0;   
+  
+   for_each_reflog_ent("refs/stash", stash_count_refs, _count); 
+   if (stash_count > 0)   
+color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "## Stash entries: %d", 
stash_count);   
 
+} 
+  
 static void wt_shortstatus_print(struct wt_status *s) 
 { 
struct string_list_item *it;   
@@ -1834,6 +1843,9 @@ static void wt_shortstatus_print(struct wt_status *s)
if (s->show_branch)
wt_shortstatus_print_tracking(s);  

Re: [PATCH 1/3] stash: add test for stash create with no files

[Junio C Hamano]

Joel Teichroeb  writes:

> On Sat, Aug 19, 2017 at 1:55 PM, Junio C Hamano  wrote:
>>
>> Are you documenting an existing breakage?  Are you extending test
>> coverage for some breakage we recently fixed without adding tests to
>> ensure that the fix will stay unbroken?  Are you planning to touch
>> the implementation (perhaps to add yet another feature that uses
>> some existing code) and adding new tests in advance to avoid breaking
>> the existing code?  Some other motivation?
>>
>
> I was just too lazy to write a cover letter, and thought these would
> make sense on their own. I'll make sure to include a cover letter next
> time.
>
> I just ripped them out of my patch series on implementing stash as a
> builtin[1]. Since I haven't had time, I figured I could at least get
> the additional tests I wrote into the codebase.

OK, so it is the third one among my random 4 choices ;-)  

They do look sensible; I did not want to make sure they are not
duplicates myself (i.e. a new test that makes sense may not be an
undesired addition if the only effect it has is to eat more cycles
without improving test coverage).

Will queue.  Thanks.

> The tests mainly expand coverage of git stash, covering a few critical
> error cases that didn't have tests.
>
> [1] https://public-inbox.org/git/20170608005535.13080-1-j...@teichroeb.net/
>

Re: [PATCH 1/3] stash: add test for stash create with no files

[Joel Teichroeb]

Hi Junio,

I was just too lazy to write a cover letter, and thought these would
make sense on their own. I'll make sure to include a cover letter next
time.

I just ripped them out of my patch series on implementing stash as a
builtin[1]. Since I haven't had time, I figured I could at least get
the additional tests I wrote into the codebase.

The tests mainly expand coverage of git stash, covering a few critical
error cases that didn't have tests.

[1] https://public-inbox.org/git/20170608005535.13080-1-j...@teichroeb.net/

On Sat, Aug 19, 2017 at 1:55 PM, Junio C Hamano  wrote:
> I see three patches that add tests, but it is hard to judge them
> without any explanation on what the point of them are.
>
> Are you documenting an existing breakage?  Are you extending test
> coverage for some breakage we recently fixed without adding tests to
> ensure that the fix will stay unbroken?  Are you planning to touch
> the implementation (perhaps to add yet another feature that uses
> some existing code) and adding new tests in advance to avoid breaking
> the existing code?  Some other motivation?
>
> These would have made fine material to write in the cover letter for
> this series.
>
> Thanks.

Re: [PATCH] progress: simplify "delayed" progress API

[Junio C Hamano]

Junio C Hamano  writes:

> We used to expose the full power of the delayed progress API to the
> callers, so that they can specify, not just the message to show and
> expected total amount of work that is used to compute the percentage
> of work performed so far, the percent-threshold parameter P and the
> delay-seconds parameter N.  The progress meter starts to show at N
> seconds into the operation only if the amount of work completed
> exceeds P.

Oops, we inspect the doneness at N seconds and show only if we have
not yet completed P percent of the total work.

Perhaps

... at N seconds into the operation only if we have not
completed P per-cent of the total work.

Re: [PATCH 1/3] stash: add test for stash create with no files

[Junio C Hamano]

I see three patches that add tests, but it is hard to judge them
without any explanation on what the point of them are.

Are you documenting an existing breakage?  Are you extending test
coverage for some breakage we recently fixed without adding tests to
ensure that the fix will stay unbroken?  Are you planning to touch
the implementation (perhaps to add yet another feature that uses
some existing code) and adding new tests in advance to avoid breaking
the existing code?  Some other motivation?

These would have made fine material to write in the cover letter for
this series.

Thanks.

[PATCH 1/2] rerere: represent time duration in timestamp_t internally

[Junio C Hamano]

The two configuration variables, gc.rerereResolved and
gc.rerereUnresolved, are measured in days and are passed as such
into the prune_one() helper function, which worked in time_t to see
if an entry in the rerere database is past its expiry.

Instead, have the caller turn the number of days into the expiry
timestamp.  Further, use timestamp_t instead of time_t.  This will
make it possible to extend the way the configuration variable is
spelled by using date.c::parse_expiry_date() that gives the expiry
timestamp in timestamp_t.

Signed-off-by: Junio C Hamano 
---
 rerere.c | 36 +++-
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/rerere.c b/rerere.c
index 70634d456c..f0b4bce881 100644
--- a/rerere.c
+++ b/rerere.c
@@ -1133,14 +1133,14 @@ int rerere_forget(struct pathspec *pathspec)
  * Garbage collection support
  */
 
-static time_t rerere_created_at(struct rerere_id *id)
+static timestamp_t rerere_created_at(struct rerere_id *id)
 {
struct stat st;
 
return stat(rerere_path(id, "preimage"), ) ? (time_t) 0 : 
st.st_mtime;
 }
 
-static time_t rerere_last_used_at(struct rerere_id *id)
+static timestamp_t rerere_last_used_at(struct rerere_id *id)
 {
struct stat st;
 
@@ -1157,11 +1157,11 @@ static void unlink_rr_item(struct rerere_id *id)
id->collection->status[id->variant] = 0;
 }
 
-static void prune_one(struct rerere_id *id, time_t now,
- int cutoff_resolve, int cutoff_noresolve)
+static void prune_one(struct rerere_id *id,
+ timestamp_t cutoff_resolve, timestamp_t cutoff_noresolve)
 {
-   time_t then;
-   int cutoff;
+   timestamp_t then;
+   timestamp_t cutoff;
 
then = rerere_last_used_at(id);
if (then)
@@ -1172,25 +1172,35 @@ static void prune_one(struct rerere_id *id, time_t now,
return;
cutoff = cutoff_noresolve;
}
-   if (then < now - cutoff * 86400)
+   if (then < cutoff)
unlink_rr_item(id);
 }
 
+static void config_get_expiry(const char *key, timestamp_t *cutoff, 
timestamp_t now)
+{
+   int days;
+
+   if (!git_config_get_int(key, )) {
+   const int scale = 86400;
+   *cutoff = now - days * scale;
+   }
+}
+
 void rerere_gc(struct string_list *rr)
 {
struct string_list to_remove = STRING_LIST_INIT_DUP;
DIR *dir;
struct dirent *e;
int i;
-   time_t now = time(NULL);
-   int cutoff_noresolve = 15;
-   int cutoff_resolve = 60;
+   timestamp_t now = time(NULL);
+   timestamp_t cutoff_noresolve = now - 15 * 86400;
+   timestamp_t cutoff_resolve = now - 60 * 86400;
 
if (setup_rerere(rr, 0) < 0)
return;
 
-   git_config_get_int("gc.rerereresolved", _resolve);
-   git_config_get_int("gc.rerereunresolved", _noresolve);
+   config_get_expiry("gc.rerereresolved", _resolve, now);
+   config_get_expiry("gc.rerereunresolved", _noresolve, now);
git_config(git_default_config, NULL);
dir = opendir(git_path("rr-cache"));
if (!dir)
@@ -1211,7 +1221,7 @@ void rerere_gc(struct string_list *rr)
for (id.variant = 0, id.collection = rr_dir;
 id.variant < id.collection->status_nr;
 id.variant++) {
-   prune_one(, now, cutoff_resolve, cutoff_noresolve);
+   prune_one(, cutoff_resolve, cutoff_noresolve);
if (id.collection->status[id.variant])
now_empty = 0;
}
-- 
2.14.1-405-g52c75fc716

[PATCH 0/2] accept non-integer for "this many days" expiry specification

[Junio C Hamano]

About a month ago, we wondered why

[gc]
rerereResolved = 5.days

does not work and if we want to do something better.  

Here is a pair of patches that attempt to improve the situation.

Junio C Hamano (2):
  rerere: represent time duration in timestamp_t internally
  rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved

 Documentation/config.txt |  2 ++
 config.c |  4 ++--
 config.h |  3 +++
 rerere.c | 46 +-
 4 files changed, 40 insertions(+), 15 deletions(-)

-- 
2.14.1-405-g52c75fc716

[PATCH 2/2] rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved

[Junio C Hamano]

These two configuration variables are described in the documentation
to take an expiry period expressed in the number of days:

gc.rerereResolved::
Records of conflicted merge you resolved earlier are
kept for this many days when 'git rerere gc' is run.
The default is 60 days.

gc.rerereUnresolved::
Records of conflicted merge you have not resolved are
kept for this many days when 'git rerere gc' is run.
The default is 15 days.

There is no strong reason not to allow a more general "approxidate"
expiry specification, e.g. "5.days.ago", or "never".

Tweak the config_get_expiry() helper introduced in the previous step
to use date.c::parse_expiry_date() to do so.

In the future, we may find other variables that only allow an
integer that specifies "this many days" (or other unit of time) and
allow them to also do the same, and at that point we probably would
want to move the helper to a place that is not specific to the
rerere machinery.  Perhaps config.c would be such a good neutral
place, as it will allow git_parse_signed() to go back to static to
the file.

But this will do for now.

Signed-off-by: Junio C Hamano 
---
 Documentation/config.txt |  2 ++
 config.c |  4 ++--
 config.h |  3 +++
 rerere.c | 14 --
 4 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index d5c9c4cab6..ac95f5f954 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1553,11 +1553,13 @@ gc..reflogExpireUnreachable::
 gc.rerereResolved::
Records of conflicted merge you resolved earlier are
kept for this many days when 'git rerere gc' is run.
+   You can also use more human-readable "1.month.ago", etc.
The default is 60 days.  See linkgit:git-rerere[1].
 
 gc.rerereUnresolved::
Records of conflicted merge you have not resolved are
kept for this many days when 'git rerere gc' is run.
+   You can also use more human-readable "1.month.ago", etc.
The default is 15 days.  See linkgit:git-rerere[1].
 
 gitcvs.commitMsgAnnotation::
diff --git a/config.c b/config.c
index 231f9a750b..ac9071c5cf 100644
--- a/config.c
+++ b/config.c
@@ -769,7 +769,7 @@ static int parse_unit_factor(const char *end, uintmax_t 
*val)
return 0;
 }
 
-static int git_parse_signed(const char *value, intmax_t *ret, intmax_t max)
+int git_parse_signed(const char *value, intmax_t *ret, intmax_t max)
 {
if (value && *value) {
char *end;
@@ -799,7 +799,7 @@ static int git_parse_signed(const char *value, intmax_t 
*ret, intmax_t max)
return 0;
 }
 
-static int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max)
+int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max)
 {
if (value && *value) {
char *end;
diff --git a/config.h b/config.h
index 0352da117b..039a9295de 100644
--- a/config.h
+++ b/config.h
@@ -215,4 +215,7 @@ struct key_value_info {
 extern NORETURN void git_die_config(const char *key, const char *err, ...) 
__attribute__((format(printf, 2, 3)));
 extern NORETURN void git_die_config_linenr(const char *key, const char 
*filename, int linenr);
 
+int git_parse_unsigned(const char *value, uintmax_t *ret, uintmax_t max);
+int git_parse_signed(const char *value, intmax_t *ret, intmax_t max);
+
 #endif /* CONFIG_H */
diff --git a/rerere.c b/rerere.c
index f0b4bce881..8bbdfe8569 100644
--- a/rerere.c
+++ b/rerere.c
@@ -1178,11 +1178,21 @@ static void prune_one(struct rerere_id *id,
 
 static void config_get_expiry(const char *key, timestamp_t *cutoff, 
timestamp_t now)
 {
-   int days;
+   char *expiry_string;
+   intmax_t days;
+   timestamp_t when;
 
-   if (!git_config_get_int(key, )) {
+   if (git_config_get_string(key, _string))
+   return;
+
+   if (git_parse_signed(expiry_string, , 
maximum_signed_value_of_type(int))) {
const int scale = 86400;
*cutoff = now - days * scale;
+   return;
+   }
+
+   if (!parse_expiry_date(expiry_string, )) {
+   *cutoff = when;
}
 }
 
-- 
2.14.1-405-g52c75fc716

[PATCH 3/3] stash: add test for stashing in a detached state

[Joel Teichroeb]

All that we are really testing here is that the message is
correct when we are not on any branch. All other functionality is
already tested elsewhere.

Signed-off-by: Joel Teichroeb 
---
 t/t3903-stash.sh | 12 
 1 file changed, 12 insertions(+)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 887010c497..3b1ac1971a 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -822,6 +822,18 @@ test_expect_success 'create with multiple arguments for 
the message' '
test_cmp expect actual
 '
 
+test_expect_success 'create in a detached state' '
+   test_when_finished "git checkout master" &&
+   git checkout HEAD~1 &&
+   >foo &&
+   git add foo &&
+   STASH_ID=$(git stash create) &&
+   HEAD_ID=$(git rev-parse --short HEAD) &&
+   echo "WIP on (no branch): ${HEAD_ID} initial" >expect &&
+   git show --pretty=%s -s ${STASH_ID} >actual &&
+   test_cmp expect actual
+'
+
 test_expect_success 'stash --  stashes and restores the file' '
>foo &&
>bar &&
-- 
2.14.1

[PATCH 1/3] stash: add test for stash create with no files

[Joel Teichroeb]

Ensure the command suceeds and outputs nothing

Signed-off-by: Joel Teichroeb 
---
 t/t3903-stash.sh | 8 
 1 file changed, 8 insertions(+)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 4046817d70..f0708ced27 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -444,6 +444,14 @@ test_expect_failure 'stash file to directory' '
test foo = "$(cat file/file)"
 '
 
+test_expect_success 'stash create - no changes' '
+   git stash clear &&
+   test_when_finished "git reset --hard HEAD" &&
+   git reset --hard &&
+   git stash create >actual &&
+   test_must_be_empty actual
+'
+
 test_expect_success 'stash branch - no stashes on stack, stash-like argument' '
git stash clear &&
test_when_finished "git reset --hard HEAD" &&
-- 
2.14.1

[PATCH 2/3] stash: Add a test for when apply fails during stash branch

[Joel Teichroeb]

If the return value of merge recursive is not checked, the stash could end
up being dropped even though it was not applied properly

Signed-off-by: Joel Teichroeb 
---
 t/t3903-stash.sh | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index f0708ced27..887010c497 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -656,6 +656,20 @@ test_expect_success 'stash branch should not drop the 
stash if the branch exists
git rev-parse stash@{0} --
 '
 
+test_expect_success 'stash branch should not drop the stash if the apply 
fails' '
+   git stash clear &&
+   git reset HEAD~1 --hard &&
+   echo foo >file &&
+   git add file &&
+   git commit -m initial &&
+   echo bar >file &&
+   git stash &&
+   echo baz >file &&
+   test_when_finished "git checkout master" &&
+   test_must_fail git stash branch new_branch stash@{0} &&
+   git rev-parse stash@{0} --
+'
+
 test_expect_success 'stash apply shows status same as git status (relative to 
current directory)' '
git stash clear &&
echo 1 >subdir/subfile1 &&
-- 
2.14.1

Re: Please fix the useless email prompts

[Patryk Obara]

Why you can't just set username as name and username@hostname as mail?
You'll do it once and it will be preserved for future. If you use
various accounts for testing, use --system flag for config to store
the values in /etc. If you don't want to modify the environment, use
--local (or no flag) to preserve name in your cloned repository only.

-- 
| ← Ceci n'est pas une pipe
Patryk Obara

SMTP FOR SALE

[SMTP]

FRESH SMTP FOR SALE AT $1.25 PER ONE(1) SMTP LOGIN THAT HAS THE CAPACITY TO 
SEND OUT 10,000 EMAILS AT A GO. PLS DO NOTE THE LEAST PURCHASE ORDER IS 20 SMTP 
LOGINS(1 PACK) AND ABOVE AT AN ACCUMALTED COST OF $25.


* BEST USED WITH TURBO MAILER.

* ONE(1) SMTP LOGIN CAN ALSO BE GIVEN OUT TO FIRST TIME BUYERS FOR CONFIRMATION 
INCLUDING THE REQUIRED SMTP SERVER TO ALLOW YOU SEND OUT CONVIENIENTLY. AND ALL 
20 SMTP LOGIN WILL ALSO BE TESTED TO YOUR PERSONAL EMAIL TOO UPON PAYMENT OF 
FUNDS. 

*PLACED ORDER CAN BE READY WITHIN 3 TO 4HRS.

*METHOD OF PAYMENT ( perfect money )



IF NEEDED KINDLY CONTACT:
EMAIL ID: smtptools...@gmail.com

PHONE: +2349028112309

Re: Submodule regression in 2.14?

[Lars Schneider]

> On 18 Aug 2017, at 19:16, Stefan Beller  wrote:
> 
>> In the past "submodule..update=none" was an easy way
>> to selectively disable certain Submodules.
>> 
>> How would I do this with Git 2.14?
> 
>submodule..active = false

That's what I thought after your first response. However,
this test case fails for me, too:


diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index dcac364c5f..24f9729015 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -1289,4 +1289,19 @@ test_expect_success 'init properly sets the config' '
test_must_fail git -C multisuper_clone config --get 
submodule.sub1.active
'

+test_expect_success 'submodule update and git pull with disabled submodule' '
+   test_when_finished "rm -rf multisuper_clone" &&
+   pwd=$(pwd) &&
+   git clone file://"$pwd"/multisuper multisuper_clone &&
+   (
+   cd multisuper_clone &&
+   git config --local submodule.sub0.update none &&
+   git config --local submodule.sub0.active false &&
+   git submodule update --init --recursive &&
+   git pull --recurse-submodules &&
+   git submodule status | cut -c 1,43- >actual
+   ) &&
+   ls &&
+   test_cmp expect multisuper_clone/actual
+'
+
test_done


Here is the relevant part of the Git config:

[submodule "sub0"]
update = none
active = false

Is this a bug?


>> My gut feeling is that all commands should respect the
>> "submodule..update=none" setting.
> 
> Well my gut feeling was that the "update" part of the name
> reponds to the subcommand, not the generic action.

I see. But wouldn't that be inconsistent with the config
"active" then? Following that logic "active" would only
respond to the (non-existent) "active" subcommand, no?


> For example when you set update=none, git-status,
> recursive git-diff still reported the submodule.

My understanding is this:

(1) "active" controls if a submodule is considered by
Git at all.

(2) "update" controls how and if the submodule pointer
modified

Is this your intention? What would be the use case for
"active=true" and "update=none"? 


- Lars

Re: Please fix the useless email prompts

[Jeffrey Walton]

On Sat, Aug 19, 2017 at 12:36 PM, Junio C Hamano  wrote:
> Jeffrey Walton  writes:
>
>> Is it possible to fix the issue shown below?
>>
>> I'm on a test machine. All I do is update to the latest code, build
>> the library and run the self tests.
>>
>> The test user account does not have a name and does not have an email
>> address. There's nothing to provide.
>>
>> There's no reason to break my workflows for useless Git policies like
>> "please tell me your email address". Its not my policy, and there's
>> nothing critical about it.
>>
>> ...
> Hasn't this been asked and answered already?
>
> 
> https://public-inbox.org/git/cacbzzx4veod-4a-ek-ubxmfrb1glsvjkxhw51whcsbczdh7...@mail.gmail.com/

Its 2017. I'd like the tools to work for me instead of me working for the tools.

Jeff

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

[Junio C Hamano]

René Scharfe  writes:

> No, it's "archive empty subtree by direct pathspec" that's broken.  Gah!
>
>> omitting the empty directory from the archive.  Sorry for missing that!
>> 
>> This is kind of a bonus patch, so please discard it for now; the first
>> three are OK IMHO.

Ah, our mails crossed.  Thanks; will drop the last one for now.

[PATCH] progress: simplify "delayed" progress API

[Junio C Hamano]

We used to expose the full power of the delayed progress API to the
callers, so that they can specify, not just the message to show and
expected total amount of work that is used to compute the percentage
of work performed so far, the percent-threshold parameter P and the
delay-seconds parameter N.  The progress meter starts to show at N
seconds into the operation only if the amount of work completed
exceeds P.

Most callers used either (0%, 2s) or (50%, 1s) as (P, N), but there
are oddballs that chose more random-looking values like 95%.

For a smoother workload, (50%, 1s) would allow us to start showing
the progress meter earlier than (0%, 2s), while keeping the chance
of not showing progress meter for long running operation the same as
the latter.  For a task that would take 2s or more to complete, it
is likely that less than half of it would complete within the first
second, if the workload is smooth.  But for a spiky workload whose
earlier part is easier, such a setting is likely to fail to show the
progress meter entirely and (0%, 2s) is more appropriate.

But that is merely a theory.  Realistically, it is of dubious value
to ask each codepath to carefully consider smoothness of their
workload and specify their own setting by passing two extra
parameters.  Let's simplify the API by dropping both parameters and
have everybody use (0%, 2s).

Oh, by the way, the percent-threshold parameter and the structure
member were consistently misspelled, which also is now fixed ;-)

Helped-by: Jeff King 
Signed-off-by: Junio C Hamano 
---

 * So before I forget all about this topic, here is a patch to
   actually do this.

   > So I'd vote to drop that parameter entirely. And if 1 second seems
   > noticeably snappier, then we should probably just move everything to a 1
   > second delay (I don't have a strong feeling either way).

   I was also tempted to do this, but decided to keep it closer to
   the original for majority of callers by leaving the delay at 2s.
   With this patch, such a change as a follow-up is made a lot
   easier (somebody may want to even make a configuration out of it,
   but that would not be me).

 builtin/blame.c|  3 +--
 builtin/fsck.c |  2 +-
 builtin/prune-packed.c |  3 +--
 builtin/prune.c|  2 +-
 builtin/rev-list.c |  2 +-
 diffcore-rename.c  |  4 ++--
 progress.c | 15 ++-
 progress.h |  3 +--
 unpack-trees.c |  3 +--
 9 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/builtin/blame.c b/builtin/blame.c
index bda1a78726..e0daf17548 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -925,8 +925,7 @@ int cmd_blame(int argc, const char **argv, const char 
*prefix)
sb.found_guilty_entry = _guilty_entry;
sb.found_guilty_entry_data = 
if (show_progress)
-   pi.progress = start_progress_delay(_("Blaming lines"),
-  sb.num_lines, 50, 1);
+   pi.progress = start_delayed_progress(_("Blaming lines"), 
sb.num_lines);
 
assign_blame(, opt);
 
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 99dea7adf6..0031439fc4 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -188,7 +188,7 @@ static int traverse_reachable(void)
unsigned int nr = 0;
int result = 0;
if (show_progress)
-   progress = start_progress_delay(_("Checking connectivity"), 0, 
0, 2);
+   progress = start_delayed_progress(_("Checking connectivity"), 
0);
while (pending.nr) {
struct object_array_entry *entry;
struct object *obj;
diff --git a/builtin/prune-packed.c b/builtin/prune-packed.c
index ac978ad401..8f41f7c20e 100644
--- a/builtin/prune-packed.c
+++ b/builtin/prune-packed.c
@@ -37,8 +37,7 @@ static int prune_object(const struct object_id *oid, const 
char *path,
 void prune_packed_objects(int opts)
 {
if (opts & PRUNE_PACKED_VERBOSE)
-   progress = start_progress_delay(_("Removing duplicate objects"),
-   256, 95, 2);
+   progress = start_delayed_progress(_("Removing duplicate 
objects"), 256);
 
for_each_loose_file_in_objdir(get_object_directory(),
  prune_object, NULL, prune_subdir, );
diff --git a/builtin/prune.c b/builtin/prune.c
index c378690545..cddabf26a9 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -138,7 +138,7 @@ int cmd_prune(int argc, const char **argv, const char 
*prefix)
if (show_progress == -1)
show_progress = isatty(2);
if (show_progress)
-   progress = start_progress_delay(_("Checking connectivity"), 0, 
0, 2);
+   progress = start_delayed_progress(_("Checking connectivity"), 
0);
 
mark_reachable_objects(, 1, expire, progress);
stop_progress();
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

[René Scharfe]

Am 19.08.2017 um 18:53 schrieb René Scharfe:
> Am 19.08.2017 um 07:33 schrieb René Scharfe:
>> When read_tree_recursive() encounters a directory excluded by a pathspec
>> then it enters it anyway because it might contain included entries.  It
>> calls the callback function before it is able to decide if the directory
>> is actually needed.
>>
>> For that reason git archive adds directories to a queue and writes
>> entries for them only when it encounters the first child item -- but
>> only if pathspecs with wildcards are used.  Do the same for literal
>> pathspecs as well, as the reasoning above applies to them, too.  This
>> prevents git archive from writing entries for excluded directories.
> 
> This breaks the test "archive empty subtree with no pathspec" in t5004 by

No, it's "archive empty subtree by direct pathspec" that's broken.  Gah!

> omitting the empty directory from the archive.  Sorry for missing that!
> 
> This is kind of a bonus patch, so please discard it for now; the first
> three are OK IMHO.
> 
> A better version of this patch would at least update t5004 as well, but
> there might be a better way.
> 
>>
>> Signed-off-by: Rene Scharfe 
>> ---
>>archive.c   | 2 +-
>>t/t5001-archive-attr.sh | 2 +-
>>2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/archive.c b/archive.c
>> index 1ab8d3a1d7..174c0555b6 100644
>> --- a/archive.c
>> +++ b/archive.c
>> @@ -123,7 +123,7 @@ static int check_attr_export_subst(const struct 
>> attr_check *check)
>>
>>static int should_queue_directories(const struct archiver_args *args)
>>{
>> -return args->pathspec.has_wildcard;
>> +return args->pathspec.nr;
>>}
>>
>>static int write_archive_entry(const unsigned char *sha1, const char 
>> *base,
>> diff --git a/t/t5001-archive-attr.sh b/t/t5001-archive-attr.sh
>> index 897f6f06d5..e9aa97117a 100755
>> --- a/t/t5001-archive-attr.sh
>> +++ b/t/t5001-archive-attr.sh
>> @@ -73,7 +73,7 @@ test_expect_missingarchive-pathspec/ignored-by-tree
>>test_expect_missing   archive-pathspec/ignored-by-tree.d
>>test_expect_missing   archive-pathspec/ignored-by-tree.d/file
>>test_expect_existsarchive-pathspec/ignored-by-worktree
>> -test_expect_missing archive-pathspec/excluded-by-pathspec.d failure
>> +test_expect_missing archive-pathspec/excluded-by-pathspec.d
>>test_expect_missing   archive-pathspec/excluded-by-pathspec.d/file
>>
>>test_expect_success 'git archive with wildcard pathspec' '
>>

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

[Junio C Hamano]

René Scharfe  writes:

> When read_tree_recursive() encounters a directory excluded by a pathspec
> then it enters it anyway because it might contain included entries.  It
> calls the callback function before it is able to decide if the directory
> is actually needed.
>
> For that reason git archive adds directories to a queue and writes
> entries for them only when it encounters the first child item -- but
> only if pathspecs with wildcards are used.  Do the same for literal
> pathspecs as well, as the reasoning above applies to them, too.  This
> prevents git archive from writing entries for excluded directories.
>
> Signed-off-by: Rene Scharfe 
> ---
>  archive.c   | 2 +-
>  t/t5001-archive-attr.sh | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

This seems to break t/t5004-archive-corner-cases.sh though...

expecting success:
git archive --format=tar $root_tree -- sub >subtree-path.tar &&
make_dir extract &&
"$TAR" xf subtree-path.tar -C extract &&
check_dir extract sub

--- expect  2017-08-19 16:56:49.761513537 +
+++ actual  2017-08-19 16:56:49.769513535 +
@@ -1,2 +1 @@
 extract
-extract/sub
not ok 10 - archive empty subtree by direct pathspec

> diff --git a/archive.c b/archive.c
> index 1ab8d3a1d7..174c0555b6 100644
> --- a/archive.c
> +++ b/archive.c
> @@ -123,7 +123,7 @@ static int check_attr_export_subst(const struct 
> attr_check *check)
>  
>  static int should_queue_directories(const struct archiver_args *args)
>  {
> - return args->pathspec.has_wildcard;
> + return args->pathspec.nr;
>  }
>  
>  static int write_archive_entry(const unsigned char *sha1, const char *base,
> diff --git a/t/t5001-archive-attr.sh b/t/t5001-archive-attr.sh
> index 897f6f06d5..e9aa97117a 100755
> --- a/t/t5001-archive-attr.sh
> +++ b/t/t5001-archive-attr.sh
> @@ -73,7 +73,7 @@ test_expect_missing archive-pathspec/ignored-by-tree
>  test_expect_missing  archive-pathspec/ignored-by-tree.d
>  test_expect_missing  archive-pathspec/ignored-by-tree.d/file
>  test_expect_exists   archive-pathspec/ignored-by-worktree
> -test_expect_missing  archive-pathspec/excluded-by-pathspec.d failure
> +test_expect_missing  archive-pathspec/excluded-by-pathspec.d
>  test_expect_missing  archive-pathspec/excluded-by-pathspec.d/file
>  
>  test_expect_success 'git archive with wildcard pathspec' '

Re: [PATCH 4/4] archive: queue directories for all types of pathspecs

[René Scharfe]

Am 19.08.2017 um 07:33 schrieb René Scharfe:
> When read_tree_recursive() encounters a directory excluded by a pathspec
> then it enters it anyway because it might contain included entries.  It
> calls the callback function before it is able to decide if the directory
> is actually needed.
> 
> For that reason git archive adds directories to a queue and writes
> entries for them only when it encounters the first child item -- but
> only if pathspecs with wildcards are used.  Do the same for literal
> pathspecs as well, as the reasoning above applies to them, too.  This
> prevents git archive from writing entries for excluded directories.

This breaks the test "archive empty subtree with no pathspec" in t5004 by
omitting the empty directory from the archive.  Sorry for missing that!

This is kind of a bonus patch, so please discard it for now; the first
three are OK IMHO.

A better version of this patch would at least update t5004 as well, but
there might be a better way.

> 
> Signed-off-by: Rene Scharfe 
> ---
>   archive.c   | 2 +-
>   t/t5001-archive-attr.sh | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/archive.c b/archive.c
> index 1ab8d3a1d7..174c0555b6 100644
> --- a/archive.c
> +++ b/archive.c
> @@ -123,7 +123,7 @@ static int check_attr_export_subst(const struct 
> attr_check *check)
>   
>   static int should_queue_directories(const struct archiver_args *args)
>   {
> - return args->pathspec.has_wildcard;
> + return args->pathspec.nr;
>   }
>   
>   static int write_archive_entry(const unsigned char *sha1, const char *base,
> diff --git a/t/t5001-archive-attr.sh b/t/t5001-archive-attr.sh
> index 897f6f06d5..e9aa97117a 100755
> --- a/t/t5001-archive-attr.sh
> +++ b/t/t5001-archive-attr.sh
> @@ -73,7 +73,7 @@ test_expect_missing archive-pathspec/ignored-by-tree
>   test_expect_missing archive-pathspec/ignored-by-tree.d
>   test_expect_missing archive-pathspec/ignored-by-tree.d/file
>   test_expect_exists  archive-pathspec/ignored-by-worktree
> -test_expect_missing  archive-pathspec/excluded-by-pathspec.d failure
> +test_expect_missing  archive-pathspec/excluded-by-pathspec.d
>   test_expect_missing archive-pathspec/excluded-by-pathspec.d/file
>   
>   test_expect_success 'git archive with wildcard pathspec' '
> 

Re: [PATCH] commit: remove unused inline function single_parent()

[Junio C Hamano]

Thanks.

Re: Please fix the useless email prompts

[Junio C Hamano]

Jeffrey Walton  writes:

> Is it possible to fix the issue shown below?
>
> I'm on a test machine. All I do is update to the latest code, build
> the library and run the self tests.
>
> The test user account does not have a name and does not have an email
> address. There's nothing to provide.
>
> There's no reason to break my workflows for useless Git policies like
> "please tell me your email address". Its not my policy, and there's
> nothing critical about it.
>
> Jeff
>
> **
>
> $ git pull
>
> *** Please tell me who you are.
>
> Run
>
>   git config --global user.email "y...@example.com"
>   git config --global user.name "Your Name"
>
> to set your account's default identity.
> Omit --global to set the identity only in this repository.
>
> fatal: unable to auto-detect email address (got 'test@via.(none)')

Hasn't this been asked and answered already?


https://public-inbox.org/git/cacbzzx4veod-4a-ek-ubxmfrb1glsvjkxhw51whcsbczdh7...@mail.gmail.com/

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

[Junio C Hamano]

Torsten Bögershausen  writes:

>> * tb/apply-with-crlf (2017-08-17) 3 commits
>>  - SQUASH???
>>  - apply: file commited with CRLF should roundtrip diff and apply
>>  - convert: add SAFE_CRLF_KEEP_CRLF
>>  (this branch is tangled with jc/apply-with-crlf.)
>> 
>>  Will merge to 'next' after squashing the fix in.
>> ...
>
> I will send V4 in a second (hopefully the last version)

Thanks.  Will replace.

Please fix the useless email prompts

[Jeffrey Walton]

Is it possible to fix the issue shown below?

I'm on a test machine. All I do is update to the latest code, build
the library and run the self tests.

The test user account does not have a name and does not have an email
address. There's nothing to provide.

There's no reason to break my workflows for useless Git policies like
"please tell me your email address". Its not my policy, and there's
nothing critical about it.

Jeff

**

$ git pull

*** Please tell me who you are.

Run

  git config --global user.email "y...@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'test@via.(none)')

Re: git svn show-externals output format

[Alexander Groß]

> My practical solution was to skip the man in the middle and ask the SVN
> server directly for the property values

Thanks, that helped a lot!

Alex
Beste Grüße,

Alex
-- 
Alexander Groß
http://therightstuff.de/


On Sat, Aug 19, 2017 at 12:14 PM, Andreas Heiduk  wrote:
> Am 19.08.2017 um 10:24 schrieb Alexander Groß:
>
>> $ git svn show-externals
>>
>> # /trunk/
>> /trunk/https://svn.code.sf.net/p/gc-webdav/svn webdav
>> /trunk/https://svn.code.sf.net/p/gc-webdav/svn@1 webdav-at-revision
>
> This is the (bugged) output of `git svn show-externals` for "new
> style" svn:externals.
>
>>
>> # /trunk/sub directory/
>> /trunk/sub directory/https://svn.code.sf.net/p/gc-webdav/svn 'webdav in 
>> subdir'
>>
>> An earlier version contains just one external:
>>
>> $ git svn show-externals --revision 8
>>
>> # /trunk/
>> /trunk/webdav https://svn.code.sf.net/p/gc-webdav/svn/
>
> And that the proper output for "old style" svn:externals.
>
>> It seems like the output is inconsistent. [...]
>
> SVN changed/extended the svn:externals format in version 1.5.
> (See [1] for details). One thing is - they switched the
> order of the arguments. `git svn` dit not pick up these changes
> and hence interprets the new format incorrectly. See [2] for
> a similar discussion - it is from 2012!
>
>> This makes consuming the output of git svn show-externals in HEAD
>> difficult because the parts are not clearly separated by space and
>> sometimes the path is the first element, sometimes it's a combination
>> of first and last elements.
>
> My practical solution was to skip the man in the middle and ask the SVN
> server directly for the property values with something like that:
>
> svn propget svn:externals -r 42 http://my-repo-url/path/to/ext/dir
>
> I used the output to hardcode the values during the conversion.
>
>
>
> [1] http://svnbook.red-bean.com/en/1.8/svn.advanced.externals.html
> [2] 
> https://public-inbox.org/git/e59cce45-6f92-4748-9b6e-2a5626479...@nikolaus-demmel.de/

git-svn: Handling of branches created from subfolders

[Jan Teske]

Hello,

I’m trying to do a one-time conversion of a large SVN repository to git using 
git-svn. Unfortunately, this SVN repo contains a substantial amount of 
non-standard branches created from a subfolder of trunk/. Users that only need 
to work on part of the code inside the repo usually create such branches to 
avoid having to download unneeded files.

A toy example showing what I’m talking about:

trunk/
- subfolder1/
- …
- subfolder2/
- …
branches/
- branch1/ (initially cp’ed from trunk/subfolder1)
- …
- branch2/ (initially cp’ed from trunk/subfolder2)
- …
- branch3/ (initially cp’ed from trunk)
- …

While in my experience, git-svn is able to correctly handle branches/branch3, 
it fails on branch1 and branch2. By "fails" I mean that it still performs the 
conversion, but any relationship to the trunk is completely missing. Instead, 
in the resulting git repository it looks like those branches have a completely 
separate history, starting from nothing.

Is there any way to fix such branches from subfolders in a way that they 
integrate correctly with the converted git repository, without losing any (or 
at least too much) history? If this is not possible with git-svn directly, 
maybe I could prepare the SVN repo or post-process the converted git repository 
somehow?

Thanks!

[PATCH v4 2/2] File commited with CRLF should roundtrip diff and apply

[tboegi]

From: Torsten Bögershausen 

When a file had been commited with CRLF but now .gitattributes say
"* text=auto" (or core.autocrlf is true),
the following does not roundtrip, `git apply` fails:

printf "Added line\r\n" >>file &&
git diff >patch &&
git checkout -- . &&
git apply patch

Before applying the patch, the file from working tree is converted into the
index format (clean filter, CRLF conversion, ...)
Here, when commited with CRLF, the line endings should not be converted.

Note that `git apply --index` or `git apply --cache` doesn't call
convert_to_git() because the source material is already in index format.

Analyze the patch if there is a) any context line with CRLF,
or b) if any line with CRLF is to be removed.
In this case the patch file `patch` has mixed line endings, for a)
it looks like this:

 diff --git a/one b/one
 index 533790e..c30dea8 100644
 --- a/one
 +++ b/one
 @@ -1 +1,2 @@
  a\r
 +b\r

And for b) it looks like this:

 diff --git a/one b/one
 index 533790e..485540d 100644
 --- a/one
 +++ b/one
 @@ -1 +1 @@
 -a\r
 +b\r

If `git apply` detects that the patch itself has CRLF, (look at the line
" a\r" or "-a\r" above), the new flag crlf_in_old is set in "struct patch"
and two things will happen:
- read_old_data() will not convert CRLF into LF by calling
  convert_to_git(..., SAFE_CRLF_KEEP_CRLF);
- The WS_CR_AT_EOL bit is set in the "white space rule",
  CRLF are no longer treated as white space.

While at there, make clear that read_old_data() in apply.c
knows what it wants convert_to_git() to do with respect to CRLF.  In
fact, this codepath is about applying a patch to a file in the
filesystem, which may not exist in the index, or may exist but may
not match what is recorded in the index, or in the extreme case, we
may not even be in a Git repository.  If convert_to_git() peeked at
the index while doing its work, it *would* be a bug.

Pass NULL instead of _index to convert_to_git() to make sure we
catch future bugs to clarify this.

Update the test in t4124: split one test case into 3:
- Detect the " a\r" line in the patch
- Detect the "-a\r" line in the patch
- Use LF in repo and CLRF in the worktree.

Reported-by: Anthony Sottile 
Helped-by: Junio C Hamano 
Signed-off-by: Torsten Bögershausen 
---

Changes since v3:
- took apply.c from junio/tb/apply-with-crlf
- Remove the leading asterix in the commit message, at the place
  where the "git diff" is cited.
- Mention "Pass NULL instead of _index to convert_to_git()"

apply.c  | 41 -
 t/t4124-apply-ws-rule.sh | 33 +++--
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/apply.c b/apply.c
index f2d599141d..66c68f193a 100644
--- a/apply.c
+++ b/apply.c
@@ -220,6 +220,7 @@ struct patch {
unsigned int recount:1;
unsigned int conflicted_threeway:1;
unsigned int direct_to_threeway:1;
+   unsigned int crlf_in_old:1;
struct fragment *fragments;
char *result;
size_t resultsize;
@@ -1662,6 +1663,19 @@ static void check_whitespace(struct apply_state *state,
record_ws_error(state, result, line + 1, len - 2, state->linenr);
 }
 
+/*
+ * Check if the patch has context lines with CRLF or
+ * the patch wants to remove lines with CRLF.
+ */
+static void check_old_for_crlf(struct patch *patch, const char *line, int len)
+{
+   if (len >= 2 && line[len-1] == '\n' && line[len-2] == '\r') {
+   patch->ws_rule |= WS_CR_AT_EOL;
+   patch->crlf_in_old = 1;
+   }
+}
+
+
 /*
  * Parse a unified diff. Note that this really needs to parse each
  * fragment separately, since the only way to know the difference
@@ -1712,11 +1726,14 @@ static int parse_fragment(struct apply_state *state,
if (!deleted && !added)
leading++;
trailing++;
+   check_old_for_crlf(patch, line, len);
if (!state->apply_in_reverse &&
state->ws_error_action == correct_ws_error)
check_whitespace(state, line, len, 
patch->ws_rule);
break;
case '-':
+   if (!state->apply_in_reverse)
+   check_old_for_crlf(patch, line, len);
if (state->apply_in_reverse &&
state->ws_error_action != nowarn_ws_error)
check_whitespace(state, line, len, 
patch->ws_rule);
@@ -1725,6 +1742,8 @@ static int parse_fragment(struct apply_state *state,
trailing = 0;
break;
case '+':
+   if (state->apply_in_reverse)
+   check_old_for_crlf(patch, line, len);
if (!state->apply_in_reverse &&
  

[PATCH v4 1/2] convert: Add SAFE_CRLF_KEEP_CRLF

[tboegi]

From: Torsten Bögershausen 

When convert_to_git() is called, the caller may want to keep CRLF
to be kept as CRLF (and not converted into LF).

This will be used in the next commit, when apply works with files that have
CRLF and patches are applied onto these files.

Add the new value "SAFE_CRLF_KEEP_CRLF" to safe_crlf.

Prepare convert_to_git() to be able to run the clean filter,
skip the CRLF conversion and run the ident filter.

Signed-off-by: Torsten Bögershausen 
---
 convert.c | 10 ++
 convert.h |  3 ++-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/convert.c b/convert.c
index deaf0ba7b3..040123b4fe 100644
--- a/convert.c
+++ b/convert.c
@@ -1104,10 +1104,12 @@ int convert_to_git(const struct index_state *istate,
src = dst->buf;
len = dst->len;
}
-   ret |= crlf_to_git(istate, path, src, len, dst, ca.crlf_action, 
checksafe);
-   if (ret && dst) {
-   src = dst->buf;
-   len = dst->len;
+   if (checksafe != SAFE_CRLF_KEEP_CRLF) {
+   ret |= crlf_to_git(istate, path, src, len, dst, ca.crlf_action, 
checksafe);
+   if (ret && dst) {
+   src = dst->buf;
+   len = dst->len;
+   }
}
return ret | ident_to_git(path, src, len, dst, ca.ident);
 }
diff --git a/convert.h b/convert.h
index cecf59d1aa..cabd5ed6dd 100644
--- a/convert.h
+++ b/convert.h
@@ -10,7 +10,8 @@ enum safe_crlf {
SAFE_CRLF_FALSE = 0,
SAFE_CRLF_FAIL = 1,
SAFE_CRLF_WARN = 2,
-   SAFE_CRLF_RENORMALIZE = 3
+   SAFE_CRLF_RENORMALIZE = 3,
+   SAFE_CRLF_KEEP_CRLF = 4
 };
 
 extern enum safe_crlf safe_crlf;
-- 
2.14.0.rc1.15.gd40c2d4e85.dirty

Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)

[Torsten Bögershausen]

> * tb/apply-with-crlf (2017-08-17) 3 commits
>  - SQUASH???
>  - apply: file commited with CRLF should roundtrip diff and apply
>  - convert: add SAFE_CRLF_KEEP_CRLF
>  (this branch is tangled with jc/apply-with-crlf.)
> 
>  "git apply" that is used as a better "patch -p1" failed to apply a
>  taken from a file with CRLF line endings to a file with CRLF line
>  endings.  The root cause was because it misused convert_to_git()
>  that tried to do "safe-crlf" processing by looking at the index
>  entry at the same path, which is a nonsense---in that mode, "apply"
>  is not working on the data in (or derived from) the index at all.
>  This has been fixed.
> 
>  Will merge to 'next' after squashing the fix in.
> 
> 
> * rs/t1002-do-not-use-sum (2017-08-15) 1 commit
>  - t1002: stop using sum(1)
> 
>  Test simplification.
> 
>  Will merge to 'next'.
> 
> 
> * sb/sha1-file-cleanup (2017-08-15) 1 commit
>  - sha1_file: make read_info_alternates static
> 
>  Code clean-up.
> 
>  Will merge to 'next'.
> 
> 
> * as/grep-quiet-no-match-exit-code-fix (2017-08-17) 1 commit
>  - git-grep: correct exit code with --quiet and -L
> 
>  "git grep -L" and "git grep --quiet -L" reported different exit
>  codes; this has been corrected.
> 
>  Will merge to 'next'.
> 
> 
> * hv/t5526-andand-chain-fix (2017-08-17) 1 commit
>  - t5526: fix some broken && chains
> 
>  Test fix.
> 
>  Will merge to 'next'.
> 
> 
> * jc/diff-sane-truncate-no-more (2017-08-17) 1 commit
>  - diff: retire sane_truncate_fn
> 
>  Code clean-up.
> 
>  Will merge to 'next'.
> 
> 
> * ks/branch-set-upstream (2017-08-17) 3 commits
>  - branch: quote branch/ref names to improve readability
>  - builtin/branch: stop supporting the "--set-upstream" option
>  - t3200: cleanup cruft of a test
> 
>  "branch --set-upstream" that has been deprecated in Git 1.8 has
>  finally been retired.
> 
>  Will merge to 'next'.
> 
> 
> * mg/format-ref-doc-fix (2017-08-18) 2 commits
>  - Documentation/git-for-each-ref: clarify peeling of tags for --format
>  - Documentation: use proper wording for ref format strings
> 
>  Doc fix.
> 
>  Will merge to 'next'.
> 
> 
> * po/read-graft-line (2017-08-18) 4 commits
>  - commit: rewrite read_graft_line
>  - commit: allocate array using object_id size
>  - commit: replace the raw buffer with strbuf in read_graft_line
>  - sha1_file: fix definition of null_sha1
> 
>  Conversion from uchar[20] to struct object_id continues; this is to
>  ensure that we do not assume sizeof(struct object_id) is the same
>  as the length of SHA-1 hash (or length of longest hash we support).
> 
>  Will merge to 'next'.
> 
> 
> * sb/submodule-parallel-update (2017-08-17) 1 commit
>  - submodule.sh: remove unused variable
> 
>  Code clean-up.
> 
>  Will merge to 'next'.
> 
> 
> * jc/apply-with-crlf (2017-08-16) 6 commits
>  . apply: clarify read_old_data() is about no-index case
>  . apply: localize the CRLF business to read_old_data()
>  . apply: only pay attention to CRLF in the preimage
>  . apply: remove unused field apply_state.flags
>  . apply: file commited with CRLF should roundtrip diff and apply
>  - convert: add SAFE_CRLF_KEEP_CRLF
>  (this branch is tangled with tb/apply-with-crlf.)
> 
>  Will discard as it now is part of the tb/apply-with-crlf topic.
> 
> --
> [Stalled]
> 
> * mg/status-in-progress-info (2017-05-10) 2 commits
>  - status --short --inprogress: spell it as --in-progress
>  - status: show in-progress info for short status
> 
>  "git status" learns an option to report various operations
>  (e.g. "merging") that the user is in the middle of.
> 
>  cf. 
> 
> 
> * nd/worktree-move (2017-04-20) 6 commits
>  - worktree remove: new command
>  - worktree move: refuse to move worktrees with submodules
>  - worktree move: accept destination as directory
>  - worktree move: new command
>  - worktree.c: add update_worktree_location()
>  - worktree.c: add validate_worktree()
> 
>  "git worktree" learned move and remove subcommands.
> 
>  Expecting a reroll.
>  cf. <20170420101024.7593-1-pclo...@gmail.com>
>  cf. <20170421145916.mknekgqzhxffu...@sigill.intra.peff.net>
>  cf. 
> 
> 
> * sg/clone-refspec-from-command-line-config (2017-06-16) 2 commits
>  - Documentation/clone: document ignored configuration variables
>  - clone: respect additional configured fetch refspecs during initial fetch
>  (this branch is used by sg/remote-no-string-refspecs.)
> 
>  "git clone -c var=val" is a way to set configuration variables in
>  the resulting repository, but it is more useful to also make these
>  variables take effect while the initial clone is happening,
>  e.g. these configuration variables could be fetch refspecs.
> 
>  Waiting for a response.
>  cf. <20170617112228.vugswym4o4owf...@sigill.intra.peff.net>
>  cf. 
> 
> 
> * js/rebase-i-final (2017-07-27) 

Re: git svn show-externals output format

[Andreas Heiduk]

Am 19.08.2017 um 10:24 schrieb Alexander Groß:

> $ git svn show-externals
> 
> # /trunk/
> /trunk/https://svn.code.sf.net/p/gc-webdav/svn webdav
> /trunk/https://svn.code.sf.net/p/gc-webdav/svn@1 webdav-at-revision

This is the (bugged) output of `git svn show-externals` for "new
style" svn:externals.

> 
> # /trunk/sub directory/
> /trunk/sub directory/https://svn.code.sf.net/p/gc-webdav/svn 'webdav in 
> subdir'
> 
> An earlier version contains just one external:
> 
> $ git svn show-externals --revision 8
> 
> # /trunk/
> /trunk/webdav https://svn.code.sf.net/p/gc-webdav/svn/

And that the proper output for "old style" svn:externals.

> It seems like the output is inconsistent. [...]

SVN changed/extended the svn:externals format in version 1.5.
(See [1] for details). One thing is - they switched the
order of the arguments. `git svn` dit not pick up these changes
and hence interprets the new format incorrectly. See [2] for 
a similar discussion - it is from 2012!

> This makes consuming the output of git svn show-externals in HEAD
> difficult because the parts are not clearly separated by space and
> sometimes the path is the first element, sometimes it's a combination
> of first and last elements.

My practical solution was to skip the man in the middle and ask the SVN
server directly for the property values with something like that:

svn propget svn:externals -r 42 http://my-repo-url/path/to/ext/dir

I used the output to hardcode the values during the conversion.



[1] http://svnbook.red-bean.com/en/1.8/svn.advanced.externals.html
[2] 
https://public-inbox.org/git/e59cce45-6f92-4748-9b6e-2a5626479...@nikolaus-demmel.de/

git svn show-externals output format

[Alexander Groß]

Hi all,

I am playing with svn-to-git conversion and wanted to have a look at
the svn:externals of a test SVN repository.

$ git svn clone svn://svn.code.sf.net/p/svn-to-git/code/ svn-to-git-code

The SVN repo in HEAD revision contains three externals:

$ cd svn-to-git-code
$ git svn show-externals

# /trunk/
/trunk/https://svn.code.sf.net/p/gc-webdav/svn webdav
/trunk/https://svn.code.sf.net/p/gc-webdav/svn@1 webdav-at-revision

# /trunk/sub directory/
/trunk/sub directory/https://svn.code.sf.net/p/gc-webdav/svn 'webdav in subdir'

An earlier version contains just one external:

$ git svn show-externals --revision 8

# /trunk/
/trunk/webdav https://svn.code.sf.net/p/gc-webdav/svn/

It seems like the output is inconsistent. In SVN revision 8 the output
looks like it's formatted like
 

In the HEAD revision it looks mangled
 

This makes consuming the output of git svn show-externals in HEAD
difficult because the parts are not clearly separated by space and
sometimes the path is the first element, sometimes it's a combination
of first and last elements.

I am able to checkout both revisions including externals using native svn.

Am I doing something wrong?

Thanks!


Alex
-- 
Alexander Groß
http://therightstuff.de/

[PATCH] commit: remove unused inline function single_parent()

[René Scharfe]

53b2c823f6 (revision walker: mini clean-up) added the function in 2007,
but it was never used, so we should be able to get rid of it now.

Signed-off-by: Rene Scharfe 
---
 commit.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/commit.h b/commit.h
index 6d857f06c1..1283d2a51f 100644
--- a/commit.h
+++ b/commit.h
@@ -313,11 +313,6 @@ extern int interactive_add(int argc, const char **argv, 
const char *prefix, int
 extern int run_add_interactive(const char *revision, const char *patch_mode,
   const struct pathspec *pathspec);
 
-static inline int single_parent(struct commit *commit)
-{
-   return commit->parents && !commit->parents->next;
-}
-
 struct commit_list *reduce_heads(struct commit_list *heads);
 
 struct commit_extra_header {
-- 
2.14.1

Re: [PATCH v3 00/23] Move exported packfile funcs to its own file

[Junio C Hamano]

Jonathan Tan  writes:

>> You'd need to double check, but I think the topics that cause
>> trouble are rs/find-apck-entry-bisection and jk/drop-sha1-entry-pos;
>> you can start from v2.14.1 and merge these topics on top and then
>> build your change on top.  That would allow you to start cooking
>> before both of them graduate to 'master', as I expect they are both
>> quick-to-next material.  There might be other topics that interfere
>> with what you are doing, but you can easily find out what they are
>> if you do a trial merge to 'next' and 'pu' yourself.
>
> OK - in addition to the 2 you mentioned, I have found some others
> (likely added after you wrote that). The complete list is:
>  - rs/find-pack-entry-bisection
>  - jk/drop-sha1-entry-pos
>  - jt/sha1-file-cleanup (formerly part of this set)
>  - mk/use-size-t-in-zlib
>  - rs/unpack-entry-leakfix
>
> I have merged all of these and rebased my patches on top.
>
> Other changes:
>  - Used packfile.h instead of pack.h (following most people's
>preference)
>  - Ensured that I added functions to packfile.h retaining the order they
>were originally in, so that if you run "git diff  --color-moved
>--patience", there are much fewer zebra stripes
>
> The merge base commit can be accessed online [1], if you need it.
>
> [1] https://github.com/jonathantanmy/git/commits/packmigrate

Thanks.

I have to say that this was a painful topic to integrate.

As you may know, the mk/use-size-t-in-zlib topic is being retracted
and getting rerolled as a larger size_t series, most of which still
needs help in reviewing.

The jt/sha1-file-cleanup topic is the only one among the other four
that are still not in 'next', and I think that topic, as well as the
other three, are all good and serve as a good base to build on top.
So I first rebuilt your patches on top of these four topics.  This
took some time but it wasn't all that painful.

The result cleanly merged to 'pu', I think, but it resulted in a
rather noisy conflict when I attempted to merge it to 'next'.  I
want to see both of a merge to 'next' and a merge to 'pu' to be
reasonably clean for any topic to be viable [*1*].  Otherwise,
"initially queue in 'pu', then cook in 'next', and eventually
graduate to 'master'" workflow would not work well.

Anyway, I _think_ I finally got the conflict resolutions right for
merges of the topic to 'next', 'jch' and 'pu', so I will push the
result of merging to 'pu' out.  This unfortunately makes Martin's
ongoing size_t topic unmergeable to any of the integration branches
as-is, but let's make sure that topic is reviewed properly first (I
haven't seen people comment much on the individual patches other
than just selected few).


[Footnote]

*1* There is an intermediate point between 'master' and 'pu' called
'jch', and I try to make sure any new topic to merge cleanly to
that branch, too, when accepting it.  That is the branch I use
for everyday work as an early guinea-pig.

Re: Submodule regression in 2.14?

[Junio C Hamano]

Stefan Beller  writes:

> Jonathan brought up the following very long term vision:
> Eventually the everyday git commands do not treat submodules
> any special than trees, even the submodules git directory
> may be non existent (everything is absorbed into the superproject);
> so it really feels like a monorepo.

That may be one valid option to have but I do not see a reason why
it needs to be the only valid option.  So I do not see why you are
bringing it up in this thread.

But that is a good starting point to discuss one possible future.
Let's think aloud how that world would look like.

 * When you "git clone" a superproject (perhaps implicitly with the
   "--recurse-submodules" option), the top-level project and all of
   its submodules will be checked out on the same branch (presumably
   the 'master' branch, which is the default).

 * Your attempt to "git commit", "git branch", "git checkout -b",
   etc. inside a submodule will either fail, or will implicitly
   chdir up to the top-level superproject and turn into the
   corresponding command with "--recurse-submodules".

 * "git commit --recurse-submodules -a" from the top-level will grab
   all the local changes, depth-first and recursively, in
   submodules, makes a commit, binds the new commit to the index of
   the superproject that immediately contains the submodule and
   makes a commit in it, until it percolates all the way up to the
   superproject.  When working in this mode, branches in submodules
   do not really matter; the gitlink in the superproject is the only
   thing that matters.

 * It naturally follows that between two adjacent commits C and C~1
   in the superproject's history, the commit in a submodule bound to
   C and the commit in a submodule bound to C~1 are either the same
   (i.e. superproject made a commit but there was no change in the
   submodule), or they are in direct parent-child relationship
   (i.e. the local changes made to the submodule was recorded as a
   single commit when the superproject made the commit).

 * "git push --recurse-submodules" from the top-level will push the
   history of the superproject out, together with the history of the
   submodules.

I think it is doable, but a mechanism to enumerate all the commits
bound from submodules to a range of superproject's commits needs to
be invented to drive the pack-objects for efficient object transfer.
Having it would also help in fsck and gc---as branches are immaterial
in the submodule repositories, commits in superprojects that are
reachable from refs will have to serve as the connectivity anchors
for commit DAG in the submodule histories.

As long as we are talking about idealized future world (well, at
least an idea of somebody's "ideal", not necessarily shared by
everybody), I wonder if there is even any need to have commits in
submodules in such a world.  To realize such a "monorepo" world, you
might be better off allowing a gitlink in the superproject to
directly point at a tree object in a submodule repository (making
them physically a single repository is an optional implementation
detail I choose to ignore in this discussion).

Re: [PATCH] pull: respect submodule update configuration

[Junio C Hamano]

Stefan Beller  writes:

> From: Lars Schneider 
>
> Do not override the submodule configuration in the call to update
> the submodules, but give a weaker default.
>
> Reported-by: Lars Schneider 
> Signed-off-by: Stefan Beller 
> ---
>   
> Personally I dislike this patch, but I have no better idea for the time
> being.

The patch text from a cursory look seems reasonable to me.

It's not like you have 47 different codepaths that need to pay
attention to the .update config and they all have to pass the new
--default-update option, this is merely to fix one of them that
relates to the problem reported by Lars, and you need a similar fix
to other 46, right?

If you want the "--recurse-submodules" thing to always do the
"weaker default" thing in your project, you can choose not to set
.update to custom values in any of your submodules, so I do not
think the reason why you dislike this change is because it would
affect your use of submodules.

So I am a bit curious to learn which part of this change you dislike
and why.


>  builtin/pull.c |  6 --
>  git-submodule.sh   |  7 ++-
>  t/t7400-submodule-basic.sh | 22 ++
>  3 files changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/pull.c b/builtin/pull.c
> index 9b86e519b1..be4f74d764 100644
> --- a/builtin/pull.c
> +++ b/builtin/pull.c
> @@ -553,7 +553,8 @@ static int rebase_submodules(void)
>   cp.git_cmd = 1;
>   cp.no_stdin = 1;
>   argv_array_pushl(, "submodule", "update",
> -"--recursive", "--rebase", NULL);
> +"--recursive", "--default-update",
> +"rebase", NULL);
>  
>   return run_command();
>  }
> @@ -565,7 +566,8 @@ static int update_submodules(void)
>   cp.git_cmd = 1;
>   cp.no_stdin = 1;
>   argv_array_pushl(, "submodule", "update",
> -"--recursive", "--checkout", NULL);
> +"--recursive", "--default-update",
> +"checkout", NULL);
>  
>   return run_command();
>  }
> diff --git a/git-submodule.sh b/git-submodule.sh
> index e131760eec..6dbc32e686 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -511,6 +511,7 @@ fetch_in_submodule () (
>  cmd_update()
>  {
>   # parse $args after "submodule ... update".
> + default_update="checkout"
>   while test $# -ne 0
>   do
>   case "$1" in
> @@ -552,6 +553,10 @@ cmd_update()
>   --checkout)
>   update="checkout"
>   ;;
> + --default-update)
> + default_update="$2"
> + shift
> + ;;
>   --recommend-shallow)
>   recommend_shallow="--recommend-shallow"
>   ;;
> @@ -619,7 +624,7 @@ cmd_update()
>   update_module=$(git config submodule."$name".update)
>   if test -z "$update_module"
>   then
> - update_module="checkout"
> + update_module="$default_update"
>   fi
>   fi
>  
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index dcac364c5f..ff64bf8528 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -1289,4 +1289,26 @@ test_expect_success 'init properly sets the config' '
>   test_must_fail git -C multisuper_clone config --get 
> submodule.sub1.active
>  '
>  
> +test_expect_success 'submodule update and git pull with disabled submodule' '
> + test_when_finished "rm -rf multisuper_clone" &&
> + pwd=$(pwd) &&
> + cat <<-\EOF >expect &&
> + -sub0
> +  sub1 (test2)
> +  sub2 (test2)
> +  sub3 (test2)
> +  sub4 (test2)
> +  sub5 (test2)
> + EOF
> + git clone file://"$pwd"/multisuper multisuper_clone &&
> + (
> + cd multisuper_clone &&
> + git config --local submodule.sub0.update none &&
> + git submodule update --init --recursive &&
> + git pull --recurse-submodules &&
> + git submodule status | cut -c 1,43- >actual
> + ) &&
> + test_cmp expect multisuper_clone/actual
> +'
> +
>  test_done

Re: [PATCH] pull: respect submodule update configuration

[Junio C Hamano]

Stefan Beller  writes:

> On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller  wrote:
>> From: Lars Schneider 
>
> eh, that is what I get for amending to Lars patch.

Sorry, I do not understand this remark.  

If you started from a patch by Lars (I do not recall seeing it but
the list is high volume so it is entirely plausible that I may have
missed it) and tweaked it, it is more than OK to keep the original
author and record it in an in-body From: header like you did,
instead of taking authorship over.