On Tue, 11 Dec 2018, Jon Forrest wrote:
> On 12/11/2018 2:50 AM, Jeff King wrote:
>
> > The content at https://git-scm.com/book is pulled regularly from
> > https://github.com/progit/progit2, which has collected a number of
> > fixes (as well as translations) since the 2nd edition was
> > released
Duy Nguyen writes:
> I have a better plan: stop exposing parse-options loop to outside.
> What all these commands need is the ability to deal with unknown
> options (or non-options in update-index case). They could register
> callbacks to deal with those and keep calling parse_options() instead.
"Derrick Stolee via GitGitGadget" writes:
> + SECOND_SMALLEST_SIZE=$(ls -l .git/objects/pack/*pack | awk
> "{print \$5;}" | sort -n | head -n 2 | tail -n 1) &&
awk is capable of remembering $5 from each line of input, sorting
them and picking the second smallest element from it, isn
Duy Nguyen writes:
> Although we could make it clear by saying "5 paths updated, 2 deleted"
> (but that may make us say "3 paths added" as well, hmm). Or maybe just
> "%d paths updated" where updates include file creation and deletion.
Yeah, the last one is the simplest and good.
Am 12.12.18 um 01:42 schrieb Steven Penny:
On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
- pc-windows
- pc-win
- win
I find all of those horrible.
one windows triplet in use is "x86_64-pc-windows", used by Rust:
https://forge.rust-lang.org/other-installation-methods.html
which
Thomas Gummerer writes:
> I think I got the right solution for that in patch 5, with deleting
> the file if it's deleted in "their" version and we pass --theirs to
> 'git checkout', and analogous for --ours. I was just wondering if
> there were any further edge cases that I can't think of right
Tejun Heo writes:
> Some trailers refer to other commits. Let's call them xrefs
> (cross-references). For example, a cherry pick trailer points to the
> source commit. It is sometimes useful to build a reverse map of these
> xrefs - ie. source -> cherry-pick instead of cherry-pick -> source.
>
Hello,
I've got confusing behavior and the cause was somewhat hard to discover:
-- 8< --
$ git status
On branch linux
Your branch is ahead of 'vendor/jps2rin_arm' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
$ git push
Everything up-to-date
On Tue, Dec 11, 2018 at 3:28 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> + if (ce->ce_flags & CE_WT_REMOVE) {
> >> + if (topath)
> >> + BUG("Can't remove entry to a path");
> >> + unlink_entry(ce);
> >> + return 0;
>
Junio C Hamano writes:
> Sergey Organov writes:
>
>> When cherry-picking multiple commits, it's impossible to have both
>> merge- and non-merge commits on the same command-line. Not specifying
>> '-m 1' results in cherry-pick refusing to handle merge commits, while
>> specifying '-m 1' fails on n
On Fri, Dec 7, 2018 at 4:51 PM Steven Penny wrote:
>
> On Fri, Dec 7, 2018 at 11:04 AM wrote:
> > The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> > is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> > in the same way as it is done in 'Git for Win
Greetings,
I am running “git-repack -A -d -f -F --window=250 --depth=250” on a Git
repository converted using git-svn.
The repository contains more than 10 years of development, and a mixture of
source code and media assets. The size of the objects directory is around 50GB,
and there
On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
> I have no intention of flaming anybody. That is simply a
> misrepresentation.
you may see yourself "through a glass darkly", but i dont. this language is not
constructive:
> > - pc-windows
> > - pc-win
> > - win
>
> I find all of those
Currently, if support for running Git's entire test suite with protocol
v2 were added, some tests would fail because the fetch-pack CLI command
dies if it encounters protocol v2. To avoid this, teach fetch-pack
support for protocol v2.
Signed-off-by: Jonathan Tan
---
builtin/fetch-pack.c | 9 +++
Signed-off-by: Jonathan Tan
---
t/t5500-fetch-pack.sh| 13 +++--
t/t5616-partial-clone.sh | 3 +--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 9c18875c9c..a5a8f348a2 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t550
Signed-off-by: Jonathan Tan
---
t/t5539-fetch-http-shallow.sh | 12
t/t5541-http-push-smart.sh| 10 --
t/t5551-http-fetch-smart.sh | 23 +++
t/t5570-git-daemon.sh | 2 +-
4 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/t/t55
Thanks, Aevar for looking into this. I haven't looked into detail, but:
- s/where/var/ in your patch 1
- I think that variables should be unset with env --unset instead of
sane_unset, because (as far as I can tell) the effects of sane_unset
"leak" from test block to test block.
- On my co
Add an HTTP path to the test server config that returns an ERR pkt-line
unconditionally. Verify in t5551 that remote-curl properly detects this
ERR message and aborts.
Signed-off-by: Josh Steadmon
Signed-off-by: Jeff King
Signed-off-by: Junio C Hamano
---
t/lib-httpd.sh | 1 +
This is a reroll of js/smart-http-detect-remote-error that also includes
a fixed version of ms/proto-err-packet-anywhere [1].
The first patch clarifies the use of ERR messages in the pkt-line
protocol and unifies error handling in pkt-line.c
The second patch refactors smart-http discovery in remo
From: Masaya Suzuki
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.
Following t
From: Jeff King
After making initial contact with an http server, we have to decide if
the server supports smart-http, and if so, which version. Our rules are
a bit inconsistent:
1. For v0, we require that the content-type indicates a smart-http
response. We also require the response to l
From: Jeff King
In a v2 smart-http conversation, the server should reply to our initial
request with a pkt-line saying "version 2" (this is the start of the
"capabilities advertisement"). We check for the string using
starts_with(), but that's overly permissive (it would match "version
20", for e
From: Tejun Heo
Some trailers refer to other commits. Let's call them xrefs
(cross-references). For example, a cherry pick trailer points to the
source commit. It is sometimes useful to build a reverse map of these
xrefs - ie. source -> cherry-pick instead of cherry-pick -> source.
This patch
From: Tejun Heo
Add post-cherry-pick.sample and post-fetch.sample which, when enabled,
will keep refs/notes/xref-cherry-picks up-to-date as new cherry-picks
are created and fetched. Also, add tests to verify xref-cherry-picks.
Signed-off-by: Tejun Heo
---
Documentation/git-reverse-trailer-xre
From: Tejun Heo
Some trailers refer to other commits. Let's call them xrefs
(cross-references). For example, a cherry pick trailer points to the
source commit. It is sometimes useful to build a reverse map of these
xrefs - ie. source -> cherry-pick instead of cherry-pick -> source.
These reve
From: Tejun Heo
* post-cherry-pick: Called after a cherry-pick and given parameters so
that it can tell which are the new cherry-picks.
* post-fetch: Called after a fetch. Each updated ref and sha1 are fed
on stdin.
These two hooks will be used to keep refs/notes/xref-cherry-picks
up-to-da
From: Tejun Heo
Some trailers refer to other commits. Let's call them xrefs
(cross-references). For example, a cherry pick trailer points to the
source commit. It is sometimes useful to build a reverse map of these
xrefs - ie. source -> cherry-pick instead of cherry-pick -> source.
This patch
Hello,
Some trailers refer to other commits. Let's call them xrefs
(cross-references). For example, a cherry pick trailer points to the
source commit. It is sometimes useful to build a reverse map of these
xrefs - ie. source -> cherry-pick instead of cherry-pick -> source.
This, e.g, can answe
On 12/10, Elijah Newren wrote:
> On Sun, Dec 9, 2018 at 12:04 PM Thomas Gummerer wrote:
> >
> > Here's the series I mentioned a couple of times on the list already,
> > introducing a no-overlay mode in 'git checkout'. The inspiration for
> > this came from Junios message in [*1*].
> >
> > Basical
On 12/10, Duy Nguyen wrote:
> On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
> > @@ -302,15 +310,29 @@ static int checkout_paths(const struct checkout_opts
> > *opts,
> > ce->ce_flags &= ~CE_MATCHED;
> > if (!opts->ignore_skipworktree && ce_skip_worktree(ce)
On 12/10, Elijah Newren wrote:
> On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
> >
> > Currently when 'git checkout -- ...' is invoked with
> > multiple pathspecs, where one or more of the pathspecs don't match
> > anything, checkout errors out.
> >
> > This can be inconvenient in some ca
On 12/10, Duy Nguyen wrote:
> On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
> >
> > Currently when 'git checkout -- ...' is invoked with
> > multiple pathspecs, where one or more of the pathspecs don't match
> > anything, checkout errors out.
> >
> > This can be inconvenient in some cases,
On 12/10, Elijah Newren wrote:
> On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
> >
> > Add a new --cached option to git checkout, which works only on the
> > index, but not the working tree, similar to what 'git reset
> > -- ... does. Indeed the tests are adapted from the 'git
> > reset
On 12/11, Junio C Hamano wrote:
> Elijah Newren writes:
>
> >> Note that 'git checkout -p -- []' already works
> >> this way, so no changes are needed for the patch mode. We disallow
> >> 'git checkout --overlay -p' to avoid confusing users who would expect
> >> to be able to force overlay mode
On 12/10, Elijah Newren wrote:
> On Sun, Dec 9, 2018 at 12:05 PM Thomas Gummerer wrote:
> >
> > 'checkout_entry()' currently only supports creating new entries in the
> > working tree, but not deleting them. Add the ability to remove
> > entries at the same time if the entry is marked with the CE
On 12/10, Elijah Newren wrote:
> On Mon, Dec 10, 2018 at 8:09 AM Duy Nguyen wrote:
> >
> > On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
> > >
> > > When marking cache entries for removal, and later removing them all at
> > > once using 'remove_marked_cache_entries()', cache entries curre
On 12/10, Duy Nguyen wrote:
> On Sun, Dec 9, 2018 at 9:04 PM Thomas Gummerer wrote:
> >
> > The 'git worktree' command used to be just another mode in 'git
> > checkout', namely 'git checkout --to'. When the tests for the latter
> > were retrofitted for the former, the test name was adjusted, but
On Tue, Dec 11 2018, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Dec 11 2018, Jeff King wrote:
>
>> On Tue, Dec 11, 2018 at 12:45:16PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>>> > I don't know if there's a good solution. I tried running the whole
>>> > test suite with v2 as the default. I
On Tue, Dec 11 2018, Jeff King wrote:
> On Tue, Dec 11, 2018 at 12:45:16PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > I don't know if there's a good solution. I tried running the whole
>> > test suite with v2 as the default. It does find this bug, but it has
>> > a bunch of other pro
Mark those tests that have behavior differences or bugs under
protocol.version=0.
Whether or not these tests should exhibit different behavior is
outside the scope of this change. Some (such as t5700-protocol-v1.sh)
clearly should, but others (such as t7406-submodule-update.sh) might
indicate bugs
Add a GIT_TEST_PROTOCOL_VERSION=X test mode which is equivalent to
running with protocol.version=X. This is needed to spot regressions
and differences such as "ls-refs" behaving differently with
transfer.hideRefs. See
https://public-inbox.org/git/20181211104236.ga6...@sigill.intra.peff.net/
for a f
A few tests are broken under GIT_TEST_PROTOCOL_VERSION=1, which as
protocol.version in git-config(1) notes is just the
GIT_TEST_PROTOCOL_VERSION=0 with a version number.
All of these cases look OK to me, and don't seem to show any
regressions or other behavior differences that are unexpected. Thes
On Tue, Dec 11 2018, Carlo Arenas wrote:
> On Mon, Dec 10, 2018 at 12:24 AM Ævar Arnfjörð Bjarmason
> wrote:
>> On Mon, Dec 10 2018, brian m. carlson wrote:
>> > Considering that some Linux users use PaX kernels with standard
>> > distributions and that most BSD kernels can be custom-compiled w
Am 11.12.18 um 12:25 schrieb Johannes Schindelin:
On Mon, 10 Dec 2018, Johannes Sixt wrote:
diff --git a/compat/mingw.c b/compat/mingw.c
index 34b3880b29..4d009901d8 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -928,11 +928,19 @@ unsigned int sleep (unsigned int seconds)
char *mingw_mk
I noticed that our CI builds (see [1] for an example) were returning success
much faster than they did before Git v2.20.0. Turns out that there was a
test script failure involving the new test hash logic.
error: bug in the test script: bad hash algorithm
make[1]: *** [Makefile:56: t-basic.sh]
From: Derrick Stolee
The new test_oid machinery in the test library requires reading
some information from t/oid-info/hash-info and t/oid-info/oid.
The shell logic that reads from these files is sensitive to CRLF
line endings, causing a problem when the test suite is run on a
Windows machine that
> Jonathan Tan writes:
>
> > When a user runs "git commit" without specifying a message, an editor
> > appears with advice:
> >
> > Please enter the commit message for your changes. Lines starting
> > with '#' will be ignored, and an empty message aborts the commit.
> >
> > However, if th
On Mon, Dec 10, 2018 at 12:24 AM Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Dec 10 2018, brian m. carlson wrote:
> > Considering that some Linux users use PaX kernels with standard
> > distributions and that most BSD kernels can be custom-compiled with a
> > variety of options enabled or disabled, I
On Tue, Dec 11, 2018 at 7:12 AM Elijah Newren wrote:
>
> On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano wrote:
> >
> > Duy Nguyen writes:
> >
> > > Elijah wanted another mode (and I agree) that modifies worktree but
> > > leaves the index alone. This is most useful (or least confusing) when
> >
>
> Can you please replace the rather unnecessary, very, very long
> `win_path_utils_` function name prefix by the much better prefix `win32_`,
> to keep in line with the current, already existing, surrounding files'
> convention? Thanks a bunch.
>
That makes sense - thanks for the suggestion &
I just noticed that while `wsErrorHighlight = none` fixes the problem of extra
green codes for regular diff, it fails to have any effect during interactive
`git add -p`.
> On 2018-12-11, at 11:41 AM, George King wrote:
>
> I first started playing around with terminal colors about 5 years ago,
Hi everyone,
I am an Outreachy GIT Intern. I will be working on the project
"Improve git-bisect", with Christian Couder and Johannes Schindelin
as mentors.
You can read my blog here: http://tanu1596.blogspot.com/
I will be posting every one or two weeks about the ongoing work.
- Tanushree Tuman
On Tue, Dec 11, 2018 at 06:30:26PM +0100, Sebastian Gniazdowski wrote:
> Hello,
> I've attached a screenshot for running `git help -a' that ends in a
> hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
> attached):
>
> https://raw.githubusercontent.com/agostonbarna/dotfiles-base/
On Tue, Dec 11, 2018 at 6:42 PM Sebastian Gniazdowski
wrote:
>
> Hello,
> I've attached a screenshot for running `git help -a' that ends in a
> hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
> attached):
>
> https://raw.githubusercontent.com/agostonbarna/dotfiles-base/master/.
> It is amazing to me how much my perspective changed when I actually had to
> teach Git to new users. Things that I live with easily all of a sudden
> become these unnecessarily confusing road blocks that make it *so hard* to
> actually use Git.
I see. Without the -y patch, this series looks good
Hello,
I've attached a screenshot for running `git help -a' that ends in a
hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
attached):
https://raw.githubusercontent.com/agostonbarna/dotfiles-base/master/.gitconfig
So it's hangs on the alias `remote-origin-https-to-ssh'. One use
On 12/11/2018 9:15 AM, Konstantin Khomoutov wrote:
I think an uspoken issue here is that while you're indeed free to "fork"
this book and maintain your fork, having two books with almost identical
contents may not be the best option as it simply may be outright
confusing for those at whom you
On Tue, Dec 11, 2018 at 09:00:31AM -0800, Jon Forrest wrote:
> > As someone who's read neither your edit or the original edition, but I
> > did read your version of the intro, it would be very helpful to me /
> > others if there was some diff between the two so we could make up our
> > own mind ab
On 12/11/2018 7:13 AM, Ævar Arnfjörð Bjarmason wrote:
As someone who's read neither your edit or the original edition, but I
did read your version of the intro, it would be very helpful to me /
others if there was some diff between the two so we could make up our
own mind about which one to r
I came up with the idea of creating a global mailmap service earlier
this year and, given a recent discussion on maintaining .mailmap, I
decided to bring it up here. While only marginally related to Git
development, I hope that it is relevant enough to not be considered
spam.
The basic idea of the
I first started playing around with terminal colors about 5 years ago, and I
recall learning the hard way that Apple Terminal at least behaves very
strangely when you have background colors cross line boundaries: background
colors disappeared when I scrolled lines back into view. I filed a bug t
On Tue, Dec 11 2018, Jeff King wrote:
> On Mon, Dec 10, 2018 at 07:26:46PM -0800, Stefan Beller wrote:
>
>> > Context lines do have both. It's just that the default color for context
>> > lines is empty. ;)
>>
>> The content itself can contain color codes.
>>
>> Instead of unconditionally resett
Hi Dscho,
On Tue, Dec 11, 2018 at 2:14 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Mon, 10 Dec 2018, Elijah Newren wrote:
>
> > On Mon, Dec 10, 2018 at 1:18 PM Johannes Schindelin via GitGitGadget
> > wrote:
> > >
> > > @@ -1195,6 +1201,9 @@ int cmd_rebase(int argc, const char **argv, co
Ever since commit 3f213981e44a ("add tests for rebasing merged history",
2013-06-06), t3425 has had tests which included the rebasing of merged
history and whose order of applied commits was checked. Unfortunately,
the tests expected different behavior depending on which backend was in
use. Imple
As part of an ongoing effort to make rebase have more uniform behavior,
modify the merge backend to behave like the interactive one, by
re-implementing it on top of the latter.
Interactive rebases are implemented in terms of cherry-pick rather than
the merge-recursive builtin, but cherry-pick also
The git-legacy-rebase.sh script previously had code of the form:
if git_am_opt:
if interactive:
if incompatible_opts:
show_error_about_interactive_and_am_incompatibilities
if rebase-merge:
if incompatible_opts
show_error_about_merge_and_am_incompatibilities
which was a tri
The post-rewrite hook is documented as being invoked by commands that
rewrite commits such as commit --amend and rebase, and that it will
be called for each rewritten commit.
Apparently, the three backends handled --skip'ed commits differently:
am: treat the skipped commit as though it weren't r
In commit f57696802c30 ("rebase: really just passthru the `git am`
options", 2018-11-14), the handling of `git am` options was simplified
dramatically (and an option parsing bug was fixed), but it introduced
a small regression in the error message shown when options only
understood by separate back
While 'quiet' and 'interactive' may sound like antonyms, the interactive
machinery actually has logic that implements several
interactive_rebase=implied cases (--exec, --keep-empty, --rebase-merges)
which won't pop up an editor. The rewrite of interactive rebase in C
added a quiet option, though i
The conversion of the script version of rebase took messages that were
prefixed with "error:" and passed them along to die(), which adds a
"fatal:" prefix, thus resulting in messages of the form:
fatal: error: cannot combine...
which seems redundant. Remove the "error:" prefix from the builtin
This series continues the work of making rebase more self-consistent
by removing inconsistencies between different backends. In
particular, this series focuses on making the merge machinery behave
like the interactive machinery (though a few differences between the am
and interactive backends are
The post-rewrite hook is supposed to be invoked for each rewritten
commit. The fact that a commit was selected and processed by the rebase
operation (even though when we hit an error a user said it had no more
useful changes), suggests we should write an entry for it. In
particular, let's treat i
On Tue, Dec 11, 2018 at 3:13 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > The reason it's in parse_options_step() is because -h is also handled
> > in there. Although -h does not bury exit() deep in the call chain. So
> > how about this as a replacement?
>
> So just like -h returns PARSE
The compiler reports this because show_gitcomp() never actually
returns a value:
"parse-options.c", line 520: warning: Function has no return
statement : show_gitcomp
We could shut the compiler up. But instead let's not bury exit() too
deep. Do the same as internal -h handling, return a s
On Tue, Dec 11, 2018 at 4:02 PM Jon Forrest wrote:
> On 12/11/2018 2:50 AM, Jeff King wrote:
>
> > The content at https://git-scm.com/book is pulled regularly from
> > https://github.com/progit/progit2, which has collected a number of fixes
> > (as well as translations) since the 2nd edition was r
From: Johannes Schindelin
We take pains to determine the longest command beforehand, so that we
can align the category column after printing the command names.
However, then we re-use that value when printing the aliases. If any
alias name is longer than the longest command name, we consequently
The code added in 26c7d0678324 (help -a: improve and make --verbose default,
2018-09-29) that intends to print out aliases in addition to commands failed
to adjust for the length of the aliases. As a consequence, if there was any
alias whose name is longer than 18 characters, git help -a tried to p
From: Johannes Schindelin
We want a space after the `while` keyword.
Signed-off-by: Johannes Schindelin
---
help.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/help.h b/help.h
index 9eab6a3f89..a141e209ae 100644
--- a/help.h
+++ b/help.h
@@ -15,7 +15,7 @@ struct cmdnames
Hi Dscho and Slavica
On 11/12/2018 09:56, Johannes Schindelin wrote:
Hi Phillip,
[Cc:ing Slavica, the Outreachy intern working on converting `add -i` to a
built-in]
On Mon, 10 Dec 2018, Phillip Wood wrote:
On 09/12/2018 20:31, Johannes Schindelin wrote:
(which I take as being inspired
Peff & Stefan, thank you for the feedback. For my purposes, I am content to
rely on gitconfig to reduce the colors to something that I can parse without
losing information. Since my first email I have found that `wsErrorHighlight =
none` gets rid of the problematic extra green highlights in the
On 12/11/2018 2:50 AM, Jeff King wrote:
The content at https://git-scm.com/book is pulled regularly from
https://github.com/progit/progit2, which has collected a number of fixes
(as well as translations) since the 2nd edition was released.
Have you considered sending some of your edits there
On Tue, Dec 11, 2018 at 01:40:25PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> Are you thinking of the "break" command (not "pause") which Dscho
> >> already added[1]?
> >>
> >> [1]: 71f82465b1 (rebase -i: introduce the 'break' command, 2018-10-12)
> >
> > Yes, thanks (as you can see, I haven't act
On Tue, Dec 11, 2018 at 12:45:16PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I don't know if there's a good solution. I tried running the whole
> > test suite with v2 as the default. It does find this bug, but it has
> > a bunch of other problems (notably fetch-pack won't run as v2, bu
Hi Steven,
On Mon, 10 Dec 2018, Steven Penny wrote:
> On Mon, Dec 10, 2018 at 2:46 AM Johannes Schindelin wrote:
> > please stop dropping me from the Cc: list. Thanks.
>
> i dropped you specifically because i knew you were going to flame like
> you just did below. oh well, i guess you cant avoid
Hi Torsten,
On Tue, 11 Dec 2018, Torsten Bögershausen wrote:
> On Mon, Dec 10, 2018 at 09:32:03AM +0100, Johannes Schindelin wrote:
> >
> > On Sat, 8 Dec 2018, tbo...@web.de wrote:
> >
> > > And, before any cleanup is done, I sould like to ask if anybody
> > > can build the code with VS and con
On 12/10/2018 9:32 PM, Stefan Beller wrote:
On Mon, Dec 10, 2018 at 10:06 AM Derrick Stolee via GitGitGadget
wrote:
From: Derrick Stolee
To repack using a multi-pack-index, first sort all pack-files by
their modified time. Second, walk those pack-files from oldest
to newest, adding the packs
Johannes Schindelin writes:
> This breaks on Windows (on Windows, the error message says "cannot spawn", see
Thanks for a quick feedback. Let's update to look for the pathname
of the command, as Peff suggested earlier.
On 12/10/2018 8:54 PM, Stefan Beller wrote:
On Mon, Dec 10, 2018 at 10:06 AM Derrick Stolee via GitGitGadget
wrote:
From: Derrick Stolee
In an environment where the multi-pack-index is useful, it is due
to many pack-files and an inability to repack the object store
into a single pack-file. Ho
On Tue, Dec 11, 2018 at 06:09:19AM -0500, Jeff King wrote:
> On Sun, Dec 09, 2018 at 11:56:23PM +0100, SZEDER Gábor wrote:
>
> > 'test-lib.sh' looks for the presence of certain options like '--tee'
> > and '--verbose-log', so it can execute the test script again to save
> > its standard output and
On Sun, Dec 02 2018, Jeff King wrote:
> On Sat, Dec 01, 2018 at 09:28:47PM -0500, Eric Sunshine wrote:
>
>> On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote:
>> > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
>> > > In reality, I think that it would even make sense to chang
Hi Eric,
On Mon, 10 Dec 2018, Eric Sunshine wrote:
> On Mon, Dec 10, 2018 at 5:50 PM Silvio Fricke wrote:
> > HTTP has several protocol versions. By default, libcurl is using HTTP/2
> > today and check if the remote can use this protocol variant and fall
> > back to a previous version if not.
>
On 12/10/2018 8:59 PM, SZEDER Gábor wrote:
On Mon, Dec 10, 2018 at 05:35:28PM -0800, Stefan Beller wrote:
On Mon, Dec 10, 2018 at 10:06 AM Derrick Stolee via GitGitGadget
wrote:
+expire::
+ When given as the verb,
Can it be given in another way? Or rather "if the verb is expire",
then .
Hi Junio,
On Tue, 11 Dec 2018, Junio C Hamano wrote:
> diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
> index cf932c8514..9c83d44d9c 100755
> --- a/t/t0061-run-command.sh
> +++ b/t/t0061-run-command.sh
> @@ -13,11 +13,13 @@ cat >hello-script <<-EOF
> EOF
>
> test_expect_success
On Tue, Dec 11 2018, Jeff King wrote:
> When using the v2 protocol, hidden-ref config is not respected at all:
>
> $ git config transfer.hiderefs refs/tags/
> $ git -c protocol.version=0 ls-remote . | grep -c refs/tags
> 0
> $ git -c protocol.version=2 ls-remote . | grep -c refs/tags
>
Hi Hannes,
On Mon, 10 Dec 2018, Johannes Sixt wrote:
> > diff --git a/compat/mingw.c b/compat/mingw.c
> > index 34b3880b29..4d009901d8 100644
> > --- a/compat/mingw.c
> > +++ b/compat/mingw.c
> > @@ -928,11 +928,19 @@ unsigned int sleep (unsigned int seconds)
> > char *mingw_mktemp(char *templa
On Sun, Dec 09, 2018 at 11:56:21PM +0100, SZEDER Gábor wrote:
> This patch series tries to make reproducing rare failures in flaky
> tests easier: it adds the '--stress' option to our test library to run
> the test script repeatedly in multiple parallel jobs, in the hope that
> the increased load
On Sun, Dec 09, 2018 at 11:56:23PM +0100, SZEDER Gábor wrote:
> 'test-lib.sh' looks for the presence of certain options like '--tee'
> and '--verbose-log', so it can execute the test script again to save
> its standard output and error. This happens way before the actual
> option parsing loop, an
On Sun, Dec 09, 2018 at 11:56:22PM +0100, SZEDER Gábor wrote:
> Right now if a test script receives SIGTERM or SIGHUP (e.g., because a
> test was hanging and the user 'kill'-ed it or simply closed the
> terminal window the test was running in), the shell exits immediately.
> This can be annoying i
On Sun, Dec 09, 2018 at 09:51:28AM +0900, Junio C Hamano wrote:
> > -static int parse_commit_in_graph_one(struct commit_graph *g, struct commit
> > *item)
> > +static struct commit *parse_commit_in_graph_one(struct repository *r,
> > + struct commit_graph
On Sun, Dec 09, 2018 at 10:42:12AM -0800, Jon Forrest wrote:
> Several years ago I released what I called Pro Git Reedited. This was an
> attempt to tighten up the text of the excellent Pro Git book written by
> Scott Chacon. Since then, Scott and Ben Straub released the second
> edition of Pro Gi
1 - 100 of 116 matches
Mail list logo
