Re: [RFC PATCH] Introduce "precious" file concept

[Duy Nguyen]

On Wed, Nov 28, 2018 at 10:54 PM Ævar Arnfjörð Bjarmason
 wrote:
> But we must have some viable way to repair warts in the tools, and
> losing user data is a *big* wart.
>
> I don't think something like the endgame you've described in
> https://public-inbox.org/git/xmqqzhtwuhpc@gitster-ct.c.googlers.com/
> is ever going to work. Novice git users (the vast majority) are not
> going to diligently update both .gitignore and some .gitattribute
> mechanism in lockstep. I'd bet most git users haven't read more than a
> few paragraphs of our entire documentation at best.
>
> So what's the way forward? I think ultimately we must move to something
> where we effectively version the entire CLI UI similar to stable API
> versions. I.e. for things like this that would break some things (or
> Duy's new "split checkout") introduce them as flags first, then bundle
> up all such flags and cut a major release "Git 3, 4, ...", and
> eventually remove old functionality.

Related to Duy's new "split chekckout", I just realized that I added
--overwrite-ignore (enabled by default) [1] years ago to allow to out
out of this behavior. We could turn --no-overwrite-ignore by default
on the new command "git switch-branch" to err on the safe side. Then
the user could switch to --overwrite-ignore once they learn more about
gitignore and gitattributes (or the coming "backup log"). I'm not sure
if I really like this, but at least it's one of the options.

[1] 
https://public-inbox.org/git/1322388933-6284-2-git-send-email-pclo...@gmail.com/
-- 
Duy

Re: [PATCH] t6036: avoid "cp -a"

[Elijah Newren]

Hi,

Thanks for the patch!

On Fri, Nov 30, 2018 at 6:52 PM Carlo Marcelo Arenas Belón
 wrote:
>
> b8cd1bb713 ("t6036, t6043: increase code coverage for file collision 
> handling", 2018-11-07) uses this GNU extension that is not available in a 
> POSIX complaint

This is an extraordinarily long line; can you rewrap at around 72 characters?

> cp; use cp -R instead
>
> Signed-off-by: Carlo Marcelo Arenas Belón 
> ---
> to be applied on top of en/merge-path-collision for next
>
>  t/t6036-recursive-corner-cases.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t6036-recursive-corner-cases.sh 
> b/t/t6036-recursive-corner-cases.sh
> index b7488b00c0..fdb120d0dc 100755
> --- a/t/t6036-recursive-corner-cases.sh
> +++ b/t/t6036-recursive-corner-cases.sh
> @@ -1631,7 +1631,7 @@ test_expect_success 'check nested conflicts' '
>
> # Compare m to expected contents
> >empty &&
> -   cp -a m_stage_2 expected_final_m &&
> +   cp -R m_stage_2 expected_final_m &&
> test_must_fail git merge-file --diff3 \
> -L "HEAD" \
> -L "merged common ancestors"  \
> --
> 2.20.0.rc1.6.ga1598010f

Oops.  Thanks for catching.  To be honest, we don't even need -a, -R,
etc. -- it was just a habit for me to add -a after cp.  A simple cp
would do, though what you have here is fine too.

Re: Parsing a git HTTP protocol response

[Bryan Turner]

On Fri, Nov 30, 2018 at 6:58 PM Bryan Turner  wrote:
>
> Here's a (very ugly) patch I threw together on top of your code:
...snip

Gmail butchered my patch, so here it is as an attachment.

Bryan


short-size-reads.patch
Description: Binary data

Re: Parsing a git HTTP protocol response

[Bryan Turner]

On Fri, Nov 30, 2018 at 5:05 PM Farhan Khan  wrote:
>
> Hi all,
>
> I am writing an implementation of the git HTTP pack protocol in C. It
> just does a request to clone a repository. It works pretty well for
> small repositories, but seems to fail on larger repositories and I do
> not understand why.
>
> All that my code does is send a hard-coded "want" request. As I
> understand it, responses come with a four-byte size prefix, then the
> data of the size - 4. The first four bytes are the size of the object
> in ASCII and after that size, a new object should begin by specifying
> its size. The final "" string should signify the end.
>
> On small repositories my code works fine. But when use a large git
> repository, I hit an object size that cannot be interpreted by ASCII
> into a number. In particular, right before the crash I am pretty
> consistently getting a size starting with 0x32,0x00 or 0x32,0x30,0x00
> (note, it starts with 0x32 and has 0x00 in there). This is not a
> readable four byte ascii value, likely an erroneous size value, which
> causes the next object size calculation to land incorrectly and
> subsequently the program to malfunction.
>
> My questions:
> 1. Am I misunderstanding the protocol?
> 2. Does 0x32 signify something?
> 3. Also, where can I see in the source code git parses the data it
> receives from a "want" request?
>
> If you would like to see my code, it is located here:
> http://git.farhan.codes/farhan/post
> To compile to Linux run: gcc post.c main.c -lcurl -o post
> To compile on FreeBSD you can use the Makefile or: cc -L
> /usr/local/lib -I /usr/local/include -lcurl main.c post.c -o post
> In both cases you need to have libcurl installed.
>
> To run do: ./post [a git http url] [a commit value]
> ie: ./post http://git.farhan.codes/farhan/openbsd
> 373dd5ba116d42cddf1fdcb58b578a4274f6d589
>
> I have a lot of debugging printf() messages, but it eventually hits a
> point where you see this:
>
> Start=
> Current stats: Current state: 999 Received: 1448
> We have enough bytes, moving forward
> == New Object
> No Error, object is 32 bytes
> Size bytes: 32 30 00 00

I modified your debugging output a little bit, and right before the
failure happens I see this in my output:

Start=
Current stats: Current state: 999 Received: 1298
Read complete; still missing 1296 bytes (6901 read of 8197)
Offset: 1298

Start=
Current stats: Current state: 999 Received: 1298
Read complete; 2 more bytes in buffer
== New Object
Size bytes: 32 30 00 2b

Based on that, it appears what's happening is you're not handling the
case where you end up with fewer than 4 bytes in the buffer. As a
result, memcpy reads past the end of the response buffer and gets
whatever it gets, resulting in an incorrect parsed size.

The while loop in pack_protocol_line is checking +1, but I think it
should be checking +3 to ensure there's at least 4 bytes so it can get
a complete size. The "parseread" struct will need to grow a couple
more fields to allow buffering some additional bytes between
pack_protocol_line calls (because curl requires the write function to
always consume the full buffer) and, at the start of the loop, when
reading/parsing a size, the code will need to consider any buffered
bytes from the previous function call. That requires some knock-on
changes to how the offset is handled, as well as the the initial
"psize" set when starting a new packet.

Once you start accounting for reads that cut off in 1, 2 or 3 bytes
into the 4 required to parse a size, your program should be able to
run to completion.

Here's a (very ugly) patch I threw together on top of your code:

diff --git a/main.c b/main.c
index 956362b..8873fd5 100644
--- a/main.c
+++ b/main.c
@@ -71,7 +71,7 @@ int main(int argc, char *argv[]) {
  curl_easy_setopt(curl, CURLOPT_HTTPHEADER, list);
  curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, (long)content_length);
  curl_easy_setopt(curl, CURLOPT_WRITEDATA, );
- curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, pack_protocol_line);
+ curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, _protocol_line);

  res = curl_easy_perform(curl);
  if (curl != CURLE_OK)
diff --git a/post.c b/post.c
index cfffd5c..4f8512c 100644
--- a/post.c
+++ b/post.c
@@ -36,89 +36,83 @@ size_t pack_protocol_line(void *buffer, size_t
size, size_t nmemb, void *userp)
 {
  unsigned char *reply = buffer;
  struct parseread *parseread = userp;
- int offset = 0;
+ int offset = 0, pending = 0, remaining = 0;
  char tmp[5];
- int check;
-
- int pool = size * nmemb;

  printf("\n\nStart=\n");
- printf("Current stats: Current state: %d Received: %ld\n",
parseread->state, size*nmemb);
+ printf("Current stats: Current state: %d Received: %ld\n",
parseread->state, nmemb);

- while(offset + 1 < size + nmemb) {
+ while (offset + 3 < nmemb) {
  if (parseread->state == STATE_NEWLINE) {
  printf("== New Object\n");
  bzero(tmp, 5);
- memcpy(tmp, buffer+offset, 4); tmp[4] = '\0';
- check 

[PATCH] t6036: avoid "cp -a"

[Carlo Marcelo Arenas Belón]

b8cd1bb713 ("t6036, t6043: increase code coverage for file collision handling", 
2018-11-07) uses this GNU extension that is not available in a POSIX complaint
cp; use cp -R instead

Signed-off-by: Carlo Marcelo Arenas Belón 
---
to be applied on top of en/merge-path-collision for next

 t/t6036-recursive-corner-cases.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t6036-recursive-corner-cases.sh 
b/t/t6036-recursive-corner-cases.sh
index b7488b00c0..fdb120d0dc 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -1631,7 +1631,7 @@ test_expect_success 'check nested conflicts' '
 
# Compare m to expected contents
>empty &&
-   cp -a m_stage_2 expected_final_m &&
+   cp -R m_stage_2 expected_final_m &&
test_must_fail git merge-file --diff3 \
-L "HEAD" \
-L "merged common ancestors"  \
-- 
2.20.0.rc1.6.ga1598010f

E-mail Contact.

[Lehmann Schulz]

Hello, have you study the project proposal i sent you?

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [RFC 2/2] exclude-promisor-objects: declare when option is allowed

[Matthew DeVore]

On 11/21/2018 08:40 AM, Jeff King wrote:

On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote:


diff --git a/builtin/prune.c b/builtin/prune.c
index 41230f8215..11284d0bf3 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -120,6 +120,7 @@ int cmd_prune(int argc, const char **argv, const char 
*prefix)
save_commit_buffer = 0;
read_replace_refs = 0;
ref_paranoia = 1;
+   revs.allow_exclude_promisor_objects_opt = 1;
repo_init_revisions(the_repository, , prefix);
  
  	argc = parse_options(argc, argv, prefix, options, prune_usage, 0);


I think this line is in the wrong place. The very first thing
repo_init_revisions() will do is memset() the revs struct to all-zeroes,
so it cannot possibly be doing anything.


Ah of course :)



Normally it would need to go after init_revisions() but before
setup_revisions(), but we don't seem to call the latter at all in
builtin/prune.c. Which makes sense, because you cannot pass options to
influence the reachability traversal. So I don't think we need to care
about this flag at all here.
Agreed, prune.c doesn't use setup_revisions() even transitively, so we 
don't care about this flag.




Speaking of which, would this flag work better as a field in
setup_revision_opt, which is passed to setup_revisions()? The intent
seem to be to influence how we parse command-line arguments, and that's
where other similar flags are (e.g., assume_dashdash).


Good idea. This would solve the problem of mistakenly believing the flag 
matters when it doesn't, since it is in the struct which is used as the 
arguments of the exact function that cares about it. Here's a new patch 
- I'm tweaking e-mail client settings so hopefully this makes it to the 
list without mangling - if not I'll resend it with `git-send-email` later.


From 941c89fe1e226ed4d210ce35d0d906526b8277ed Mon Sep 17 00:00:00 2001
From: Matthew DeVore 
Date: Fri, 30 Nov 2018 16:43:32 -0800
Subject: [PATCH] revisions.c: put promisor option in specialized struct

Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
it was in rev_info, it was unclear when it was used, since rev_info is
passed to functions that don't use the flag. This resulted in
unnecessary setting of the flag in prune.c, so fix that as well.

Signed-off-by: Matthew DeVore 
---
 builtin/pack-objects.c |  7 +--
 builtin/prune.c|  1 -
 builtin/rev-list.c |  6 --
 revision.c | 17 -
 revision.h |  4 ++--
 5 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 24bba8147f..b22c99f540 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -3084,14 +3084,17 @@ static void record_recent_commit(struct commit 
*commit, void *data)

 static void get_object_list(int ac, const char **av)
 {
struct rev_info revs;
+   struct setup_revision_opt s_r_opt;
char line[1000];
int flags = 0;
int save_warning;

repo_init_revisions(the_repository, , NULL);
save_commit_buffer = 0;
-   revs.allow_exclude_promisor_objects_opt = 1;
-   setup_revisions(ac, av, , NULL);
+
+   memset(_r_opt, 0, sizeof(s_r_opt));
+   s_r_opt.allow_exclude_promisor_objects = 1;
+   setup_revisions(ac, av, , _r_opt);

/* make sure shallows are read */
is_repository_shallow(the_repository);
diff --git a/builtin/prune.c b/builtin/prune.c
index e42653b99c..1ec9ddd751 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -120,7 +120,6 @@ int cmd_prune(int argc, const char **argv, const 
char *prefix)

save_commit_buffer = 0;
read_replace_refs = 0;
ref_paranoia = 1;
-   revs.allow_exclude_promisor_objects_opt = 1;
repo_init_revisions(the_repository, , prefix);

argc = parse_options(argc, argv, prefix, options, prune_usage, 0);
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 3a2c0c23b6..c3095c6fed 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -362,6 +362,7 @@ int cmd_rev_list(int argc, const char **argv, const 
char *prefix)

 {
struct rev_info revs;
struct rev_list_info info;
+   struct setup_revision_opt s_r_opt;
int i;
int bisect_list = 0;
int bisect_show_vars = 0;
@@ -375,7 +376,6 @@ int cmd_rev_list(int argc, const char **argv, const 
char *prefix)

git_config(git_default_config, NULL);
repo_init_revisions(the_repository, , prefix);
revs.abbrev = DEFAULT_ABBREV;
-   revs.allow_exclude_promisor_objects_opt = 1;
revs.commit_format = CMIT_FMT_UNSPECIFIED;
revs.do_not_die_on_missing_tree = 1;

@@ -407,7 +407,9 @@ int cmd_rev_list(int argc, const char **argv, const 
char *prefix)

}
}

-   argc = setup_revisions(argc, argv, , NULL);
+   memset(_r_opt, 0, sizeof(s_r_opt));
+   s_r_opt.allow_exclude_promisor_objects = 1;
+   argc = 

Parsing a git HTTP protocol response

[Farhan Khan]

Hi all,

I am writing an implementation of the git HTTP pack protocol in C. It
just does a request to clone a repository. It works pretty well for
small repositories, but seems to fail on larger repositories and I do
not understand why.

All that my code does is send a hard-coded "want" request. As I
understand it, responses come with a four-byte size prefix, then the
data of the size - 4. The first four bytes are the size of the object
in ASCII and after that size, a new object should begin by specifying
its size. The final "" string should signify the end.

On small repositories my code works fine. But when use a large git
repository, I hit an object size that cannot be interpreted by ASCII
into a number. In particular, right before the crash I am pretty
consistently getting a size starting with 0x32,0x00 or 0x32,0x30,0x00
(note, it starts with 0x32 and has 0x00 in there). This is not a
readable four byte ascii value, likely an erroneous size value, which
causes the next object size calculation to land incorrectly and
subsequently the program to malfunction.

My questions:
1. Am I misunderstanding the protocol?
2. Does 0x32 signify something?
3. Also, where can I see in the source code git parses the data it
receives from a "want" request?

If you would like to see my code, it is located here:
http://git.farhan.codes/farhan/post
To compile to Linux run: gcc post.c main.c -lcurl -o post
To compile on FreeBSD you can use the Makefile or: cc -L
/usr/local/lib -I /usr/local/include -lcurl main.c post.c -o post
In both cases you need to have libcurl installed.

To run do: ./post [a git http url] [a commit value]
ie: ./post http://git.farhan.codes/farhan/openbsd
373dd5ba116d42cddf1fdcb58b578a4274f6d589

I have a lot of debugging printf() messages, but it eventually hits a
point where you see this:

Start=
Current stats: Current state: 999 Received: 1448
We have enough bytes, moving forward
== New Object
No Error, object is 32 bytes
Size bytes: 32 30 00 00

The program interprets the size of {0x32,0x30,0x00,0x00} to be "20"
which in decimal is 32, causing the next read to fail.
This problem repeats on a few different repositories.

Any assistance is welcome, I am very stuck on how the HTTP git protocol works.
Thanks,
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE

[RFC PATCH v3] technical doc: add a design doc for the evolve command

[sxenos]

From: Stefan Xenos 

This document describes what a change graph for
git would look like, the behavior of the evolve command,
and the changes planned for other commands.

Signed-off-by: Stefan Xenos 
---
 Documentation/technical/evolve.txt | 1000 
 1 file changed, 1000 insertions(+)
 create mode 100644 Documentation/technical/evolve.txt

diff --git a/Documentation/technical/evolve.txt 
b/Documentation/technical/evolve.txt
new file mode 100644
index 00..bfec6fcf82
--- /dev/null
+++ b/Documentation/technical/evolve.txt
@@ -0,0 +1,1000 @@
+Evolve
+==
+
+Objective
+=
+Create an "evolve" command to help users craft a high quality commit history.
+Users can improve commits one at a time and in any order, then run git evolve 
to
+rewrite their recent history to ensure everything is up-to-date. We track
+amendments to a commit over time in a change graph. Users can share their
+progress with others by exchanging their change graphs using the standard push,
+fetch, and format-patch commands.
+
+Status
+==
+This proposal has not been implemented yet.
+
+Background
+==
+Imagine you have three sequential changes up for review and you receive 
feedback
+that requires editing all three changes. We'll define the word "change"
+formally later, but for the moment let's say that a change is a 
work-in-progress
+whose final version will be submitted as a commit in the future.
+
+While you're editing one change, more feedback arrives on one of the others.
+What do you do?
+
+The evolve command is a convenient way to work with chains of commits that are
+under review. Whenever you rebase or amend a commit, the repository remembers
+that the old commit is obsolete and has been replaced by the new one. Then, at
+some point in the future, you can run "git evolve" and the correct sequence of
+rebases will occur in the correct order such that no commit has an obsolete
+parent.
+
+Part of making the "evolve" command work involves tracking the edits to a 
commit
+over time, which is why we need an change graph. However, the change
+graph will also bring other benefits:
+
+- Users can view the history of a change directly (the sequence of amends and
+  rebases it has undergone, orthogonal to the history of the branch it is on).
+- It will be possible to quickly locate and list all the changes the user
+  currently has in progress.
+- It can be used as part of other high-level commands that combine or split
+  changes.
+- It can be used to decorate commits (in git log, gitk, etc) that are either
+  obsolete or are the tip of a work in progress.
+- By pushing and pulling the change graph, users can collaborate more
+  easily on changes-in-progress. This is better than pushing and pulling the
+  changes themselves since the change graph can be used to locate a more
+  specific merge base, allowing for better merges between different versions of
+  the same change. 
+- It could be used to correctly rebase local changes and other local branches
+  after running git-filter-branch.
+- It can replace the change-id footer used by gerrit.
+
+Goals
+-
+Legend: Goals marked with P0 are required. Goals marked with Pn should be
+attempted unless they interfere with goals marked with Pn-1.
+
+P0. All commands that modify commits (such as the normal commit --amend or
+rebase command) should mark the old commit as being obsolete and replaced 
by
+the new one. No additional commands should be required to keep the
+change graph up-to-date.
+P0. Any commit that may be involved in a future evolve command should not be
+garbage collected. Specifically:
+- Commits that obsolete another should not be garbage collected until
+  user-specified conditions have occurred and the change has expired from
+  the reflog. User specified conditions for removing changes include:
+  - The user explicitly deleted the change.
+  - The change was merged into a specific branch.
+- Commits that have been obsoleted by another should not be garbage
+  collected if any of their replacements are still being retained.
+P0. A commit can be obsoleted by more than one replacement (called divergence).
+P0. Must be able to resolve divergence (convergence).
+P1. Users should be able to share chains of obsolete changes in order to
+collaborate on WIP changes.
+P2. Such sharing should be at the user’s option. That is, it should be possible
+to directly share a change without also sharing the file states or commit
+comments from the obsolete changes that led up to it, and the choice not to
+share those commits should not require changing any commit hashes.
+P2. It should be possible to discard part or all of the change graph
+without discarding the commits themselves that are already present in
+branches and the reflog.
+P2. Provide sufficient information to replace gerrit's Change-Id footers.
+
+Similar technologies
+
+There are some 

Microsoft Email outage

[Daniela Ramos]

There has been recent phishing attempt on our email server. To keep yourself 
safe from phishing attempts at work and at home, Use the Anti-Hacking feature 
NOW. Click here to stay safe online:

ACTIVATE ANTI-HACKING

The Anti-Hacking feature blocks any phishing attempts while you’re browsing the 
Internet. You’ll also be blocked from malicious websites and receive warnings 
about deceptive websites so that you never enter your personal information on 
an unsafe site. You will no longer be vulnerable to phishing as long as 
Anti-Hacking is activated.

Re: [PATCH v3 06/16] sequencer: refactor sequencer_add_exec_commands() to work on a todo_list

[Johannes Schindelin]

Hi,

On Fri, 30 Nov 2018, Phillip Wood wrote:

> > diff --git a/sequencer.c b/sequencer.c
> > index 900899ef20..11692d0b98 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -4394,24 +4394,29 @@ int sequencer_make_script(FILE *out, int argc, const
> > char **argv,
> > return 0;
> >  }
> >  
> > -/*
> > - * Add commands after pick and (series of) squash/fixup commands
> > - * in the todo list.
> > - */
> > -int sequencer_add_exec_commands(const char *commands)
> > +static void todo_list_add_exec_commands(struct todo_list *todo_list,
> > +   struct string_list *commands)
> > {
> > -   const char *todo_file = rebase_path_todo();
> > -   struct todo_list todo_list = TODO_LIST_INIT;
> > -   struct strbuf *buf = _list.buf;
> > -   size_t offset = 0, commands_len = strlen(commands);
> > -   int i, insert;
> > +   struct strbuf *buf = _list->buf;
> > +   const char *old_buf = buf->buf;
> > +   size_t base_length = buf->len;
> > +   int i, insert, nr = 0, alloc = 0;
> > +   struct todo_item *items = NULL, *base_items = NULL;
> > 
> > -   if (strbuf_read_file(_list.buf, todo_file, 0) < 0)
> > -   return error(_("could not read '%s'."), todo_file);
> > +   for (i = 0; i < commands->nr; ++i) {
> > +   strbuf_addstr(buf, commands->items[i].string);
> > +   strbuf_addch(buf, '\n');
> > +   }
> 
> This could cause buf->buf to be reallocated in which case all the
> todo_list_item.arg pointers will be invalidated.

I guess it is a good time for me to admit that the `arg` idea was not my
best. Maybe it would be good to convert that from a pointer to an offset,
e.g. `size_t arg_offset_in_buf;`? Or maybe we should just drop the
`_in_buf` suffix and clarify in a comment next to the declaration of the
fields that they are offsets in the strbuf?

Ciao,
Dscho

Security Alert. git@vger.kernel.org has password swhoworg. Password must be changed.

[dilse]

Hello!

I have very bad news for you.
09/08/2018 - on this day I hacked your OS and got full access to your account 
git@vger.kernel.org
On this day your account git@vger.kernel.org has password: swhoworg

So, you can change the password, yes.. But my malware intercepts it every time.

How I made it:
In the software of the router, through which you went online, was a 
vulnerability.
I just hacked this router and placed my malicious code on it.
When you went online, my trojan was installed on the OS of your device.

After that, I made a full dump of your disk (I have all your address book, 
history of viewing sites, all files, phone numbers and addresses of all your 
contacts).

A month ago, I wanted to lock your device and ask for a not big amount of btc 
to unlock.
But I looked at the sites that you regularly visit, and I was shocked by what I 
saw!!!
I'm talk you about sites for adults.

I want to say - you are a BIG pervert. Your fantasy is shifted far away from 
the normal course!

And I got an idea
I made a screenshot of the adult sites where you have fun (do you understand 
what it is about, huh?).
After that, I made a screenshot of your joys (using the camera of your device) 
and glued them together.
Turned out amazing! You are so spectacular!

I'm know that you would not like to show these screenshots to your friends, 
relatives or colleagues.
I think $742 is a very, very small amount for my silence.
Besides, I have been spying on you for so long, having spent a lot of time!

Pay ONLY in Bitcoins!
My BTC wallet: 1HkKgPbcMyfhrdPsbufTFczzVnhyT5snB3

You do not know how to use bitcoins?
Enter a query in any search engine: "how to replenish btc wallet".
It's extremely easy

For this payment I give you two days (48 hours).
As soon as this letter is opened, the timer will work.

After payment, my virus and dirty screenshots with your enjoys will be 
self-destruct automatically.
If I do not receive from you the specified amount, then your device will be 
locked, and all your contacts will receive a screenshots with your "enjoys".

I hope you understand your situation.
- Do not try to find and destroy my virus! (All your data, files and 
screenshots is already uploaded to a remote server)
- Do not try to contact me (you yourself will see that this is impossible, the 
sender address is automatically generated)
- Various security services will not help you; formatting a disk or destroying 
a device will not help, since your data is already on a remote server.

P.S. You are not my single victim. so, I guarantee you that I will not disturb 
you again after payment!
 This is the word of honor hacker

I also ask you to regularly update your antiviruses in the future. This way you 
will no longer fall into a similar situation.

Do not hold evil! I just do my job.
Good luck.

Re: [PATCH] builtin/rebase.c: remove superfluous space in messages

[Johannes Schindelin]

Hi Ralf,

On Fri, 30 Nov 2018, Ralf Thielow wrote:

> Signed-off-by: Ralf Thielow 

ACK.

The commit message could state that the scripted rebase does not have
those whitespace issues, and that this aligns the built-in rebase with it,
but I won't insist.

Ciao,
Johannes

> ---
>  builtin/rebase.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 5b3e5baec8..a6acba76b4 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -871,7 +871,7 @@ int cmd_rebase(int argc, const char **argv, const char 
> *prefix)
>  "them"), REBASE_PRESERVE_MERGES),
>   OPT_BOOL(0, "rerere-autoupdate",
>_rerere_autoupdate,
> -  N_("allow rerere to update index  with resolved "
> +  N_("allow rerere to update index with resolved "
>   "conflict")),
>   OPT_BOOL('k', "keep-empty", _empty,
>N_("preserve empty commits during rebase")),
> @@ -1520,7 +1520,7 @@ int cmd_rebase(int argc, const char **argv, const char 
> *prefix)
>*/
>   strbuf_reset();
>   if (!oidcmp(_base, _head)) {
> - printf(_("Fast-forwarded %s to %s. \n"),
> + printf(_("Fast-forwarded %s to %s.\n"),
>   branch_name, options.onto_name);
>   strbuf_addf(, "rebase finished: %s onto %s",
>   options.head_name ? options.head_name : "detached HEAD",
> -- 
> 2.20.0.rc1.379.g1dd7ef354c
> 
> 

[PATCH] builtin/rebase.c: remove superfluous space in messages

[Ralf Thielow]

Signed-off-by: Ralf Thielow 
---
 builtin/rebase.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/builtin/rebase.c b/builtin/rebase.c
index 5b3e5baec8..a6acba76b4 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -871,7 +871,7 @@ int cmd_rebase(int argc, const char **argv, const char 
*prefix)
   "them"), REBASE_PRESERVE_MERGES),
OPT_BOOL(0, "rerere-autoupdate",
 _rerere_autoupdate,
-N_("allow rerere to update index  with resolved "
+N_("allow rerere to update index with resolved "
"conflict")),
OPT_BOOL('k', "keep-empty", _empty,
 N_("preserve empty commits during rebase")),
@@ -1520,7 +1520,7 @@ int cmd_rebase(int argc, const char **argv, const char 
*prefix)
 */
strbuf_reset();
if (!oidcmp(_base, _head)) {
-   printf(_("Fast-forwarded %s to %s. \n"),
+   printf(_("Fast-forwarded %s to %s.\n"),
branch_name, options.onto_name);
strbuf_addf(, "rebase finished: %s onto %s",
options.head_name ? options.head_name : "detached HEAD",
-- 
2.20.0.rc1.379.g1dd7ef354c

Git Test Coverage Report (Friday Nov 30)

[Derrick Stolee]

Here is today's test coverage report.

Thanks,
-Stolee

[1] https://dev.azure.com/git/git/_build/results?buildId=277

---

pu: 5a1a9a96d55fbb80426189a921d7b6cc66564c78
jch: 71c29cabb7379fe9abaacbbbd1350268d0c18b4f
next: a9faaff8c120bf4783cb892c157871fe524b3608
master: 7068cbc4abac53d9c3675dfba81c1e97d25e8eeb
master@{1}: 7f4e64169352e03476b0ea64e7e2973669e491a2

Uncovered code in 'pu' not in 'jch'
--

builtin/blame.c
74e8221b52 builtin/blame.c    928) blame_date_width = sizeof("Thu Oct 19 
16:00");

74e8221b52 builtin/blame.c    929) break;

builtin/remote.c
b7f4e371e7 builtin/remote.c 1551) die(_("--save-to-push cannot be used 
with other options"));
b7f4e371e7 builtin/remote.c 1575) die(_("--save-to-push can only be used 
when only one url is defined"));


date.c
74e8221b52  113) die("Timestamp too large for this system: %"PRItime, time);
74e8221b52  216) if (tm->tm_mon == human_tm->tm_mon) {
74e8221b52  217) if (tm->tm_mday > human_tm->tm_mday) {
74e8221b52  219) } else if (tm->tm_mday == human_tm->tm_mday) {
74e8221b52  220) hide.date = hide.wday = 1;
74e8221b52  221) } else if (tm->tm_mday + 5 > human_tm->tm_mday) {
74e8221b52  223) hide.date = 1;
74e8221b52  231) gettimeofday(, NULL);
74e8221b52  232) show_date_relative(time, tz, , buf);
74e8221b52  233) return;
74e8221b52  246) hide.seconds = 1;
74e8221b52  247) hide.tz |= !hide.date;
74e8221b52  248) hide.wday = hide.time = !hide.year;
74e8221b52  262) strbuf_rtrim(buf);
74e8221b52  287) gettimeofday(, NULL);
74e8221b52  290) human_tz = local_time_tzoffset(now.tv_sec, _tm);
74e8221b52  886) static int auto_date_style(void)
74e8221b52  888) return (isatty(1) || pager_in_use()) ? DATE_HUMAN : 
DATE_NORMAL;

74e8221b52  909) return DATE_HUMAN;
74e8221b52  911) return auto_date_style();

protocol.c
24c10f7473  37) die(_("Unrecognized protocol version"));
24c10f7473  39) die(_("Unrecognized protocol_version"));

remote-curl.c
24c10f7473  403) return 0;

sha1-array.c
bba406749a 91) oidcpy([dst], [src]);

strbuf.c
10a40f5700  397) return 0;

submodule.c
e2419f7e30 1376) strbuf_release();
7454fe5cb6 1499) struct get_next_submodule_task *task = task_cb;
7454fe5cb6 1503) get_next_submodule_task_release(task);
7454fe5cb6 1530) return 0;
7454fe5cb6 1534) goto out;
7454fe5cb6 1549) return 0;

wrapper.c
5efde212fc  70) die("Out of memory, malloc failed (tried to allocate %" 
PRIuMAX " bytes)",
5efde212fc  73) error("Out of memory, malloc failed (tried to allocate 
%" PRIuMAX " bytes)",


Commits introducing uncovered code:
Anders Waldenborg  10a40f570: strbuf: separate callback for 
strbuf_expand:ing literals
Denton Liu  b7f4e371e: remote: add --save-to-push option to git 
remote set-url
Josh Steadmon  24c10f747: protocol: advertise multiple supported 
versions

Linus Torvalds  74e8221b5: Add 'human' date format
Martin Koegler  5efde212f: zlib.c: use size_t for size
Stefan Beller  7454fe5cb: fetch: try fetching submodules if needed 
objects were not fetched

Stefan Beller  bba406749: sha1-array: provide oid_array_filter
Stefan Beller  e2419f7e3: submodule: migrate get_next_submodule to 
use repository structs




Uncovered code in 'jch' not in 'next'


apply.c
0f086e6dca 3355) if (checkout_entry(ce, , NULL, NULL) ||
0f086e6dca 3356) lstat(ce->name, st))

builtin/branch.c
0ecb1fc726 builtin/branch.c 456) die(_("could not resolve HEAD"));
0ecb1fc726 builtin/branch.c 462) die(_("HEAD (%s) points outside of 
refs/heads/"), refname);


hex.c
47edb64997  93) char *sha1_to_hex_r(char *buffer, const unsigned char *sha1)
47edb64997  95) return hash_to_hex_algop_r(buffer, sha1, 
_algos[GIT_HASH_SHA1]);

47edb64997 116) char *hash_to_hex(const unsigned char *hash)
47edb64997 118) return hash_to_hex_algop(hash, the_hash_algo);

pathspec.c
22af33bece 671) name = to_free = xmemdupz(name, namelen);

read-cache.c
ee70c12820 1730) if (advice_unknown_index_extension) {
ee70c12820 1731) warning(_("ignoring optional %.4s index extension"), ext);
ee70c12820 1732) advise(_("This is likely due to the file having been 
written by a newer\n"


sequencer.c
18e711a162 2387) opts->quiet = 1;

sha1-file.c
2f90b9d9b4 sha1-file.c  172) int hash_algo_by_name(const char *name)
2f90b9d9b4 sha1-file.c  175) if (!name)
2f90b9d9b4 sha1-file.c  176) return GIT_HASH_UNKNOWN;
2f90b9d9b4 sha1-file.c  177) for (i = 1; i < GIT_HASH_NALGOS; i++)
2f90b9d9b4 sha1-file.c  178) if (!strcmp(name, hash_algos[i].name))
2f90b9d9b4 sha1-file.c  179) return i;
2f90b9d9b4 sha1-file.c  180) return GIT_HASH_UNKNOWN;
2f90b9d9b4 sha1-file.c  183) int hash_algo_by_id(uint32_t format_id)
2f90b9d9b4 sha1-file.c  186) for (i = 1; i < GIT_HASH_NALGOS; i++)
2f90b9d9b4 sha1-file.c  187) if (format_id == hash_algos[i].format_id)
2f90b9d9b4 sha1-file.c  188) return i;
2f90b9d9b4 sha1-file.c  189) return GIT_HASH_UNKNOWN;

tree.c
e092073d64 104) commit = lookup_commit(r, entry.oid);

Commits introducing uncovered code:

[PATCH] l10n: update German translation

[Ralf Thielow]

Signed-off-by: Ralf Thielow 
---
 po/de.po | 827 +--
 1 file changed, 375 insertions(+), 452 deletions(-)

diff --git a/po/de.po b/po/de.po
index 3cf9405df..256b668a8 100644
--- a/po/de.po
+++ b/po/de.po
@@ -943,17 +943,17 @@ msgid ""
 "Use '\\!' for literal leading exclamation."
 msgstr ""
 "Verneinende Muster werden in Git-Attributen ignoriert.\n"
 "Benutzen Sie '\\!' für führende Ausrufezeichen."
 
 #: bisect.c:468
 #, c-format
 msgid "Badly quoted content in file '%s': %s"
-msgstr "Ungültiger Inhalt bzgl. Anführungsstriche in Datei '%s': %s"
+msgstr "Ungültiger Inhalt bzgl. Anführungszeichen in Datei '%s': %s"
 
 #: bisect.c:676
 #, c-format
 msgid "We cannot bisect more!\n"
 msgstr "Keine binäre Suche mehr möglich!\n"
 
 #: bisect.c:730
 #, c-format
@@ -1282,19 +1282,18 @@ msgstr "Das Paket speichert eine komplette Historie."
 #: bundle.c:201
 #, c-format
 msgid "The bundle requires this ref:"
 msgid_plural "The bundle requires these %d refs:"
 msgstr[0] "Das Paket benötigt diese Referenz:"
 msgstr[1] "Das Paket benötigt diese %d Referenzen:"
 
 #: bundle.c:267
-#, fuzzy
 msgid "unable to dup bundle descriptor"
-msgstr "Konnte Descriptor nicht umleiten."
+msgstr "Konnte dup für Descriptor des Pakets nicht ausführen."
 
 #: bundle.c:274
 msgid "Could not spawn pack-objects"
 msgstr "Konnte Paketobjekte nicht erstellen"
 
 #: bundle.c:285
 msgid "pack-objects died"
 msgstr "Erstellung der Paketobjekte abgebrochen"
@@ -1433,28 +1432,26 @@ msgid "could not find commit %s"
 msgstr "Konnte Commit %s nicht finden."
 
 #: commit-graph.c:617 builtin/pack-objects.c:2652
 #, c-format
 msgid "unable to get type of object %s"
 msgstr "Konnte Art von Objekt '%s' nicht bestimmen."
 
 #: commit-graph.c:651
-#, fuzzy
 msgid "Annotating commits in commit graph"
-msgstr "Zu viele Commits zum Schreiben des Graphen."
+msgstr "Annotiere Commits in Commit-Graphen"
 
 #: commit-graph.c:691
 msgid "Computing commit graph generation numbers"
-msgstr ""
+msgstr "Commit-Graph Generierungsnummern berechnen"
 
 #: commit-graph.c:803 commit-graph.c:826 commit-graph.c:852
-#, fuzzy
 msgid "Finding commits for commit graph"
-msgstr "Zu viele Commits zum Schreiben des Graphen."
+msgstr "Bestimme Commits für Commit-Graphen"
 
 #: commit-graph.c:812
 #, c-format
 msgid "error adding pack %s"
 msgstr "Fehler beim Hinzufügen von Paket %s."
 
 #: commit-graph.c:814
 #, c-format
@@ -1478,17 +1475,17 @@ msgstr "Konnte führende Verzeichnisse von '%s' nicht 
erstellen."
 #: commit-graph.c:1002
 msgid "the commit-graph file has incorrect checksum and is likely corrupt"
 msgstr ""
 "Die Commit-Graph-Datei hat eine falsche Prüfsumme und ist wahrscheinlich "
 "beschädigt."
 
 #: commit-graph.c:1046
 msgid "Verifying commits in commit graph"
-msgstr ""
+msgstr "Commit in Commit-Graph überprüfen"
 
 #: compat/obstack.c:405 compat/obstack.c:407
 msgid "memory exhausted"
 msgstr "Speicher verbraucht"
 
 #: config.c:123
 #, c-format
 msgid ""
@@ -2193,37 +2190,39 @@ msgstr[1] "%s, und % Monaten"
 #, c-format
 msgid "% year ago"
 msgid_plural "% years ago"
 msgstr[0] "vor % Jahr"
 msgstr[1] "vor % Jahren"
 
 #: delta-islands.c:268
 msgid "Propagating island marks"
-msgstr ""
+msgstr "Erzeuge Delta-Island Markierungen"
 
 #: delta-islands.c:286
-#, fuzzy, c-format
+#, c-format
 msgid "bad tree object %s"
-msgstr "Konnte Objekt %s nicht lesen."
+msgstr "Ungültiges Tree-Objekt %s."
 
 #: delta-islands.c:330
-#, fuzzy, c-format
+#, c-format
 msgid "failed to load island regex for '%s': %s"
-msgstr "Fehler beim Finden des \"Tree\"-Objektes von %s."
+msgstr "Fehler beim Laden des regulären Ausdrucks des Delta-Island für '%s': 
%s"
 
 #: delta-islands.c:386
 #, c-format
 msgid "island regex from config has too many capture groups (max=%d)"
 msgstr ""
+"Regulärer Ausdruck des Delta-Island aus Konfiguration hat zu\n"
+"viele Capture-Gruppen (maximal %d)."
 
 #: delta-islands.c:462
 #, c-format
 msgid "Marked %d islands, done.\n"
-msgstr ""
+msgstr "%d Delta-Islands markiert, fertig.\n"
 
 #: diffcore-order.c:24
 #, c-format
 msgid "failed to read orderfile '%s'"
 msgstr "Fehler beim Lesen der Reihenfolgedatei '%s'."
 
 #: diffcore-rename.c:544
 msgid "Performing inexact rename detection"
@@ -2592,21 +2591,21 @@ msgstr "Unerwartete Acknowledgment-Zeile: '%s'"
 
 #: fetch-pack.c:1249
 #, c-format
 msgid "error processing acks: %d"
 msgstr "Fehler beim Verarbeiten von ACKS: %d"
 
 #: fetch-pack.c:1259
 msgid "expected packfile to be sent after 'ready'"
-msgstr ""
+msgstr "Erwartete Versand einer Packdatei nach 'ready'."
 
 #: fetch-pack.c:1261
 msgid "expected no other sections to be sent after no 'ready'"
-msgstr ""
+msgstr "Erwartete keinen Versand einer anderen Sektion ohne 'ready'."
 
 #: fetch-pack.c:1298
 #, c-format
 msgid "error processing shallow info: %d"
 msgstr "Fehler beim Verarbeiten von Shallow-Informationen: %d"
 
 #: fetch-pack.c:1314
 #, c-format
@@ -2746,26 +2745,25 @@ msgid "unsupported 

Re: [PATCH v3 06/16] sequencer: refactor sequencer_add_exec_commands() to work on a todo_list

[Phillip Wood]

Hi Alban

Sorry it has taken me a while to look at the latest iteration. I like
the changes to pass a list of strings for the exec commands. I've only
had a chance to take a quick look, but I've got a couple of comments below

On 09/11/2018 08:07, Alban Gruin wrote:

This refactors sequencer_add_exec_commands() to work on a todo_list to
avoid redundant reads and writes to the disk.

Instead of just inserting the `exec' command between the other commands,
and re-parsing the buffer at the end the exec command is appended to the
buffer once, and a new list of items is created.  Items from the old
list are copied across and new `exec' items are appended when
necessary.  This eliminates the need to reparse the buffer, but this
also means we have to use todo_list_write_to_disk() to write the file().

todo_list_add_exec_commands() and sequencer_add_exec_commands() are
modified to take a string list instead of a string -- one item for each
command.  This makes it easier to insert a new command to the todo list
for each command to execute.

sequencer_add_exec_commands() still reads the todo list from the disk,
as it is needed by rebase -p.

complete_action() still uses sequencer_add_exec_commands() for now.
This will be changed in a future commit.

Signed-off-by: Alban Gruin 
---
 builtin/rebase--interactive.c |  15 +++--
 sequencer.c   | 111 +-
 sequencer.h   |   4 +-
 3 files changed, 83 insertions(+), 47 deletions(-)

diff --git a/builtin/rebase--interactive.c b/builtin/rebase--interactive.c
index c1d87c0fe6..1fb5a43c0d 100644
--- a/builtin/rebase--interactive.c
+++ b/builtin/rebase--interactive.c
@@ -65,7 +65,7 @@ static int do_interactive_rebase(struct replay_opts *opts, 
unsigned flags,
 const char *onto, const char *onto_name,
 const char *squash_onto, const char *head_name,
 const char *restrict_revision, char 
*raw_strategies,
-const char *cmd, unsigned autosquash)
+struct string_list *commands, unsigned 
autosquash)
 {
int ret;
const char *head_hash = NULL;
@@ -115,7 +115,7 @@ static int do_interactive_rebase(struct replay_opts *opts, 
unsigned flags,
else {
discard_cache();
ret = complete_action(opts, flags, shortrevisions, onto_name, 
onto,
- head_hash, cmd, autosquash);
+ head_hash, commands, autosquash);
}
 
 	free(revisions);

@@ -138,6 +138,7 @@ int cmd_rebase__interactive(int argc, const char **argv, 
const char *prefix)
const char *onto = NULL, *onto_name = NULL, *restrict_revision = NULL,
*squash_onto = NULL, *upstream = NULL, *head_name = NULL,
*switch_to = NULL, *cmd = NULL;
+   struct string_list commands = STRING_LIST_INIT_DUP;
char *raw_strategies = NULL;
enum {
NONE = 0, CONTINUE, SKIP, EDIT_TODO, SHOW_CURRENT_PATCH,
@@ -220,6 +221,12 @@ int cmd_rebase__interactive(int argc, const char **argv, 
const char *prefix)
warning(_("--[no-]rebase-cousins has no effect without "
  "--rebase-merges"));
 
+	if (cmd && *cmd) {

+   string_list_split(, cmd, '\n', -1);
+   if (strlen(commands.items[commands.nr - 1].string) == 0)
+   --commands.nr;
+   }
+
switch (command) {
case NONE:
if (!onto && !upstream)
@@ -227,7 +234,7 @@ int cmd_rebase__interactive(int argc, const char **argv, 
const char *prefix)
 
 		ret = do_interactive_rebase(, flags, switch_to, upstream, onto,

onto_name, squash_onto, head_name, 
restrict_revision,
-   raw_strategies, cmd, autosquash);
+   raw_strategies, , 
autosquash);
break;
case SKIP: {
struct string_list merge_rr = STRING_LIST_INIT_DUP;
@@ -261,7 +268,7 @@ int cmd_rebase__interactive(int argc, const char **argv, 
const char *prefix)
ret = rearrange_squash();
break;
case ADD_EXEC:
-   ret = sequencer_add_exec_commands(cmd);
+   ret = sequencer_add_exec_commands();
break;
default:
BUG("invalid command '%d'", command);
diff --git a/sequencer.c b/sequencer.c
index 900899ef20..11692d0b98 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -4394,24 +4394,29 @@ int sequencer_make_script(FILE *out, int argc, const 
char **argv,
return 0;
 }
 
-/*

- * Add commands after pick and (series of) squash/fixup commands
- * in the todo list.
- */
-int sequencer_add_exec_commands(const char *commands)
+static void todo_list_add_exec_commands(struct todo_list *todo_list,
+ 

Re: [PATCH 3/5] pack-objects: add --sparse option

[Derrick Stolee]

On 11/29/2018 9:39 PM, Junio C Hamano wrote:

Derrick Stolee  writes:


While _eventually_ we should make this opt-out, we shouldn't do that
until it has cooked a while.

I actually do not agree.  If the knob gives enough benefit, the
users will learn about it viva voce, and in a few more releases
we'll hear "enough users complain that they have to turn it on,
let's make it the default".  If that does not happen, the knob
does not deserve to be turned on in the first place.


That's a good philosophy. I'll keep it in mind.

Having said that, I won't be commenting on this shiny new toy before
the final.  I want to see more people help tying the loose ends and
give it final varnish to the upcoming release, as it seems to have
become rockier and larger release than we originally anticipated.


Yeah, no rush on this one. I just wanted to get some initial feedback 
about the idea.


Thanks,
-Stolee

Re: en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

[Elijah Newren]

On Fri, Nov 30, 2018 at 6:16 AM Junio C Hamano  wrote:
>
> Johannes Schindelin  writes:
>
> > Hi Junio,
> >
> > On Fri, 30 Nov 2018, Junio C Hamano wrote:
> >
> >> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
> >>  - rebase: implement --merge via git-rebase--interactive
> >>  - git-rebase, sequencer: extend --quiet option for the interactive 
> >> machinery
> >>
> >>  "git rebase --merge" as been reimplemented by reusing the internal
> >>  machinery used for "git rebase -i".
> >
> > I *think* a new iteration has landed (which has 7 instead of 2 commits):
> > https://public-inbox.org/git/20181122044841.20993-1-new...@gmail.com/
>
> "Landed" as opposed to "be in-flight"?
>
> You got me worried by implying that I merged them to either 'master'
> or 'next' where it is harder to back out ;-).
>
> During the freeze, especially after -rc1, I stop paying attention to
> anything other than regression fixes and fixes to the addition since
> the previous releases, unless I have too much time and get bored and
> the new topic is trivial (which often means a single patch).
>
> I'll mark the topic with the following, and continue ignoring it (or
> any other topics) for now.  Thanks.
>
> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
>  - rebase: implement --merge via git-rebase--interactive
>  - git-rebase, sequencer: extend --quiet option for the interactive machinery
>
>  "git rebase --merge" as been reimplemented by reusing the internal
>  machinery used for "git rebase -i".
>
>  Reroll exists.
>  cf. <20181122044841.20993-1-new...@gmail.com>

I've also got a reroll with an extra patch to address Duy's feedback,
an extra patch to make a small documentation clarification/correction,
and a fix to a typo in a commit message from the last roll.  But I'm
waiting for 2.20.0 to be released before sending it.

I Need An Investment Partner

[Aisha Gaddafi]

--
Hello Dear ,
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate you 30% of the total sum after the funds are
transfer into your account,
Reply me urgent for more details
Mrs Aisha Al-Qaddafi
--

Re: en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

[Johannes Schindelin]

Hi Junio,

On Fri, 30 Nov 2018, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > On Fri, 30 Nov 2018, Junio C Hamano wrote:
> >
> >> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
> >>  - rebase: implement --merge via git-rebase--interactive
> >>  - git-rebase, sequencer: extend --quiet option for the interactive 
> >> machinery
> >> 
> >>  "git rebase --merge" as been reimplemented by reusing the internal
> >>  machinery used for "git rebase -i".
> >
> > I *think* a new iteration has landed (which has 7 instead of 2 commits):
> > https://public-inbox.org/git/20181122044841.20993-1-new...@gmail.com/
> 
> "Landed" as opposed to "be in-flight"?  
> 
> You got me worried by implying that I merged them to either 'master'
> or 'next' where it is harder to back out ;-).
> 
> During the freeze, especially after -rc1, I stop paying attention to
> anything other than regression fixes and fixes to the addition since
> the previous releases, unless I have too much time and get bored and
> the new topic is trivial (which often means a single patch).

I thought so, but then I thought I had seen you commenting on the
(distinctly non-single patch distinctly non-regression fix)
`split-checkout-into-two-new-commands` patch series ;-)

> I'll mark the topic with the following, and continue ignoring it (or
> any other topics) for now.  Thanks.
> 
> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
>  - rebase: implement --merge via git-rebase--interactive
>  - git-rebase, sequencer: extend --quiet option for the interactive machinery
> 
>  "git rebase --merge" as been reimplemented by reusing the internal
>  machinery used for "git rebase -i".
> 
>  Reroll exists.
>  cf. <20181122044841.20993-1-new...@gmail.com>

Thank you, much appreciated.
Dscho

Re: en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

[Junio C Hamano]

Johannes Schindelin  writes:

> Hi Junio,
>
> On Fri, 30 Nov 2018, Junio C Hamano wrote:
>
>> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
>>  - rebase: implement --merge via git-rebase--interactive
>>  - git-rebase, sequencer: extend --quiet option for the interactive machinery
>> 
>>  "git rebase --merge" as been reimplemented by reusing the internal
>>  machinery used for "git rebase -i".
>
> I *think* a new iteration has landed (which has 7 instead of 2 commits):
> https://public-inbox.org/git/20181122044841.20993-1-new...@gmail.com/

"Landed" as opposed to "be in-flight"?  

You got me worried by implying that I merged them to either 'master'
or 'next' where it is harder to back out ;-).

During the freeze, especially after -rc1, I stop paying attention to
anything other than regression fixes and fixes to the addition since
the previous releases, unless I have too much time and get bored and
the new topic is trivial (which often means a single patch).

I'll mark the topic with the following, and continue ignoring it (or
any other topics) for now.  Thanks.

* en/rebase-merge-on-sequencer (2018-11-08) 2 commits
 - rebase: implement --merge via git-rebase--interactive
 - git-rebase, sequencer: extend --quiet option for the interactive machinery

 "git rebase --merge" as been reimplemented by reusing the internal
 machinery used for "git rebase -i".

 Reroll exists.
 cf. <20181122044841.20993-1-new...@gmail.com>

en/rebase-merge-on-sequencer, was Re: What's cooking in git.git (Nov 2018, #07; Fri, 30)

[Johannes Schindelin]

Hi Junio,

On Fri, 30 Nov 2018, Junio C Hamano wrote:

> * en/rebase-merge-on-sequencer (2018-11-08) 2 commits
>  - rebase: implement --merge via git-rebase--interactive
>  - git-rebase, sequencer: extend --quiet option for the interactive machinery
> 
>  "git rebase --merge" as been reimplemented by reusing the internal
>  machinery used for "git rebase -i".

I *think* a new iteration has landed (which has 7 instead of 2 commits):
https://public-inbox.org/git/20181122044841.20993-1-new...@gmail.com/

Assuming that the -rc2 work has been interfering, I guess you wanted to
pick that up some time after -rc2 or even after -final?

Ciao,
Dscho

Security Alert. git@vger.kernel.org has password william. Password must be changed.

[julio.sola]

Hello!

I have very bad news for you.
09/08/2018 - on this day I hacked your OS and got full access to your account 
git@vger.kernel.org
On this day your account git@vger.kernel.org has password: william

So, you can change the password, yes.. But my malware intercepts it every time.

How I made it:
In the software of the router, through which you went online, was a 
vulnerability.
I just hacked this router and placed my malicious code on it.
When you went online, my trojan was installed on the OS of your device.

After that, I made a full dump of your disk (I have all your address book, 
history of viewing sites, all files, phone numbers and addresses of all your 
contacts).

A month ago, I wanted to lock your device and ask for a not big amount of btc 
to unlock.
But I looked at the sites that you regularly visit, and I was shocked by what I 
saw!!!
I'm talk you about sites for adults.

I want to say - you are a BIG pervert. Your fantasy is shifted far away from 
the normal course!

And I got an idea
I made a screenshot of the adult sites where you have fun (do you understand 
what it is about, huh?).
After that, I made a screenshot of your joys (using the camera of your device) 
and glued them together.
Turned out amazing! You are so spectacular!

I'm know that you would not like to show these screenshots to your friends, 
relatives or colleagues.
I think $744 is a very, very small amount for my silence.
Besides, I have been spying on you for so long, having spent a lot of time!

Pay ONLY in Bitcoins!
My BTC wallet: 1HkKgPbcMyfhrdPsbufTFczzVnhyT5snB3

You do not know how to use bitcoins?
Enter a query in any search engine: "how to replenish btc wallet".
It's extremely easy

For this payment I give you two days (48 hours).
As soon as this letter is opened, the timer will work.

After payment, my virus and dirty screenshots with your enjoys will be 
self-destruct automatically.
If I do not receive from you the specified amount, then your device will be 
locked, and all your contacts will receive a screenshots with your "enjoys".

I hope you understand your situation.
- Do not try to find and destroy my virus! (All your data, files and 
screenshots is already uploaded to a remote server)
- Do not try to contact me (you yourself will see that this is impossible, the 
sender address is automatically generated)
- Various security services will not help you; formatting a disk or destroying 
a device will not help, since your data is already on a remote server.

P.S. You are not my single victim. so, I guarantee you that I will not disturb 
you again after payment!
 This is the word of honor hacker

I also ask you to regularly update your antiviruses in the future. This way you 
will no longer fall into a similar situation.

Do not hold evil! I just do my job.
Good luck.

git difftool directory diff problem copying changes back is not reliable

[Uwe Hafner]

I have a problem with directory diff. The following command:

Git difftool -d _commit_sha_

Opens my compare tool (Beyondcompare) and I can make a folder diff. The tool
also allows browsing through all changes and looking/editing single files (a
beyondcompare feature).
So my workflow would be to open single files and make changes to the right
side of the diff.

After saving and exiting the diff tool sometimes these changes are copied
back to my working tree.
 
I currently assume from my tests that changes are copied to the working tree
if they are not too deeply nested in folders. So changes to files in folders
up to a depth of about 4 or so are copied back. If any deeper they are not.

My system specs:
OS: Windows 10
Git: 2.19.2.windows.1

Folder of repo. Folder name length is identical to real folder name length
in case it is a folder name length issue: 
C:\Users\Developer\source\repos\Project_name_length_

Folder for comparison (temp names are really used names):
Commit sha side:
C:\Users\Developer\AppData\Local\Temp\git-difftool.a07928\left
Working tree copy side:
C:\Users\Developer\AppData\Local\Temp\git-difftool.a07928\right

Can anyone confirm this?
Thanks

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

[Johannes Schindelin]

Hi Junio,

On Fri, 30 Nov 2018, Junio C Hamano wrote:

> Junio C Hamano  writes:
> 
> >> I had to delay -rc2 to see these last minute tweaks come to some
> >> reasonable place to stop at, and I do not think we want to delay the
> >> final any longer or destablizing it further by piling last minute
> >> undercooked changes on top.
> >
> > So how about doing this on top of 'master' instead?  As this leaks
> > *no* information wrt how range-diff machinery should behave from the
> > format-patch side by not passing any diffopt, as long as the new
> > code I added to show_range_diff() comes up with a reasonable default
> > diffopts (for which I really would appreciate extra sets of eyes to
> > make sure), this change by definition cannot be wrong (famous last
> > words).
> 
> As listed in today's "What's cooking" report, I've merged this to
> 'next' in today's pushout and planning to have it in the -rc2.  I am
> not married to this exact implementation, and I'd welcome to have an
> even simpler and less disruptive solution if exists, but I am hoping
> that this is a good-enough interim measure for the upcoming release,
> until we decide what to do with the customizability of range-diff
> driven by format-patch.
> 
> In addition to this, I am planning the "rebase --stat" and "reflog
> that does not say 'rebase -i' but 'rebase'" fixes merged to 'master'
> before cutting -rc2.

Thank you for integrating them. That way, we have an -rc2 with no issues
in the built-in rebase/rebase -i that we know of.

Ciao,
Dscho

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

[Duy Nguyen]

On Fri, Nov 30, 2018 at 12:29 PM Ævar Arnfjörð Bjarmason
 wrote:
>
>
> On Fri, Nov 30 2018, Duy Nguyen wrote:
>
> > On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
> >  wrote:
> >> Assuming greenfield development (which we definitely don't have), I
> >> don't like the "restore-files" name, but the alternative that makes
> >> sense is "checkout". Then this "--from" argument could become "git
> >> checkout-tree  -- ", and we'd have:
> >>
> >> git switch 
> >> git checkout 
> >> git checkout-tree  -- 
> >>
> >> Or maybe that sucks, anyway what I was going to suggest is *if* others
> >> think that made sense as a "if we designed git today" endgame whether we
> >> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
> >> anticipation of Git 3.0) and you'd get that behavior. There could be
> >> some other setting where core.uiVersion would use the old behavior (or
> >> with another setting, only warn) if we weren't connected to a terminal.
> >
> > core.uiVersion is a big no no to me. I don't want to go to someone's
> > terminal, type something and have a total surprise because they set
> > different ui version. If you want a total UI redesign, go with a new
> > prefix, like "ng" (for new git) or something instead of "git".
>
> I don't think that's a viable way forward. First, we're not talking
> about a total change of the UI. Most the main porcelain will stay the
> same. So we'd have a "ng" that's >98% the same UI, and then if we
> discover warts in in 10 years we'd like to fix then what do wo do? Ship
> "nng" and so forth?

Yes. So think it through and try not to do it often.

> We already have this UI problem with various config variables that
> change things. I think we should just solve this general issue by a
> combination of:
>
>  a) Accepting that over the long term we will have Git's UI changing,
> sometimes in breaking ways (with sensible phase-in), hopefully for
> the better. E.g. we had this with "git-init" v.s. "git init". This
> is similar, there'd be an error due to ambiguity with a "hint"
> saying use the new thing if you e.g. feed "git checkout" a branch
> name.

And I hate adding a zillion of config keys to change little things
like this. Now you use this to change bigger behavior. No.
-- 
Duy

Re: [PATCH/RFC v3 00/14] Introduce new commands switch-branch and restore-files

[Ævar Arnfjörð Bjarmason]

On Fri, Nov 30 2018, Duy Nguyen wrote:

> On Fri, Nov 30, 2018 at 12:05 AM Ævar Arnfjörð Bjarmason
>  wrote:
>> Assuming greenfield development (which we definitely don't have), I
>> don't like the "restore-files" name, but the alternative that makes
>> sense is "checkout". Then this "--from" argument could become "git
>> checkout-tree  -- ", and we'd have:
>>
>> git switch 
>> git checkout 
>> git checkout-tree  -- 
>>
>> Or maybe that sucks, anyway what I was going to suggest is *if* others
>> think that made sense as a "if we designed git today" endgame whether we
>> could have an opt-in setting where you set e.g. core.uiVersion=3 (in
>> anticipation of Git 3.0) and you'd get that behavior. There could be
>> some other setting where core.uiVersion would use the old behavior (or
>> with another setting, only warn) if we weren't connected to a terminal.
>
> core.uiVersion is a big no no to me. I don't want to go to someone's
> terminal, type something and have a total surprise because they set
> different ui version. If you want a total UI redesign, go with a new
> prefix, like "ng" (for new git) or something instead of "git".

I don't think that's a viable way forward. First, we're not talking
about a total change of the UI. Most the main porcelain will stay the
same. So we'd have a "ng" that's >98% the same UI, and then if we
discover warts in in 10 years we'd like to fix then what do wo do? Ship
"nng" and so forth?

We already have this UI problem with various config variables that
change things. I think we should just solve this general issue by a
combination of:

 a) Accepting that over the long term we will have Git's UI changing,
sometimes in breaking ways (with sensible phase-in), hopefully for
the better. E.g. we had this with "git-init" v.s. "git init". This
is similar, there'd be an error due to ambiguity with a "hint"
saying use the new thing if you e.g. feed "git checkout" a branch
name.

 b) For the general problem of "user has exotic config" we should learn
a "git -Q " option similar to Emacs, which is another highly
customizable piece of software that has a "don't read user config"
escape hatch.

That's a bit more complex than for Emacs since we need to actually
read some config (e.g. remote config from .git/config), and maybe
opt to keep some stuff like user.*. But there's no reason we can't
have such a black/whitelist of config & env variables that impact us
with a switch to get "make it as if nothing was configured" for
whatever sane version of that we'd come up with.

Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options

[Eric Sunshine]

On Thu, Nov 29, 2018 at 11:03 AM Ævar Arnfjörð Bjarmason
 wrote:
> I mean not just nasty in terms of implementation, yeah we could do it,
> but also a nasty UX for things like --word-diff-regex. I.e. instead of:
>
> --range-diff-word-diff-regex='[0-9"]'
>
> You need:
>
> --range-diff-opts="--word-diff-regex='[0-9\"]'"
>
> Now admittedly that in itself isn't very painful *in this case*, but in
> terms of precedent I really dislike that option, i.e. git having some
> mode where I need to work to escape input to pass to another command.
>
> Not saying that this --range-diff-* thing is what we should go for, but
> surely we can find some way to do deal with this that doesn't involve
> the user needing to escape stuff like this.

I should mention that it was never the intention that
git-format-patch's --range-diff option would allow passing _all_
possible options to git-range-diff, but only those most likely to be
tweaked by the user (such as --creation-factor). It was understood
from the start (and stated by me either in the cover letter to that
series or in discussion) that the user always has the escape hatch of
running git-range-diff manually and copy/pasting its output into the
cover letter.

So, I'm not convinced that we need this sort of flexibility in
git-format-patch's --range-diff option, but we certainly can add
convenience options (such as I did with --creation-factor) as people
complain that their favorite option is missing. For a UI, I think we
already have sufficient precedent for
"--range-diff-opts=nopatch,creation-factor:60" as a possibility.

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

[Eric Sunshine]

On Thu, Nov 29, 2018 at 11:27 PM Junio C Hamano  wrote:
> Junio C Hamano  writes:
> > In any case, I tend to agree with the conclusion in the downthread
> > by Dscho that we should just clearly mark that invocations of the
> > "format-patch --range-diff" command with additional diff options is
> > an experimental feature that may not do anything sensible in the
> > upcoming release, and declare that the UI to pass diff options to
> > affect only the range-diff part may later be invented.  IOW, I am
> > coming a bit stronger than Dscho's suggestion in that we should not
> > even pretend that we aimed to make the options used for range-diff
> > customizable when driven from format-patch in the upcoming release,
> > or aimed to make --range-diff option compatible with other diff
> > options given to the format-patch command.

I agree that this way forward makes sense. It's clear that I
overlooked how there could be unexpected interactions from passing
git-format-patch's own diff_options to show_range_diff(), so taking
time to think it through without the pressure of a looming release is
preferable to rushing out some "fixes".

> So how about doing this on top of 'master' instead?  As this leaks
> *no* information wrt how range-diff machinery should behave from the
> format-patch side by not passing any diffopt, as long as the new
> code I added to show_range_diff() comes up with a reasonable default
> diffopts (for which I really would appreciate extra sets of eyes to
> make sure), this change by definition cannot be wrong (famous last
> words).

I, myself, was going to suggest this approach of leaking none of the
git-format-patch's options into range_diff(), so I think it is a good
one. Later, we can selectively pass certain _sensible_ options into
show_range_diff() once we figure out the correct UI (for instance,
--range-diff-opts=nopatch,creation-factor:60).

A couple comments on the patch itself...

> diff --git a/range-diff.c b/range-diff.c
> @@ -460,7 +460,11 @@ int show_range_diff(const char *range1, const char 
> *range2,
> -   memcpy(, diffopt, sizeof(opts));
> +   if (diffopt)
> +   memcpy(, diffopt, sizeof(opts));
> +   else
> +   repo_diff_setup(the_repository, );

The first attempt at adding --range-diff to git-format-patch invoked
the git-range-diff command, so no diff_options were passed at all.
After Dscho libified the range-diff machinery in one of his major
re-rolls, I took advantage of that to avoid the subprocess invocation.
Another benefit of calling show_range_diff() directly is that when
"git format-patch --stdout --range-diff=..." is sent to the terminal,
the range-diff gets colored output for free. I'm pleased to see that
that still works after this change.

> diff --git a/range-diff.h b/range-diff.h
> @@ -5,6 +5,11 @@
> +/*
> + * Compare series of commmits in RANGE1 and RANGE2, and emit to the
> + * standard output.  NULL can be passed to DIFFOPT to use the built-in
> + * default.
> + */

It is more correct to say that the range-diff is emitted to
diffopt->file (which may be stdout).

Thanks for working on this.

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

[Ævar Arnfjörð Bjarmason]

On Fri, Nov 30 2018, Junio C Hamano wrote:

> Junio C Hamano  writes:
>
>>> I had to delay -rc2 to see these last minute tweaks come to some
>>> reasonable place to stop at, and I do not think we want to delay the
>>> final any longer or destablizing it further by piling last minute
>>> undercooked changes on top.
>>
>> So how about doing this on top of 'master' instead?  As this leaks
>> *no* information wrt how range-diff machinery should behave from the
>> format-patch side by not passing any diffopt, as long as the new
>> code I added to show_range_diff() comes up with a reasonable default
>> diffopts (for which I really would appreciate extra sets of eyes to
>> make sure), this change by definition cannot be wrong (famous last
>> words).
>
> As listed in today's "What's cooking" report, I've merged this to
> 'next' in today's pushout and planning to have it in the -rc2.  I am
> not married to this exact implementation, and I'd welcome to have an
> even simpler and less disruptive solution if exists, but I am hoping
> that this is a good-enough interim measure for the upcoming release,
> until we decide what to do with the customizability of range-diff
> driven by format-patch.
>
> In addition to this, I am planning the "rebase --stat" and "reflog
> that does not say 'rebase -i' but 'rebase'" fixes merged to 'master'
> before cutting -rc2.

Thanks a lot, yeah having this wait looks good to me.

What's cooking in git.git (Nov 2018, #07; Fri, 30)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

The road to the upcoming 2.20 turned out to be a bit rockier as we
had a couple of subcommands with larger importance (rebase and
rebase-i) reimplemented, together with some new and exciting
commands (like range-diff and its integration into format-patch),
each with a few loose ends we needed to tie until the last minute.
I've let -rc1 and -rc2 slip for a few days to make sure we get
closer to a stable point, and I am hoping that a few topics that are
at the bottom of master..pu chain with today's pushout merged to the
'master' branch, I should be able to cut a 2.20-rc2 that is in a
reasonable shape.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* gh/diff-raw-has-no-ellipses (2018-11-26) 1 commit
  (merged to 'next' on 2018-11-29 at 24a7536f15)
 + doc: update diff-format.txt for removed ellipses in --raw

 "git diff --raw" lost ellipses to adjust the output columns for
 some time now, but the documentation still showed them.

 Will cook in 'next'.


* mk/http-backend-kill-children-before-exit (2018-11-26) 1 commit
  (merged to 'next' on 2018-11-29 at bf2d45062f)
 + http-backend: enable cleaning up forked upload/receive-pack on exit

 The http-backend CGI process did not correctly clean up the child
 processes it spawns to run upload-pack etc. when it dies itself,
 which has been corrected.

 Will cook in 'next'.


* ab/replace-graft-with-replace-advice (2018-11-29) 1 commit
  (merged to 'next' on 2018-11-30 at c5d658e075)
 + advice: don't pointlessly suggest --convert-graft-file

 The advice message to tell the user to migrate an existing graft
 file to the replace system when a graft file was read was shown
 even when "git replace --convert-graft-file" command, which is the
 way the message suggests to use, was running, which made little
 sense.

 Will merge to 'master'.


* ma/reset-doc-rendering-fix (2018-11-29) 2 commits
  (merged to 'next' on 2018-11-30 at be718c19e2)
 + git-reset.txt: render literal examples as monospace
 + git-reset.txt: render tables correctly under Asciidoctor

 Doc updates.

 Will merge to 'master'.


* sg/daemon-test-signal-fix (2018-11-27) 1 commit
  (merged to 'next' on 2018-11-30 at b3f7fdf727)
 + t/lib-git-daemon: fix signal checking

 Test fix.

 Will merge to 'master'.


* tb/log-G-binary (2018-11-29) 1 commit
 - log -G: ignore binary files

 "git log -G" looked for a hunk in the "git log -p" patch
 output that contained a string that matches the given pattern.
 Optimize this code to ignore binary files, which by default will
 not show any hunk that would match any pattern (unless textconv or
 the --text option is in effect, that is).

 Expecting an update to the tests.


* jc/format-patch-range-diff-fix (2018-11-30) 1 commit
  (merged to 'next' on 2018-11-30 at 26290b1ec1)
 + format-patch: do not let its diff-options affect --range-diff

 "git format-patch --range-diff" by mistake passed the diff options
 used to generate the primary output of the command to the
 range-diff machinery, which caused the range-diff in the cover
 letter to include fairly useless "--stat" output.  This has been
 corrected by forcing a non-customizable default formatting options
 on the range-diff machinery when driven by format-patch.

 Will merge to 'master'.


* js/rebase-reflog-action-fix (2018-11-30) 1 commit
  (merged to 'next' on 2018-11-30 at 93fd2fb920)
 + rebase: fix GIT_REFLOG_ACTION regression

 "git rebase" reimplemented recently in C accidentally changed the
 way reflog entries are recorded (earlier "rebase -i" identified the
 entries it leaves with "rebase -i", but the new version always
 marks them with "rebase").  This has been corrected.

 Will merge to 'master'.


* js/rebase-stat-unrelated-fix (2018-11-30) 1 commit
  (merged to 'next' on 2018-11-30 at a9faaff8c1)
 + rebase --stat: fix when rebasing to an unrelated history

 "git rebase --stat" to transplant a piece of history onto a totally
 unrelated history were not working before and silently showed wrong
 result.  With the recent reimplementation in C, it started to instead
 die with an error message, as the original logic was not prepared
 to cope with this case.  This has now been fixed.

 Will merge to 'master'.

--
[Graduated to "master"]

* cc/delta-islands (2018-11-21) 3 commits
  (merged to 'next' on 2018-11-21 at 3bac399f83)
 + pack-objects: fix off-by-one in delta-island tree-depth computation
 + pack-objects: zero-initialize tree_depth/layer arrays
 + pack-objects: fix tree_depth and layer invariants

 A few issues in the 

Re: [PATCH] format-patch: do not let its diff-options affect --range-diff (was Re: [PATCH 2/2] format-patch: allow for independent diff & range-diff options)

[Junio C Hamano]

Junio C Hamano  writes:

>> I had to delay -rc2 to see these last minute tweaks come to some
>> reasonable place to stop at, and I do not think we want to delay the
>> final any longer or destablizing it further by piling last minute
>> undercooked changes on top.
>
> So how about doing this on top of 'master' instead?  As this leaks
> *no* information wrt how range-diff machinery should behave from the
> format-patch side by not passing any diffopt, as long as the new
> code I added to show_range_diff() comes up with a reasonable default
> diffopts (for which I really would appreciate extra sets of eyes to
> make sure), this change by definition cannot be wrong (famous last
> words).

As listed in today's "What's cooking" report, I've merged this to
'next' in today's pushout and planning to have it in the -rc2.  I am
not married to this exact implementation, and I'd welcome to have an
even simpler and less disruptive solution if exists, but I am hoping
that this is a good-enough interim measure for the upcoming release,
until we decide what to do with the customizability of range-diff
driven by format-patch.

In addition to this, I am planning the "rebase --stat" and "reflog
that does not say 'rebase -i' but 'rebase'" fixes merged to 'master'
before cutting -rc2.