From: Johannes Schindelin
The scripted version (partially) heeded the `GIT_REFLOG_ACTION` and when
we converted to a built-in, this regressed.
Fix that, and add a regression test, both with `GIT_REFLOG_ACTION` set
and unset.
Note: the reflog message for "rebase finished" did *not* heed
Hi Ævar,
On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>
> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >
> >> On Thu, Nov 29 2018, Johannes Schindelin wrote:
> >>
> >> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >>
On Thu, Nov 29, 2018 at 7:14 PM Stefan Beller wrote:
>
> > > Idea:
> > > If git checkout-files modifies the submodules file, it could also
> > > auto-update the submodules. (For example, with something like "git
> > > submodule update --init --recursive --progress").
> >
> > This one is tricky
>
> Which brings us back to your "git checkout-files " use case
> above. It should be treat the same way in my opinion, so we either do
>
> git checkout-files --from=tree-ish :/
>
> or
>
> git checkout-files --from=tree-ish .
>
> But "git checkout-files --from=tree-ish" alone is rejected.
Ævar Arnfjörð Bjarmason writes:
>> What prevents you from using `sq_dequote_to_argv()`?
>
> 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:
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
> > Idea:
> > If git checkout-files modifies the submodules file, it could also
> > auto-update the submodules. (For example, with something like "git
> > submodule update --init --recursive --progress").
>
> This one is tricky because we should deal with submodule autoupdate
> consistently across
It has been reported on the Debian bug tracker
[https://bugs.debian.org/914695] that the built-in rebase regresses on the
scripted version, and later details emerged that this has something to do
with the reflog messages: they were different with the built-in rebase than
with the scripted one.
Nguyễn Thái Ngọc Duy writes:
> 'git switch-branch'
>
> - implicit detaching is rejected. If you need to detach, you need to
> give --detach. Or stick to 'git checkout'.
OK. Is "auto-vivify the named branch based on a remote-tracking"
also rejected, as it is a confusing behaviour that is a
Other thoughts on a global UI rethink:
One of the most common complaints I hear about git is the conceptual difficulty
required in undoing changes. https://ohshitgit.com/
> Git is hard: screwing up is easy, and figuring out how to fix your mistakes
> is fucking impossible. Git documentation
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: callgsm01
So, you can change the password, yes.. But my malware intercepts it every time.
How I made
Johannes Schindelin writes:
> But I guess that I should not be so lazy and really use two different
> messages here:
>
> Changes from to
>
> and if there is no merge base,
>
> Changes in
Ah, that's excellent.
Thanks.
Masaya Suzuki writes:
> Yes, I did. And it also didn't end up in a build error. Do I have a
> different build option...?
Passig DEVELOPER=Yes to make turns a bit more warnings on (in this
case, I think it was "unused-variable") and also uses -Werror to
turn warnings into errors.
Duy Nguyen writes:
> On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote:
>> should we do
>> something about detached HEAD in this switch-branch command (or
>> whatever its name will be)?
>>
>> This is usually a confusing concept to new users
>
> And it just occurred to me that perhaps we should
Derrick Stolee writes:
> You're right that having this hidden as an opt-in config variable
> makes it hard to discover as a typical user.
>
> I would argue that we should actually make the config setting true by
> default, and recommend that servers opt-out. Here are my reasons:
>
> 1. The vast
Hi Paul,
On Wed, 28 Nov 2018, Paul Morelle wrote:
> On 28/11/18 16:19, Johannes Schindelin wrote:
> >
> > On Wed, 28 Nov 2018, Paul Morelle wrote:
> >
> >> The 'exec' command can be used to run tests on a set of commits,
> >> interrupting on failing commits to let the user fix the tests.
> >>
>
Masaya Suzuki writes:
> In the Git pack protocol definition, an error packet may appear only in
> a certain context. However, servers can face a runtime error (e.g. I/O
> error) at an arbitrary timing. This patch changes the protocol to allow
> an error packet to be sent instead of any packet.
>
On Thu, Nov 29 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> v3 sees switch-branch go back to switch-branch (in v2 it was
>> checkout-branch). checkout-files is also renamed restore-files (v1 was
>> restore-paths). Hopefully we won't see another
The two new commands "git switch-branch" and "git restore-files" are
added to avoid the confusion of one-command-do-all "git checkout" for
new users. They are also helpful to avoid ambiguation context.
For these reasons, promote them everywhere possible. This includes
documentation,
The shortcut of these options do not make much sense when used with
switch-branch. And their descriptions are also tied to checkout
out. Move -b/-B to cmd_checkout() and new -c/-C with the same
functionality in cmd_switch_branch()
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 30
"git checkout " will checkout the commit in question and
detach HEAD from the current branch. It is naturally a right thing to
do once you get git references. But detached HEAD is a scary concept
to new users because we show a lot of warnings and stuff, and it could
be hard to get out of (until
"opts" will soon be moved out of cmd_checkout(). To keep changes in
that patch smaller, convert "opts" to a pointer and keep the real
thing behind "real_opts".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 109 +++--
1 file changed, 55
This is a preparation step for introducing new commands that do parts
of what checkout does. There will be two new commands, one is about
switching branches, detaching HEAD... one about checking out
paths. These share the a subset of command line options. The rest of
command line options are
These local variables are referenced by struct option[]. This struct
will soon be broken down, moved away and we can't rely on local
variables anymore. Move these two to struct checkout_opts in
preparation for that.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 16
"git restore-files" without arguments does not make much sense when
it's about restoring files (what files now?). We could default to
either
git restore-files .
or
git restore-files :/
Neither is intuitive. Make the user always give pathspec, force the
user to think the scope of
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore-files") of
course do accept pathspec as before.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 14
v3 sees switch-branch go back to switch-branch (in v2 it was
checkout-branch). checkout-files is also renamed restore-files (v1 was
restore-paths). Hopefully we won't see another rename.
I'll try to summarize the differences between the new commands and
'git checkout' down here, but you're
can be omitted in this syntax, and it's actually documented a
few paragraphs down:
You could omit , in which case the command degenerates to
"check out the current branch", which is a glorified no-op with
rather expensive side-effects to show only the tracking information,
if exists, for
This is in preparation for the new command restore-files, which also
needs to parse opts->source_tree but does not need all the
disambiguation logic.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 51 --
1 file changed, 31 insertions(+),
"git checkout" doing too many things is a source of confusion for many
users (and it even bites old timers sometimes). To rememdy that, the
command is now split in two: switch-branch and checkout-files. The
good old "git checkout" command is still here and will be until all
(or most of users) are
"git checkout" can be executed without any arguments. What it does is
not exactly great: it switches from HEAD to HEAD and showing worktree
modification as a side effect.
Make switch-branch reject this case. You have to either
- really switch a branch
- (explicitly) detach from the current
This is to be reused by the coming git-switch-branch.txt man page
which also deals with detached HEAD.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/detach-head.txt | 132
Documentation/git-checkout.txt | 133 +
2 files
This is another departure from 'git checkout' syntax, which uses -- to
separate ref and pathspec. The observation is restore-files (or "git
checkout ,, ") is most often used to restore some files from
the index. If this is correct, we can simplify it by taking a way the
ref, so that we can write
On Thu, Nov 29 2018, Nguyễn Thái Ngọc Duy wrote:
> v3 sees switch-branch go back to switch-branch (in v2 it was
> checkout-branch). checkout-files is also renamed restore-files (v1 was
> restore-paths). Hopefully we won't see another rename.
>
> I'll try to summarize the differences between the
Assuming the great day has come to think about this, one thing I'd love to do
is to unify the name of the index/stage/cache in command-line parameters and
the documentation.
The index/stage/cache should have one canonical name, and the documentation
should support that consistently. My taste
Duy Nguyen writes:
> 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".
On Fri, Nov 30, 2018 at 3:16 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > 'git switch-branch'
> >
> > - implicit detaching is rejected. If you need to detach, you need to
> > give --detach. Or stick to 'git checkout'.
>
> OK. Is "auto-vivify the named branch based on a
On Fri, Nov 30, 2018 at 1:16 AM Dan Fabulich wrote:
>
> Other thoughts on a global UI rethink:
>
> One of the most common complaints I hear about git is the conceptual
> difficulty required in undoing changes. https://ohshitgit.com/
>
> > Git is hard: screwing up is easy, and figuring out how to
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 -- ",
Duy Nguyen writes:
>>
>> OK. Is "auto-vivify the named branch based on a remote-tracking"
>> also rejected, as it is a confusing behaviour that is a too subtle
>> and implicit, just like the detaching head is, and require --guess
>> or sticking to 'git checkout'? I think it should.
>
> This
Hi Ævar,
On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Change the semantics of the "--range-diff" option so that the regular
> diff options can be provided separately for the range-diff and the
> patch. This allows for supplying e.g. --range-diff-U0 and -U1 to
> "format-patch" to provide
On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote:
> On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
> > v2.19.2, installed from brew on macOS Mojave 14.2.1.
> >
> > `git-gui` is my much beloved go-to tool for everything git.
> > Unfortunately, on my new Macbook Air it seems to have a bug.
Hi Merijn and Junio,
On Thu, 29 Nov 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > -test_expect_success 'run_command is restricted to PATH' '
> > +test_lazy_prereq DOT_IN_PATH '
> > + case ":$PATH:" in
> > + *:.:*) true;;
> > + *) false;;
> > + esac
> > +'
>
> An
Hi.
I have done this (on box A):
git commit -m "Message"
git tag -a 0.9.0
git push origin master
In my local repository, when I run "git tag" it is showing me "0.9.0".
Then I did (on box B)
git clone ssh://user@host:/path/project.git
cd project
git tag
Now git tag is showing nothing.
Why is
On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
wrote:
>
> git tag -a 0.9.0
> git push origin master
>
> In my local repository, when I run "git tag" it is showing me "0.9.0".
>
> Then I did (on box B)
> git clone ssh://user@host:/path/project.git
> cd project
> git tag
>
> Now git tag is
Dear Friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
Good day,
My Name is Johann Reimann and i have something important to discuss with you
but only with your permission i will proceed.
Regards
J. Reimann
Hi Paul,
On Thu, 29 Nov 2018, Johannes Schindelin wrote:
> I already added a test... See the reschedule-failed-exec branch on
> https://github.com/dscho/git.
And now I put up a proper Pull Request, to be submitted via GitGitGadget
right after Git v2.20.0 will be released (technically, we are in
Hi Ævar,
On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>
> > On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >
> >> Change the semantics of the "--range-diff" option so that the regular
> >> diff options can be provided separately
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> Change the semantics of the "--range-diff" option so that the regular
>> diff options can be provided separately for the range-diff and the
>> patch. This allows for supplying
On 11/28/2018 5:11 PM, Stefan Beller wrote:
+--sparse::
+ Use the "sparse" algorithm to determine which objects to include in
+ the pack. This can have significant performance benefits when computing
+ a pack to send a small change. However, it is possible that extra
+
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>>
>> > On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> Change the semantics of the "--range-diff" option so
From: Derrick Stolee
In preparation for a new algorithm that walks fewer trees when
creating a pack from a set of revisions, create a method that
takes an oidset of tree oids and marks reachable objects as
UNINTERESTING.
The current implementation uses the existing
mark_tree_uninteresting to
From: Derrick Stolee
When creating a pack-file using 'git pack-objects --revs' we provide
a list of interesting and uninteresting commits. For example, a push
operation would make the local topic branch be interesting and the
known remote refs as uninteresting. We want to discover the set of
new
From: Derrick Stolee
The '--sparse' flag in 'git pack-objects' changes the algorithm
used to enumerate objects to one that is faster for individual
users pushing new objects that change only a small cone of the
working directory. The sparse algorithm is not recommended for a
server, which likely
One of the biggest remaining pain points for users of very large
repositories is the time it takes to run 'git push'. We inspected some slow
pushes by our developers and found that the "Enumerating Objects" phase of a
push was very slow. This is unsurprising, because this is why reachability
Hi Jonathan,
if you could pry more information (or better information) out of that bug
reporter, that would be nice. Apparently my email address is blacklisted
by his mail provider, so he is unlikely to have received my previous mail
(nor will he receive this one, I am sure).
Thanks,
Dscho
On
From: Derrick Stolee
Create a test variable GIT_TEST_PACK_SPARSE to enable the sparse
object walk algorithm by default during the test suite. Enabling
this variable ensures coverage in many interesting cases, such as
shallow clones, partial clones, and missing objects.
Signed-off-by: Derrick
From: Derrick Stolee
When enumerating objects to place in a pack-file during 'git
pack-objects --revs', we discover the "frontier" of commits
that we care about and the boundary with commit we find
uninteresting. From that point, we walk trees to discover which
trees and blobs are uninteresting.
From: Derrick Stolee
Add a '--sparse' option flag to the pack-objects builtin. This
allows the user to specify that they want to use the new logic
for walking trees. This logic currently does not differ from the
existing output, but will in a later change.
Create a new test script,
Hi Junio,
On Thu, 29 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > The built-in version of the `git rebase` command blindly translated that
> > shell script code, assuming that there is no need to test whether there
> > *was* a merge base, and due to
On November 29, 2018 6:56, Mateusz Loskot wrote:
> On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
> wrote:
> >
> > git tag -a 0.9.0
> > git push origin master
> >
> > In my local repository, when I run "git tag" it is showing me "0.9.0".
> >
> > Then I did (on box B)
> > git clone
Hi Junio,
On Mon, 26 Nov 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Thomas Gummerer writes:
> >
> >> Thanks for your work on this! I have read through the range-diff and
> >> the new patch of this last round, and this addresses all the comments
> >> I had on v10 (and some
We're really entering obscure territory here, I would say.
To trigger the bug, two things have to come together: the user must have
asked for a diffstat afterwards, and the commits need to have been rebased
onto a completely unrelated commit history (i.e. there must exist no merge
base between
From: Johannes Schindelin
When rebasing to a commit history that has no common commits with the
current branch, there is no merge base. In diffstat mode, this means
that we cannot compare to the merge base, but we have to compare to the
empty tree instead.
Also, if running in verbose diffstat
Just checked gitk, it seems to work fine including children windows.
This problem seems to affect git-gui only.
On Thu, Nov 29, 2018 at 5:16 AM Eric Sunshine wrote:
>
> On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller wrote:
> > On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta wrote:
> > > v2.19.2,
On Thu, 29 Nov 2018 at 14:40, Randall S. Becker wrote:
> On November 29, 2018 6:56, Mateusz Loskot wrote:
> > On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
> > wrote:
> > >
> > > git tag -a 0.9.0
> > > git push origin master
> > >
> > > In my local repository, when I run "git tag" it
Hi Junio,
On Thu, 29 Nov 2018, Johannes Schindelin wrote:
> On Mon, 26 Nov 2018, Junio C Hamano wrote:
>
> > Junio C Hamano writes:
> >
> > > Thomas Gummerer writes:
> > >
> > >> Thanks for your work on this! I have read through the range-diff and
> > >> the new patch of this last round,
On 11/28/2018 4:37 AM, Johannes Schindelin wrote:
Hi Ben,
On Tue, 27 Nov 2018, Ben Peart wrote:
From: Ben Peart
Add tracing around initializing and discarding mempools. In discard report
on the amount of memory unused in the current block to help tune setting
the initial_size.
On 11/28/2018 8:31 AM, SZEDER Gábor wrote:
On Tue, Nov 27, 2018 at 02:50:57PM -0500, Ben Peart wrote:
diff --git a/t/t1092-virtualworkdir.sh b/t/t1092-virtualworkdir.sh
new file mode 100755
index 00..0cdfe9b362
--- /dev/null
+++ b/t/t1092-virtualworkdir.sh
@@ -0,0 +1,393 @@
Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as
an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> if you could pry more information (or better information) out of that bug
> reporter, that would be nice. Apparently my email address is
On Wed, Nov 28 2018, Mateusz Loskot wrote:
> Hi,
>
> (using git version 2.19.2.windows.1)
>
> I've just encountered one of those WTH moments.
>
> I have a bare repository
>
> core.git (BARE:master) $ git branch
> 1.0
> 2.0
> * master
>
> core.git (BARE:master) $ git tag
> 1.0.1651
> 1.0.766
On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Nov 28 2018, Mateusz Loskot wrote:
> >
> > (using git version 2.19.2.windows.1)
> >
> > I've just encountered one of those WTH moments.
> >
> > I have a bare repository
> >
> > core.git (BARE:master) $ git branch
> > 1.0
> >
On Wed, Nov 28, 2018 at 9:30 PM Stefan Beller wrote:
>
> On Wed, Nov 28, 2018 at 12:09 PM Duy Nguyen wrote:
> >
> > On Wed, Nov 28, 2018 at 9:01 PM Duy Nguyen wrote:
> > > should we do
> > > something about detached HEAD in this switch-branch command (or
> > > whatever its name will be)?
> > >
Hi Ian,
On Thu, 29 Nov 2018, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation
> as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> > if you could pry more information (or better information) out of that bug
> > reporter,
On Thu, Nov 29 2018, Mateusz Loskot wrote:
> On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason
> wrote:
>> On Wed, Nov 28 2018, Mateusz Loskot wrote:
>> >
>> > (using git version 2.19.2.windows.1)
>> >
>> > I've just encountered one of those WTH moments.
>> >
>> > I have a bare repository
Hi Ævar,
On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>
> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >
> >> On Thu, Nov 29 2018, Johannes Schindelin wrote:
> >>
> >> > On Wed, 28 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> >>
On Thu, Nov 29 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>>
>> > On Thu, 29 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> On Thu, Nov 29 2018, Johannes Schindelin wrote:
>> >>
>>
On Thu, Nov 29 2018, Stefanie Leisestreichler wrote:
> Hi.
>
> I have done this (on box A):
>
> git commit -m "Message"
> git tag -a 0.9.0
> git push origin master
>
> In my local repository, when I run "git tag" it is showing me "0.9.0".
>
> Then I did (on box B)
> git clone
On Thu, Nov 29, 2018 at 6:59 AM Junio C Hamano wrote:
>
> Stefan Xenos writes:
>
> > Although I have no problem with "switch-branch" as a command name,
> > some alternative names we might consider for switch-branch might be:
> >
> > chbranch
> > swbranch
>
> Please never go in that direction.
Hi Ben,
On Thu, 29 Nov 2018, Ben Peart wrote:
> On 11/28/2018 4:37 AM, Johannes Schindelin wrote:
> > Hi Ben,
> >
> > On Tue, 27 Nov 2018, Ben Peart wrote:
> >
> > > From: Ben Peart
> > >
> > > Add tracing around initializing and discarding mempools. In discard report
> > > on the amount of
On Thu, Nov 29, 2018 at 12:22 AM Stefan Xenos wrote:
> Some behaviors I'd expect to see from these commands (I haven't yet
> checked to see if you've already done this):
>
> git checkout-files
> should reset all the files in the repository regardless of the current
> directory - it should
Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as
an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> > In a successful run with older git I get a reflog like this:
> >
> >4833d74 HEAD@{0}: rebase finished: returning to
> >
On Thu, Nov 29, 2018 at 3:42 AM Junio C Hamano wrote:
>
> Masaya Suzuki writes:
>
> > In the Git pack protocol definition, an error packet may appear only in
> > a certain context. However, servers can face a runtime error (e.g. I/O
> > error) at an arbitrary timing. This patch changes the
Hi Ian,
On Thu, 29 Nov 2018, Ian Jackson wrote:
> Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation
> as an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> > > In a successful run with older git I get a reflog like this:
> > >
> > >4833d74
Johannes Schindelin writes ("Re: [PATCH] rebase: mark the C reimplementation as
an experimental opt-in feature (was Re: [ANNOUNCE] Git v2.20.0-rc1)"):
> I'll have to take a (lengthy) dinner break now, but this is what I have so
> far: a regression test that verifies the breakage (see the
>
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: ani420
So, you can change the password, yes.. But my malware intercepts it every time.
How I made
87 matches
Mail list logo
