Junio C Hamano writes:
> Eric Sunshine writes:
>
>> On Tue, May 7, 2019 at 5:51 PM Johannes Schindelin via GitGitGadget
>> wrote:
>>> [...]
>>> Let's fix this by making sure that the Windows PID is written into
>>> `gc.pid` in this test script soo that `git.exe` is able to understand
I amended
"LI, BO XUAN" writes:
> Thanks for your review! I can understand your point, but I've got a
> quick question:
>
> What if format-patch really breaks and 'am' magically does not break?
Doesn't that indicate that you are not testing the result of "am"
adequately?
I am not saying it is *wrong* to
"Dr. Adam Nielsen" writes:
> + - A pattern that contains a non-trailing slash is matched
> + For example, `doc/frotz/` matches `doc/frotz` directory, but not
> + `a/doc/frotz` (relative from the `.gitignore` file).
> + Note that the pattern `doc/frotz` and `/doc/frotz` have the
> + same e
Ævar Arnfjörð Bjarmason writes:
> This is a WIP series I have that I figured I'd send out as-is for
> comment since Junio said he'd be merging dl/rebase-i-keep-base down.
>
> So I wanted to test it, and as seen early in this series in 3/13 and
> 4/13 we had significant blindspots in our tests, i
Eric Sunshine writes:
> On Tue, May 7, 2019 at 5:51 PM Johannes Schindelin via GitGitGadget
> wrote:
>> [...]
>> Let's fix this by making sure that the Windows PID is written into
>> `gc.pid` in this test script soo that `git.exe` is able to understand
>> that that process does indeed still exis
Emily Shaffer writes:
> +=== Clone the Git Repository
> +
> +Git is mirrored in a number of locations. Clone the repository from one of
> them;
> +https://git-scm.com/downloads suggests one of the best places to clone from
> is
> +the official mirror on GitHub.
I didn't want to have to get int
Emily Shaffer writes:
> - Removed 'extern' from the addition to builtin.h
I said something that conflicts with this in my message to JTan, but
I am fine with this removal of extern, as it is reasonable that
Denton Liu's no-extern work would land soonish.
I agree with the spirit of all the other
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>> This v3 is all Johannes's patches. The outstanding review on v2 could
>> be clarified with a commit message change, which I've addressed, and
>> v2 conflicted with a cache.h change that's since landed in "master",
>> which I've rebas
Stephen Boyd writes:
> Quoting Junio C Hamano (2019-05-06 21:38:24)
>> Stephen Boyd writes:
>>
>> > I wonder if we need to make some other sort of form of
>> > "prerequisite-patch-id:" here and let that be a legacy form of the
>> > patch-id so that users know that they have a fixed version of t
Jonathan Tan writes:
> Sorry for not looking at this sooner.
>
> Firstly, I'm not sure if this file should be named without the ".txt",
> like SubmittingPatches.
SubmittingPatches has historical baggage but this does not, so its
source can be left as .txt (alternatively we could have added .txt
Jeff King writes:
> I think this is reasonable, especially with the feature in patch 6 to
> tell the caller they're doing it wrong, instead of just silently
> producing nonsense results.
>
> Junio, if you haven't been following closely, this can replace my patch
> from jk/perf-installed-fix.
I d
Ævar Arnfjörð Bjarmason writes:
> This may just be more insanity to implement right now, but perhaps in
> addition to "gitdir:" etc. in the IncludeIf config syntax we'd want to
> aim for "HEADref" (or some saner name). I.e. allowing to include/enable
> arbitrary config based on the ref name.
>
>
"Dr. Adam Nielsen" writes:
> On 07.05.19 12:07, Junio C Hamano wrote:
>> "Dr. Adam Nielsen" writes:
>>
>>> gitignore.txt: make slash-rules more readable
>>>
>>> Make all paragraphs valid, even if they are not read
>>> in strict order. Make paragraph better understandable
>>> for pattern without
Fix a regression introduced in 4f21454b55 ("merge-base: handle
--fork-point without reflog", 2016-10-12).
Before that change having a linear history on top of an upstream
master would with --fork-point (aka argument-less rebase) tell us
there was nothing to be done:
$ git rebase
Current b
From: Denton Liu
Before, can_fast_forward was written with an if-else statement. However,
in the future, we may be adding more termination cases which would lead
to deeply nested if statements.
Refactor to use a goto tower so that future cases can be easily
inserted.
Signed-off-by: Denton Liu
Add tests rebasing a linear branch topology to linear rebase tests
added in 2aad7cace2 ("add simple tests of consistency across rebase
types", 2013-06-06).
These tests are duplicates of two surrounding tests that do the same
with tags pointing to the same objects. Right now there's no change in
be
From: Denton Liu
Before, when we had the following graph,
A---B---C (master)
\
D (side)
running 'git rebase --onto master... master side' would result in D
being always rebased, no matter what. However, the desired behavior is
that rebase should notice that th
From: Denton Liu
A common scenario is if a user is working on a topic branch and they
wish to make some changes to intermediate commits or autosquash, they
would run something such as
git rebase -i --onto master... master
in order to preserve the merge base. This is useful when contribu
From: Denton Liu
Before, when we rebased with a --fork-point invocation where the
fork-point wasn't empty, we would be setting options.restrict_revision.
The fast-forward logic would automatically declare that the rebase was
not fast-forwardable if it was set. However, this was painting with a
ve
The can_fast_forward() function is potentially much more expensive
than is_interactive() since it e.g. might need to call
is_linear_history().
So reversing the two looks like an obvious improvement, but doing so
reveals a previously hidden caveat: We need the can_fast_forward()
function to populat
This seems to work, needs more tests etc...
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/rebase.c | 6 ++
t/t3432-rebase-fast-forward.sh | 7 +--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 167d4fcf67..de1c
From: Denton Liu
When rebase is run on a branch that can be fast-forwarded, this should
automatically be done. Create test to ensure this behavior happens.
There are some cases that currently don't pass. The first case is where
a feature and master have diverged, running
"git rebase master... ma
The is_interactive() test gets tricky around --rebase-merges. Let's
split our use of it for the purposes of whether we should try
fast-forwarding a rebase into a utility function to prepare for adding
more logic to that specific codepath.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/rebase
Change "same head" introduced in the preceding commit to check whether
the rebase.c code lands in the can_fast_forward() case in, and thus
prints out an "is up to date" and aborts early.
In some of these cases we make it past that and to "rewinding head",
then do a rebase, only to find out there's
Add more stress tests for the can_fast_forward() case in
rebase.c. These tests are getting rather verbose, but now we can see
under --ff and --no-ff whether we skip work, or whether we're forced
to run the rebase.
These tests aren't supposed to endorse the status quo, just test for
what we're curr
This is a WIP series I have that I figured I'd send out as-is for
comment since Junio said he'd be merging dl/rebase-i-keep-base down.
So I wanted to test it, and as seen early in this series in 3/13 and
4/13 we had significant blindspots in our tests, i.e. there were no
tests for whether --no-ff
From: Denton Liu
Signed-off-by: Denton Liu
Signed-off-by: Junio C Hamano
---
t/t3431-rebase-fork-point.sh | 53
1 file changed, 53 insertions(+)
create mode 100755 t/t3431-rebase-fork-point.sh
diff --git a/t/t3431-rebase-fork-point.sh b/t/t3431-rebase-for
> +Add a line to `#include "config.h"`. Then, add the following bits to the
> +function body:
> +
> +
> + const char *cfg_name;
> +
> +...
> +
> + git_config(git_default_config, NULL)
> + if (git_config_get_string_const("user.name", &cfg_name) > 0) {
> + printf(_("No nam
The fread/fwrite-like functions in http.c, namely fread_buffer,
fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
multiplication of the size and number of items they are being given.
Practically speaking, it doesn't matter, because in all contexts where
those functions are used, size is
On 2019.05.07 18:30, Jeff King wrote:
> Just as we instruct Apache to pass through ASAN_OPTIONS (so that
> server-side Git programs it spawns will respect our options while
> running the tests), we should do the same with LSAN_OPTIONS. Otherwise
> trying to collect a list of leaks like:
>
> ex
Just as we instruct Apache to pass through ASAN_OPTIONS (so that
server-side Git programs it spawns will respect our options while
running the tests), we should do the same with LSAN_OPTIONS. Otherwise
trying to collect a list of leaks like:
export LSAN_OPTIONS=exitcode=0:log_path=/tmp/lsan
On Tue, May 07, 2019 at 11:49:41AM +0200, Ævar Arnfjörð Bjarmason wrote:
> I wonder in general if there's a more sustainable solution to these
> one-at-a-time memory leak fixes we're doing to these
> libraries. E.g. marking some tests in the test suite as passing cleanly
> with valgrind's leak che
On Tue, May 7, 2019 at 5:51 PM Johannes Schindelin via GitGitGadget
wrote:
> [...]
> Let's fix this by making sure that the Windows PID is written into
> `gc.pid` in this test script soo that `git.exe` is able to understand
> that that process does indeed still exist.
>
> Signed-off-by: Johannes S
> On 2019/05/07, at 11:34, Jonathan Tan wrote:
>
> To get an enumeration of available objects, don't you need to use only
> "blob:none"? Combining filters (once that's implemented) will get all
> objects only up to a certain depth.
>
> Combining "tree:" and "blob:none" would allow us to reduc
I saw this in one of my builds that followed the bleeding edge of Git for
Windows' SDK: git.exe has a different idea of the test script's PID than the
test script itself. Yet another of the quirks Git for Windows has to deal
with...
Johannes Schindelin (1):
t6500(mingw): use the Windows PID of t
From: Johannes Schindelin
In Git for Windows, we use the MSYS2 Bash which inherits a non-standard
PID model from Cygwin's POSIX emulation layer: every MSYS2 process has a
regular Windows PID, and in addition it has an MSYS2 PID (which
corresponds to a shadow process that emulates Unix-style signa
On Tue, May 07, 2019 at 04:58:32PM +0200, SZEDER Gábor wrote:
> On Wed, May 01, 2019 at 05:56:35PM +0900, Mike Hommey wrote:
> > The fread/fwrite-like functions in http.c, namely fread_buffer,
> > fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
> > multiplication of the size and number
Since v4, I've made one major change and a handful of minor changes. The
major change is contained entirely in patch 2/2; patch 1/2 has only nit
fixes compared to v4.
Major:
- I've added anchors to each section. These anchors are custom-named in
order to be compatible with asciidoc as well as as
This tutorial covers how to add a new command to Git and, in the
process, everything from cloning git/git to getting reviewed on the
mailing list. It's meant for new contributors to go through
interactively, learning the techniques generally used by the git/git
development community.
Reviewed-by:
During the course of review for MyFirstContribution.txt, the suggestion
came up to include anchors to make it easier for veteran contributors to
link specific sections of this documents to newbies. To make life easier
for reviewers, add these anchors in their own commit. See review context
here: ht
On Tue, May 07, 2019 at 12:54:28PM +0200, Ævar Arnfjörð Bjarmason wrote:
> So here as a 6-parter given some of the feedback on v2. Maybe Jeff
> still hates it :), but this time around some of the changes are split
> up and should be easier to understand in isolation, as well as some
> more "notice
On Tue, May 07, 2019 at 10:31:23AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I'm not sure I get what's going on here. Why do we need the realpath in
> > aggregate.perl? We'd want to generate the same filename that "run"
> > decided to store things in, which we'd generate from the command-line
> >
> On Mon, May 06, 2019 at 03:28:44PM -0700, Jonathan Tan wrote:
> > Sorry for not looking at this sooner.
> >
> > Firstly, I'm not sure if this file should be named without the ".txt",
> > like SubmittingPatches.
>
> I should mention that during this change's life as a GitGitGadget PR,
> dscho p
On 07/05/2019 17:07, Junio C Hamano wrote:
SZEDER Gábor writes:
This patch and the topic 'pw/rebase-abort-clean-rewritten' can't be
compiled on its own, because it starts using 'struct replay_opts'
here, which is defined in 'sequencer.h', but 'builtin/rebase.c'
doesn't include that header yet.
On Mon, May 06, 2019 at 03:28:44PM -0700, Jonathan Tan wrote:
> Sorry for not looking at this sooner.
>
> Firstly, I'm not sure if this file should be named without the ".txt",
> like SubmittingPatches.
I should mention that during this change's life as a GitGitGadget PR,
dscho performed a revie
On Thu, May 02, 2019 at 07:11:04PM -0700, Phil Hord wrote:
> On Tue, Apr 23, 2019 at 12:35 PM Emily Shaffer
> wrote:
> >
> > This tutorial covers how to add a new command to Git and, in the
> > process, everything from cloning git/git to getting reviewed on the
> > mailing list. It's meant for ne
> > My main question is: we can get the same list of objects (in the form of
> > tree objects) if we fetch with "blob:none" filter. Admittedly, we will
> > get extra data (file names, etc.) - if the extra bandwidth saving is
> > necessary, this should be called out. (And some of the savings will be
On Tue, May 07, 2019 at 05:36:56PM +0700, Duy Nguyen wrote:
> On Tue, May 7, 2019 at 9:21 AM Emily Shaffer wrote:
> > I've got a usability comment, as we're giving restore a try within
> > Google for now.
>
> Thanks. I thought I was the only guinea pig :D and obviously not a
> good one since I kn
Quoting Junio C Hamano (2019-05-06 21:38:24)
> Stephen Boyd writes:
>
> > I wonder if we need to make some other sort of form of
> > "prerequisite-patch-id:" here and let that be a legacy form of the
> > patch-id so that users know that they have a fixed version of this code?
> > Maybe "prerequis
On Tue, May 7, 2019 at 7:12 AM Robert Dailey wrote:
> On Mon, May 6, 2019 at 6:52 PM Ævar Arnfjörð Bjarmason
> wrote:
> The majority use case I'm interested in is seeing net-positive changes
> that happen in merge commits. Normally I take for granted that merge
> commits have nothing meaningful
SZEDER Gábor writes:
> This patch and the topic 'pw/rebase-abort-clean-rewritten' can't be
> compiled on its own, because it starts using 'struct replay_opts'
> here, which is defined in 'sequencer.h', but 'builtin/rebase.c'
> doesn't include that header yet. (Though 'pu' already builds fine,
>
On Tue, May 07 2019, Denton Liu wrote:
> On Wed, May 08, 2019 at 12:05:43AM +0900, Junio C Hamano wrote:
>> Denton Liu writes:
>
> [snip]
>
>> >
>> > Would you suggest moving to a format..* approach or would it
>> > make sense to rename the configs to something like
>> > branch..{emailCoverSubj
On Tue, May 07, 2019 at 10:58:49AM -0400, Denton Liu wrote:
> For more details, this code[2] just blindly diffs the first two
> endpoints returned preceding `repo_init_revisions`.
If you throw in more than two endpoints, the result is a combined diff
with respect to the first commit. You can have
On Tue, May 07 2019, Robert Dailey wrote:
> On Mon, May 6, 2019 at 6:52 PM Ævar Arnfjörð Bjarmason
> wrote:
>> Maybe an example helps, let's say you have two paint buckets, one with
>> red paint, one with yellow paint. You mix them. What happens?
>>
>> (
>> rm -rf /tmp/git &&
>>
On Wed, May 08, 2019 at 12:05:43AM +0900, Junio C Hamano wrote:
> Denton Liu writes:
[snip]
> >
> > Would you suggest moving to a format..* approach or would it
> > make sense to rename the configs to something like
> > branch..{emailCoverSubject,emailTo,emailCc}?
>
> So if I have to pick betwe
On Fri, Apr 26, 2019 at 11:32:12AM +0100, Phillip Wood wrote:
> From: Phillip Wood
>
> When `rebase -r` finishes it removes any refs under refs/rewritten
> that it has created. However if the rebase is aborted these refs are
> not removed. This can cause problems for future rebases. For example I
Denton Liu writes:
> I noticed that there are both `dl/rev-tilde-doc-clarify` and
> `dl/revisions-doc-update` branches. The latter comes from this patchset
> and is a complete replacement for the former.
Thanks for spotting. Will replace the former with the updated
patches.
Thanks.
On Wed, May 01, 2019 at 05:56:35PM +0900, Mike Hommey wrote:
> The fread/fwrite-like functions in http.c, namely fread_buffer,
> fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
> multiplication of the size and number of items they are being given.
>
> Practically speaking, it doesn't m
Hi Robert,
On Tue, May 07, 2019 at 09:10:12AM -0500, Robert Dailey wrote:
[snip]
> Even ignoring that issue, the more concerning observation of mine is
> that `diff @^!` produces any output at all. If you exclude both
> parents, why do I see a diff for parent 2 (I see the complete diff of
> the
Denton Liu writes:
> The reason why I chose to use branch..* is because format-patch
> currently reads from branch..description and I wanted to build on
> top of that. In addition, I didn't want to scatter branch-specific
> configs in two different place (i.e. have a branch..description
> alongsi
On Tue, May 7, 2019 at 9:10 AM Robert Dailey wrote:
> Your example is very helpful. I understand what you're saying for
> conflicted lines. But the "whatever the default merge resolution would
> have been" doesn't exist, because there's no reality where line 1 in
> color.txt can be something "auto
Hi Junio,
I noticed that there are both `dl/rev-tilde-doc-clarify` and
`dl/revisions-doc-update` branches. The latter comes from this patchset
and is a complete replacement for the former.
Thanks,
Denton
On Sun, May 05, 2019 at 12:06:54PM -0400, Denton Liu wrote:
> Thanks again for the comments
Hi Junio,
On Tue, May 07, 2019 at 05:56:00PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Currently, format-patch only accepts branch..description as a
> > branch-specific configuration variable. However, there are many other
> > options which would be useful to have on a branch-by-bra
On Mon, May 6, 2019 at 6:52 PM Ævar Arnfjörð Bjarmason wrote:
> Maybe an example helps, let's say you have two paint buckets, one with
> red paint, one with yellow paint. You mix them. What happens?
>
> (
> rm -rf /tmp/git &&
> git init /tmp/git &&
> cd /tmp/git &&
>
Hi Junio
On 05/05/2019 05:02, Junio C Hamano wrote:
Phillip Wood writes:
I've had a look at the rebase -i code and I think it only overwrites
ignored files when it is fast-forwarding. This matches what merge does
when fast-forwarding but I'm not convinced either of them should be
doing this b
Dustin Spicuzza writes:
> Yes, your interpretation is exactly correct, even the interpretation of
> the uncertainty of the message.
>
> I didn't send the patch to this list though, not sure why gitgitgadget
> decided to do so (I've never heard of it before now). The patch was
> originally submitt
Ævar Arnfjörð Bjarmason writes:
> This v3 is all Johannes's patches. The outstanding review on v2 could
> be clarified with a commit message change, which I've addressed, and
> v2 conflicted with a cache.h change that's since landed in "master",
> which I've rebased this on.
>
> Junio: We're get
Yes, your interpretation is exactly correct, even the interpretation of
the uncertainty of the message.
I didn't send the patch to this list though, not sure why gitgitgadget
decided to do so (I've never heard of it before now). The patch was
originally submitted to git for windows (PR #938), with
Hi Junio,
Thanks for your review! I can understand your point, but I've got a
quick question:
What if format-patch really breaks and 'am' magically does not break?
Then the two tests might still pass. On the contrary, with this patch,
we can verify the correctness of format-patch and safely rely
On Tue, May 7, 2019 at 10:43 AM Junio C Hamano wrote:
> -- >8 --
> Subject: t0040: protect lines that are indented by spaces
>
> This block is byte-for-byte identical expected output, that contains a
> few lines that are indented in many spaces, which makes "git diff --check"
> unhappy and will br
On Mon, May 06, 2019 at 07:43:34PM -0400, Jeff King wrote:
> Subject: [PATCH] coccicheck: optionally batch spatch invocations
>
> In our "make coccicheck" rule, we currently feed each source file to its
> own individual invocation of spatch. This has a few downsides:
>
> - it repeats any overhe
From: Johannes Schindelin
This one is tricky.
When `core.fsmonitor` is set, a `refresh_index()` will not perform a
full scan of files that might be modified, but will query the fsmonitor
and refresh only the ones that have been actually touched.
Due to implementation details, the fsmonitor is q
This v3 is all Johannes's patches. The outstanding review on v2 could
be clarified with a commit message change, which I've addressed, and
v2 conflicted with a cache.h change that's since landed in "master",
which I've rebased this on.
Junio: We're getting closer to the release so it would be grea
From: Johannes Schindelin
With this change, the `index_state` struct becomes the new home for the
flag that says whether the fsmonitor hook has been run, i.e. it is now
per-index.
It also gets re-set when the index is discarded, fixing the bug
demonstrated by the "test_expect_failure" test added
On Tue, May 7, 2019 at 5:02 PM Phillip Wood wrote:
> > My (biased, obviously) view is that "git reset --hard" is very
> > dangerous and I'm not trying to change that, especially when its
> > behavior has been like this since forever and I'm sure it's used in
> > scripts.
> >
> > Instead "git resto
Remove the setting of the "environment" from the --codespeed output. I
don't think this is useful, and it helps with a later refactoring
where we GIT_TEST_INSTALLED stop munging/reading GIT_TEST_INSTALLED in
the perf tests in so many places.
This was added in 05eb1c37ed ("perf/aggregate: implement
As noted in preceding commits setting GIT_TEST_INSTALLED has never
been supported or documented, and as noted in an earlier t/perf/README
change to the extent that it's been documented nobody's notices that
the example hasn't worked since 3c8f12c96c ("test-lib: reorder and
include GIT-BUILD-OPTIONS
So here as a 6-parter given some of the feedback on v2. Maybe Jeff
still hates it :), but this time around some of the changes are split
up and should be easier to understand in isolation, as well as some
more "noticed while I was at it" things fixed.
This series ends with outright forbidding the
Follow-up my preceding change which fixed the immediate "./run
" regression in 0baf78e7bc ("perf-lib.sh: rely on
test-lib.sh for --tee handling", 2019-03-15) and entirely get rid of
GIT_TEST_INSTALLED from perf-lib.sh (and aggregate.perl).
As noted in that change the dance we're doing with GIT_TES
Change the output file names in test-results/ to be
"test-results/bindir_" rather than just
"test-results/".
This is for consistency with the "build_" directories we have for
built revisions, i.e. "test-results/build_".
There's no user-visible functional changes here, it just makes it
easier to s
Since 3c8f12c96c ("test-lib: reorder and include GIT-BUILD-OPTIONS a
lot earlier", 2012-06-24) the suggested advice of overriding
GIT_BUILD_DIR has not worked. We've printed a hard error like this
given e.g. GIT_BUILD_DIR=/home/avar/g/git:
/bin-wrappers/git is not executable; using GIT_EXEC_PA
Fix a really bad regression in 0baf78e7bc ("perf-lib.sh: rely on
test-lib.sh for --tee handling", 2019-03-15). Since that change all
runs of different of git have used the git found in the
user's $PATH, e.g. /usr/bin/git instead of the we just
built and wanted to performance test.
The problem st
Yes, exactly. When squashing or fixup-ing commits via rebase I really
want "git log" to show the date and time of the rebase operation and
not the date and time of the commit I rebased onto, which could be
months or even years in the past. I once worked on a project where
part of the code-base hadn
I assume you and your family are in good health. I am the Foreign
operations Manager at one of the leading generation bank here in West
Africa.
In my bank; there resides an overdue and unclaimed sum of $15.5m, when
the account holder suddenly passed on, he left no beneficiary who
would be entitled
gitignore.txt: make slash-rules more readable
Make all paragraphs valid, even if they are not read
in strict order. Make paragraph better understandable
for pattern without slash. Add paragraph for pattern
with slash. Be precise whenever a trailing slashes
would make a difference. Add some example
On Tue, May 7, 2019 at 9:21 AM Emily Shaffer wrote:
> I've got a usability comment, as we're giving restore a try within
> Google for now.
Thanks. I thought I was the only guinea pig :D and obviously not a
good one since I know too much (which is not a good thing as a
tester).
> I found myself i
On 07.05.19 12:07, Junio C Hamano wrote:
"Dr. Adam Nielsen" writes:
gitignore.txt: make slash-rules more readable
Make all paragraphs valid, even if they are not read
in strict order. Make paragraph better understandable
for pattern without slash. Add paragraph for pattern
with slash. Be p
On Tue, May 7, 2019 at 6:43 AM Jeff King wrote:
>
> On Mon, May 06, 2019 at 04:34:09PM +0700, Duy Nguyen wrote:
>
> > > However, it comes at a cost. The RSS of each spatch process goes from
> > > ~50MB to ~1500MB (and peak memory usage may be even higher if make runs
> >
> > 1.5G should be fine. T
"Dr. Adam Nielsen" writes:
> gitignore.txt: make slash-rules more readable
>
> Make all paragraphs valid, even if they are not read
> in strict order. Make paragraph better understandable
> for pattern without slash. Add paragraph for pattern
> with slash. Be precise whenever a trailing slashes
On 02/05/2019 11:53, Duy Nguyen wrote:
On Wed, May 1, 2019 at 9:58 PM Phillip Wood wrote:
On 01/05/2019 11:31, Duy Nguyen wrote:
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
From: Phillip Wood
These two patches teach read-tree how to avoid overwriting untracked
files when doing '--r
This is a complete line. We're not expecting the next function to add
anything to the same line.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/submodule--helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index
On Mon, May 06 2019, Josh Steadmon wrote:
> Free the commit graph when verify_commit_graph_lite() reports an error.
> Credit to OSS-Fuzz for finding this leak.
>
> Signed-off-by: Josh Steadmon
> ---
> commit-graph.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/co
Johannes Schindelin writes:
> Hi Junio,
>
> gentle ping: this patch was not picked up yet, although it should be
> pretty uncontroversial.
Thanks. It does look it fell through the cracks without sound.
Will pick it up.
"Dustin Spicuzza via GitGitGadget" writes:
> From: Dustin Spicuzza
>
> When using cvsnt + msys + git, it seems like the output of cvs status
> had \r\n in it, and caused the command to fail.
This is a bit under-explained in that it does not make it clear
where the right place to fix would be.
Boxuan Li writes:
> The exit code of the upstream in a pipe is ignored thus we should avoid
> using it. By writing out the output of the git command to a file, we can
> test the exit codes of both the commands.
We are trying to catch breakages in "am" in these two tests (see the
title of the tes
Denton Liu writes:
> Currently, format-patch only accepts branch..description as a
> branch-specific configuration variable. However, there are many other
> options which would be useful to have on a branch-by-branch basis,
> namely cover letter subject and To: and Cc: headers.
>
> Teach format-p
On Tue, May 07 2019, Jeff King wrote:
> On Tue, May 07, 2019 at 01:23:09AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> @@ -79,7 +95,16 @@ run_dirs_helper () {
>> if test $# -gt 0 -a "$1" = --; then
>> shift
>> fi
>> -if [ ! -d "$mydir" ]; then
>> +
>> +PERF_RESULTS_
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Much of the multi-pack-index code focuses on the multi_pack_index
> struct, and so we only pass a pointer to the current one. However,
> we will insert a dependency on the packed_git linked list in a
> future change, so we will
On Tue, May 07 2019, Jeff King wrote:
> On Sat, May 04, 2019 at 08:52:01AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > Note that Ævar's case was somebody running bitmaps locally and trying to
>> > push, which I think is generally not a good match for bitmaps (even when
>> > they work, they cost
On Mon, May 06, 2019 at 11:44:06AM +0200, Ævar Arnfjörð Bjarmason wrote:
> Maybe there's some case I haven't thought of that makes this stupid, but
> I wonder if something like a "gc quarantine" might be a fix fo both of
> the the issues you noted above.
>
> I.e. it seems to me that the main issu
1 - 100 of 107 matches
Mail list logo
