Enabling pack.writebitmaphashcache should always be a performance win.
It costs only 4 bytes per object on disk, and the timings in ae4f07fbcc
(pack-bitmap: implement optional name_hash cache, 2013-12-21) show it
improving fetch and partial-bitmap clone times by 40-50%.
The only reason we didn't e
We use "jgit gc" to generate a pack bitmap file, and then make sure our
implementation can read it. To prepare the repo before running jgit, we
try to "rm -f" any existing bitmap files. But we got the path wrong;
we're in a bare repo, so looking in ".git/" finds nothing. Our "rm"
doesn't complain b
On Thu, Mar 14, 2019 at 12:02:56PM -0400, Jeff King wrote:
> On Thu, Mar 14, 2019 at 09:12:54AM +, Eric Wong wrote:
>
> > > The reason it defaults to off is for on-disk compatibility with JGit.
> >
> > Right. Our documentation seems to indicate JGit just warns (but
> > doesn't fall over), s
Since its inception, the perf-lib.sh script has manually handled the
"--tee" option (and other options which imply it, like "--valgrind")
with a cut-and-pasted block from test-lib.sh. That block has grown stale
over the years, and has at least three problems:
1. It uses $SHELL to re-exec the scr
On Tue, Mar 12, 2019 at 9:52 AM Elijah Newren wrote:
>
> On Tue, Mar 12, 2019 at 8:37 AM Eric Sunshine wrote:
> >
> > On Tue, Mar 12, 2019 at 8:19 AM Duy Nguyen wrote:
> > > On Tue, Mar 12, 2019 at 3:51 AM Phillip Wood
> > > wrote:
> > > > I tend to agree with this but that's probably because
Linus Torvalds writes:
> While it's true that header ordering isn't specified, there's a common
> "canonical" order that the headers are listed in. To quote rfc822:
> ...
> body must occur AFTER the headers. It is recommended
> that, if present, headers be sent in
Schönen Tag,
Sie benötigen einen echten Kredit online Ihre Rechnungen zu sichern?
Startet ein neues Unternehmen? Sie benötigen einen persönlichen Kredit
oder Business-Darlehen? Wir bieten ein Darlehen von € 10.000 bis €
500,000.000.00 mit 2% Zinsen pro Jahr und auch mit einem
erschwinglichen Rückz
On Thu, Mar 14, 2019 at 09:31:29PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > There's also been discussion about doing something (possibly in North
> > America) in the summer or fall of this year, but as far as I know there
> > hasn't been any planning so far.
>
> This is going off-topic, but I'd
On Thu, Mar 14, 2019 at 01:04:51PM +0100, Johannes Schindelin wrote:
> > One thing that I think submitGit can do that GGG cannot (yet), is just
> > take PRs straight on git/git. If we're going to start recommending it,
> > then I think we'd probably want to configure that, since it's one less
> >
On Thu, Mar 14, 2019 at 12:31:21PM +0100, Johannes Schindelin wrote:
> > Hmm. I guess it is still an issue in GGG. This thread has identical
> > timestamps on patches 1 and 2 (and my server received them out of order
> > by 2 seconds, so mutt orders them wrong):
> >
> > https://public-inbox.org
On Thu, Mar 14, 2019 at 04:25:04AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> @@ -714,6 +714,7 @@ int cmd_difftool(int argc, const char **argv, const char
> *prefix)
> "tool returns a non - zero exit code")),
> OPT_STRING('x', "extcmd", &extcmd,
On Thu, Mar 14, 2019 at 04:25:04AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> diff --git a/Documentation/technical/api-parse-options.txt
> b/Documentation/technical/api-parse-options.txt
> index 2b036d7838..2e2e7c10c6 100644
> --- a/Documentation/technical/api-parse-options.txt
> +++ b
On Thu, Mar 14, 2019 at 01:16:45PM +0100, Johannes Schindelin wrote:
> In other words, my take is that the ways in which `--no-index` is used are
> probably not very different from one another, and the bugs lurk in
> really rarely exercised code paths.
Yeah, that's more likely (and consistent wit
> It fixes not just this issue, but now the whole test suite passes with
> GIT_TEST_FSMONITOR, i.e. this test that's been failing for ~2 years also
> works now:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubli
> c-
> inbox.org%2Fgit%2F87k1vwn9qe.fsf%40evledraar.gmail.com%2F
On Sun, Mar 10, 2019 at 6:13 PM Eric Sunshine wrote:
>
> On Sun, Mar 10, 2019 at 4:09 AM Jonathan Chang wrote:
> > 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 t
On Mon, Mar 11, 2019 at 1:59 AM Thomas Gummerer wrote:
>
> On 03/10, Jonathan Chang wrote:
> > Hi,
> >
> > Thanks for the reviews.
> >
> > Here are the changes in the second version:
> > - bug fixes
> > - add preparatory patch
> > - seperate different files to different patch
> >
So Thomas Gleixner just figured out that the google gmail support for
S/MIME is even more broken than we initially thought, and has been
rejecting emails that have a non-canonical order of headers in the
email. In particular, gmail s/mime parsing hates emails generated with
"git format-patch --thre
On Thu, Mar 14 2019, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Mar 14 2019, Johannes Schindelin wrote:
>>
>> > On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> On Tue, Feb 26 2019, Thomas Gummerer wrote:
>> >>
>> >> >
Hi Ævar,
On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Mar 14 2019, Johannes Schindelin wrote:
>
> > On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
> >
> >> On Tue, Feb 26 2019, Thomas Gummerer wrote:
> >>
> >> > From: Joel Teichroeb
> >> >
> >> > Add a builtin helper for p
Running git 2.21.0 on Windows with certain invalid file names like
"c:\root.txt" (see https://github.com/jmandel/local-path-test as a
test case), I get an expected "invalid path" error when I clone the
repository.
But if I actually have a file at this path (i.e., outside of the git
working tree, a
Split up the corrupt_graph_and_verify() function added in
d9b9f8a6fd ("commit-graph: verify catches corrupt signature",
2018-06-27) into its logical components of setting up the test itself,
doing the corruption in a particular way with "dd", and then finally
testing that stderr is what we expect.
When the commit-graph is written we end up calling
parse_commit(). This will in turn invoke code that'll consult the
existing commit-graph about the commit, if the graph is corrupted we
die.
We thus get into a state where a failing "commit-graph verify" can't
be followed-up with a "commit-graph wr
When core.commitGraph=true is set, various common commands now consult
the commit graph. Because the commit-graph code is very trusting of
its input data, it's possibly to construct a graph that'll cause an
immediate segfault on e.g. "status" (and e.g. "log", "blame", ...). In
some other cases wher
Use the recently split-up components of the corrupt_graph_and_verify()
function to assert that we error on graphs that are too small. The
error was added in 2a2e32bdc5 ("commit-graph: implement git
commit-graph read", 2018-04-10), but there was no test for it.
Signed-off-by: Ævar Arnfjörð Bjarmaso
Change the error emitted when a commit-graph file is corrupt so that
we actually mention the commit-graph, e.g. change errors like:
error: improper chunk offset 00385e0c
To:
error: commit-graph improper chunk offset 00385e0c
As discussed in the commits leading up to this
An earlier change implemented load_commit_graph_one_fd_st() in a way
that was bug-compatible with earlier code in terms of the "graph file
%s is too small" error message printing out the path to the
commit-graph (".git/objects/info/commit-graph").
But change that, because:
* A function that take
Make the commit-graph loading code work as a library that returns an
error code instead of calling exit(1) when the commit-graph is
corrupt. This means that e.g. "status" will now report commit-graph
corruption as an "error: [...]" at the top of its output, but then
proceed to work normally.
This
Change "commit-graph verify" to error on open() failures other than
ENOENT. As noted in the third paragraph of 283e68c72f ("commit-graph:
add 'verify' subcommand", 2018-06-27) and the test it added it's
intentional that "commit-graph verify" doesn't error out when the file
doesn't exist.
But let's
See the v1 cover letter for details:
https://public-inbox.org/git/20190221223753.20070-1-ava...@gmail.com/
I'd forgotten this after 2.21 was released.
This addresses all the comments on v1 and rebases it. A range-diff is
below. I also improved 7/8's commit message a bit.
I fixed a test to avoid
Greetings
Can you please assist me to receive about 15 million Euros into your
personal account? . I will give you details as I hear from you.
Kindly send me the followings
Full Names
Address
Occupation
Direct Mobile Telephone Lines
Nationality
Regards,
Mr Ahmed Zama
On Wed, Mar 13 2019, Jeff King wrote:
> I took an informal poll at the last contributor summit in Brussels, but
> that obviously has some bias. So I'll ask here: do you have a location
> preference for a Git Merge conference (and associated contributor
> summit) next March?
>
> We're looking at
Hi Peff,
On Thu, 14 Mar 2019, Jeff King wrote:
> On Thu, Mar 14, 2019 at 02:17:18PM +0100, Johannes Schindelin wrote:
>
> > > 2. is there a way to cleanly avoid the three-line duplicate?
> > [...]
> > Peff tried with a function, but I think that this would actually be a
> > really appropriate o
On Thu, Mar 14, 2019 at 01:51:35PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Seeing "--stale-fix" again reminded me: that may be the "oops, we can
> > spend tons of CPU walking history" bit that I mentioned in the other
> > part of the thread. But I don't think git-gc would ever run
From: Phillip Wood
Spell out --no-rerere-autoupdate explictly to make searching
easier. This matches the other --no options in the man page.
Signed-off-by: Phillip Wood
---
Documentation/git-merge.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-merge
From: Phillip Wood
This option was missing from the man pages of these commands.
Signed-off-by: Phillip Wood
---
Documentation/git-am.txt | 5 +
Documentation/git-cherry-pick.txt | 5 +
Documentation/git-rebase.txt | 5 +
Documentation/git-revert.txt | 5 +
4
I've squashed the first tree patches together
Best Wishes
Phillip
On Thu, Mar 14, 2019 at 02:17:18PM +0100, Johannes Schindelin wrote:
> > 2. is there a way to cleanly avoid the three-line duplicate?
> [...]
> Peff tried with a function, but I think that this would actually be a
> really appropriate occasion for a well-placed `goto`:
I worried that a goto woul
On Thu, Mar 14, 2019 at 01:05:03PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'm not sure it's really worth addressing (just because I don't think
> > there's a good way to do it that isn't expensive).
>
> I do not think so, either. Not at this layer, anyway.
>
> If a "-x" comman
On Thu, 14 Mar 2019, Konstantin Ryabitsev wrote:
> On Wed, 13 Mar 2019 at 16:56, Jeff King wrote:
> > - preferences between Canada and US?
>
> If you're looking at Canada, East coast is generally more affordable
> than West Coast in terms of venues and accommodation. The three main
> tech hubs
Hi folks,
The main purpose of `git apply --check` is to see if a patch can apply.
It's not intuitive to a user, just from the command name, that "no
output" means your patch can apply cleanly.
Furthermore, `git apply --check --verbose` only says that it is
checking the patch, ending with "..." w
On Wed, 13 Mar 2019 at 16:56, Jeff King wrote:
> - preferences between Canada and US?
If you're looking at Canada, East coast is generally more affordable
than West Coast in terms of venues and accommodation. The three main
tech hubs in the East are Toronto, Montreal and Halifax.
Toronto pros:
On Thu, Mar 14, 2019 at 12:21:00PM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > +test_atexit () {
> > + # We cannot detect when we are in a subshell in general, but by
> > + # doing so on Bash is better than nothing (the test will
> > + # silently pass on other shells).
> > +
Hello,
I believe I've encountered a bug regarding the use of double asterisk
( /**/ ) within includeIf patterns.
git-config man pages state that
**/ and /**, that can match multiple path components
They then refer to the gitignore man pages which further define
supported wildcard patterns:
Hi all,
Sorry to bother one last time. After a bit more digging, I found that the
problem was with my workflow.
Shallow clones set `remote.origin.fetch` to one branch, so what I was doing in
the past was overriding the respository-specific `remote.origin.fetch` with my
global config.
I've now ch
On 3/13/2019 4:55 PM, Jeff King wrote:
> We're looking at doing it in North America, but there are two specific
> questions:
>
> - is there preference between East Coast vs West Coast?
I have no preference here.
> - preferences between Canada and US?
There should be serious consideration fo
Hi,
On Thu, 14 Mar 2019, Elijah Newren wrote:
> On Wed, Mar 13, 2019 at 1:58 PM Jeff King wrote:
> >
> > I took an informal poll at the last contributor summit in Brussels, but
> > that obviously has some bias. So I'll ask here: do you have a location
> > preference for a Git Merge conference (a
On Wed, Mar 13, 2019 at 1:58 PM Jeff King wrote:
>
> I took an informal poll at the last contributor summit in Brussels, but
> that obviously has some bias. So I'll ask here: do you have a location
> preference for a Git Merge conference (and associated contributor
> summit) next March?
>
> We're
On Thu, Mar 14, 2019 at 09:12:54AM +, Eric Wong wrote:
> > The reason it defaults to off is for on-disk compatibility with JGit.
>
> Right. Our documentation seems to indicate JGit just warns (but
> doesn't fall over), so maybe that can be considered separately.
I think it was a hard error
On Thu, Mar 14, 2019 at 12:23 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> I think sometimes a 3-way merge creates marker conflicts in file, and
> >> this does not look easy to reverse when switching back. If it's true
> >> and we can detect it, we can still abort this case (i.e. req
On Thu, Mar 14 2019, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
>> On Tue, Feb 26 2019, Thomas Gummerer wrote:
>>
>> > From: Joel Teichroeb
>> >
>> > Add a builtin helper for performing stash commands. Converting
>> > all at once proved hard
From: Johannes Schindelin
Signed-off-by: Johannes Schindelin
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index f91062718d..79a046d748 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -3641,7 +3641,6 @@ static int pick_commits(struct
From: Johannes Schindelin
The interactive rebase simply complains about an "invalid line" when the
object hash of, say, a `pick` line could not be parsed.
Let's tell the user what happened in a little more detail.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 3 ++-
1 file changed, 2 i
From: Johannes Schindelin
It is quite possible that the loose object cache gets stale when new
objects are written. Or that a new pack was installed. In those cases,
get_oid() would potentially say that it cannot find a given object, even
if it should find it.
Let's blow away the loose object ca
From: Johannes Schindelin
We specifically support `exec` commands in `git rebase -i`'s todo lists
to rewrite the very same todo list. Of course, we need to validate that
todo list when re-reading it.
It is also totally legitimate to extend the todo list by `pick` lines
using short names of commi
Being rather a power user of the interactive rebase, I discovered recently
that one of my scripts ran into an odd problem where an interactive rebase
appended new commands to the todo list, and the interactive rebase failed to
validate the (short) OIDs. But when I tried to fix things via git rebase
On Thu, Mar 14 2019, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
>> Remove the rebase.useBuiltin setting, which was added as an escape
>> hatch to disable the builtin version of rebase first released with Git
>> 2.20.
>>
>> See [1] for the init
Hi Ævar,
On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Feb 26 2019, Thomas Gummerer wrote:
>
> > From: Joel Teichroeb
> >
> > Add a builtin helper for performing stash commands. Converting
> > all at once proved hard to review, so starting with just apply
> > lets conversion get
On Thu, Mar 14, 2019 at 12:28:35PM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
> I see most of these changes are removal of stop_httpd because it is
> done as part of start_httpd() to arrange it to be called at exit.
>
> But ...
>
> > @@ -176,7 +175,7 @@ prepare_httpd() {
> > start_htt
When a2d5156c2b (resolve_gitlink_ref: ignore non-repository paths,
2016-01-22) added this test, the purpose was to check the 'ls-files
-o' didn't die() when processing the bogus repository. The expected
output didn't even need to be adjusted for the addition because the
bogus repository is treated
When the path given to 'git submodule add' is an existing repository
that is not in the index, the repository is passed to 'git add'. If
this repository doesn't have any commits, we don't get a useful
result: there is no subproject OID to track, and any untracked files
in the sub-repository are ad
When the working tree contains a repository with no commits, it's
treated as an empty directory, not a repository:
$ git init
$ git init no-commit && touch no-commit/untracked
$ git init with-commit && touch with-commit/untracked
$ git -C with-commit commit --allow-empty -mmsg
a2d5156c2b (resolve_gitlink_ref: ignore non-repository paths,
2016-01-22) added a test to t3000-ls-files-others.sh to check that
'ls-files -o' does not die() when given a subdirectory that looks like
a repository but is actually a subdirectory containing a bogus .git
file.
Move this test to a sepa
When treat_directory() encounters a directory that is not in the index
and DIR_NO_GITLINKS is unset, it calls resolve_gitlink_ref() to decide
if a directory looks like a repository, in which case the directory
won't be traversed. As a result, 'status -uall' and 'ls-files -o'
will show only the dir
Hi Ævar,
On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
> Remove the rebase.useBuiltin setting, which was added as an escape
> hatch to disable the builtin version of rebase first released with Git
> 2.20.
>
> See [1] for the initial implementation of rebase.useBuiltin, and [2]
> and [3] fo
On Thu, Mar 14, 2019 at 11:18:41AM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > Putting these together, when a test script run with 'dash' and
> > '--verbose-log -x' is interrupted, then 'dash' tries to write the
> > trace output from the EXIT trap to the script's original standard
>
On Thu, Mar 14, 2019 at 7:06 PM Johannes Schindelin
wrote:
> If this is truly something we ("we" as in "engaged Git developers") want,
> I can set aside some time to work on that. I had originally planned on
> exactly that, i.e. supporting PRs on git/git, but I got rather strong
> indications that
On Thu, Mar 14, 2019 at 2:18 AM Duy Nguyen wrote:
>
> On Tue, Mar 12, 2019 at 01:28:35PM -0400, Eric Sunshine wrote:
> > > > Again, not much of a datapoint, but I do use --orphan periodically.
> > > > The idea of "fixing" the behavior so that --orphan starts with a clean
> > > > slate is certainly
Hi Josh,
On Wed, 13 Mar 2019, Josh Steadmon wrote:
> Persistently enabling trace2 output is difficult because it requires
> specifying a full filename. This series teaches tr2_dst_get_trace_fd()
> to randomize filenames when a directory or filename prefix are given as
> targets in the GIT_TR2_* e
On Thu, Mar 14, 2019 at 9:10 PM Johannes Schindelin
wrote:
> In any case, before we get better tooling to work around these issues, I
> still think it makes a ton of sense to encourage proper separation of
> concerns: to keep patches that introduce regression tests demonstrating a
> breakage separ
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
> > +-f::
> > +--force::
> > + Proceed even if the index or the working tree differs from
> > + HEAD. Both the index and working tree are restored to match
> > + the switching target. This is used to throw away local
> > + changes
Hi Junio,
On Thu, 14 Mar 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > And it is especially nice that you make it easy to verify that there
> > is a bug in the first place, by separating the concern of
> > demonstrating it from the concern to fix it.
>
> For a multi-patch ser
Signed-off-by: Christophe Coevoet
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 499e56f83d..715f388721 100644
--- a/contrib/completion/git-co
Remove the rebase.useBuiltin setting, which was added as an escape
hatch to disable the builtin version of rebase first released with Git
2.20.
See [1] for the initial implementation of rebase.useBuiltin, and [2]
and [3] for the documentation and corresponding
GIT_TEST_REBASE_USE_BUILTIN option.
On Tue, Feb 26 2019, Thomas Gummerer wrote:
> From: Joel Teichroeb
>
> Add a builtin helper for performing stash commands. Converting
> all at once proved hard to review, so starting with just apply
> lets conversion get started without the other commands being
> finished.
>
> The helper is bei
Hi Junio & Peff,
On Thu, 14 Mar 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > @@ -442,6 +442,18 @@ static enum get_oid_result get_short_oid(const char
> > *name, int len,
> > find_short_packed_object(&ds);
> > status = finish_object_disambiguation
Hi Hannes,
On Thu, 14 Mar 2019, Johannes Sixt wrote:
> Am 13.03.19 um 17:35 schrieb Jeff King:
> > On Wed, Mar 13, 2019 at 05:11:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> As a further improvement, is there a good reason for why we wouldn't
> >> pass something down to the oid machinery to sa
On Thu, Mar 14, 2019 at 6:02 PM Phillip Wood wrote:
>
> On 14/03/2019 09:17, Duy Nguyen wrote:
> > On Tue, Mar 12, 2019 at 01:28:35PM -0400, Eric Sunshine wrote:
> Again, not much of a datapoint, but I do use --orphan periodically.
> The idea of "fixing" the behavior so that --orphan sta
Hi Junio,
On Thu, 14 Mar 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > +test_expect_failure SHA1 'loose object cache vs re-reading todo list' '
> > + GIT_REBASE_TODO=.git/rebase-merge/git-rebase-todo &&
> > + export GIT_REBASE_TODO &&
> > + write_scr
During reflog expiry, the cmd_reflog_expire() function first iterates
over all reflogs in logs/*, and then one-by-one acquires the lock for
each one to expire its reflog by getting a *.lock file on the
corresponding loose ref[1] (even if the actual ref is packed).
This lock is needed, but what isn
When gc.reflogExpire and gc.reflogExpireUnreachable are set to "never"
and --stale-fix isn't in effect (covered by the first part of the "if"
statement being modified here) we can exit early without pointlessly
looping over all the reflogs.
Signed-off-by: Jeff King
Signed-off-by: Ævar Arnfjörð Bj
Checking gc_auto_threshold in too_many_loose_objects() was added in
17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.",
2007-09-17) when need_to_gc() itself was also reliant on
gc_auto_pack_limit before its early return:
gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0
When tha
Change a couple of tests that weren't using the helper to use it. This
makes the trailing "--unset" unnecessary.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t1410-reflog.sh | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
in
There's been a lot of changing of the hardcoded "40" values to
the_hash_algo->hexsz, but we've so far missed this one where we
hardcoded 38 for the loose object file length.
This is because a SHA-1 like abcde[...] gets turned into
objects/ab/cde[...]. There's no reason to suppose the same won't be
Change an idiom we're using to ensure that gc_before_repack() only
does work once (see 62aad1849f ("gc --auto: do not lock refs in the
background", 2014-05-25)) to be more obvious.
Nothing except this function cares about the "pack_refs" and
"prune_reflogs" variables, so let's not leave the reader
Addresse Peff's comments to v1. For a couple of patches I've faked up
his SOB where I copy/pasted a comment or code from a v1 comment
verbatim. Will see if he acks that.
The main change is a better commit message in the last patch (now
7/7), and 2x new "reflog" patches to make it early exit in add
Don't redundantly run "git reflog expire --all" when gc.reflogExpire
and gc.reflogExpireUnreachable are set to "never".
An earlier change taught "git reflog expire" itself to exit early
under this scenario, so in some sense this isn't strictly
necessary. Reasons to also do it here:
1) Similar to
Hi Peff,
On Wed, 13 Mar 2019, Jeff King wrote:
> On Wed, Mar 13, 2019 at 12:20:14PM -0700, Johannes Schindelin via
> GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > As far as this developer can tell, the conversion from a Perl script to
> > a built-in caused the regression in the d
Hi Peff,
On Tue, 12 Mar 2019, Jeff King wrote:
> One thing that I think submitGit can do that GGG cannot (yet), is just
> take PRs straight on git/git. If we're going to start recommending it,
> then I think we'd probably want to configure that, since it's one less
> confusing step for first-time
Grüße an dich mein lieber Freund,
Ich heiße Mariam Abdul und schreibe Ihnen diese Nachricht mit Tränen
in den Augen. Der anhaltende Bürgerkrieg in meinem Land Syrien hat
mein Leben so sehr beeinflusst. Ich habe meine Familie im letzten Jahr
verloren. Mein Vater war vor seinem Tod ein reicher Gesch
Hi Peff,
On Wed, 13 Mar 2019, Jeff King wrote:
> On Wed, Mar 13, 2019 at 03:39:09PM -0400, Jeff King wrote:
>
> > On Wed, Mar 13, 2019 at 10:49:22AM +0900, Junio C Hamano wrote:
> >
> > > Jeff King writes:
> > >
> > > > infrequent contributors. And there are a few reasons to prefer GGG:
> > >
It was reported in https://github.com/git-for-windows/git/issues/2123 that
git difftool --no-index fails to work outside worktrees, even if it should
work.
I fear this is a regression I introduced over two years ago (!) when I
converted the Perl script to C.
At least now that I know about the bu
From: Johannes Schindelin
As far as this developer can tell, the conversion from a Perl script to
a built-in caused the regression in the difftool that it no longer runs
outside of a Git worktree (with `--no-index`, of course).
It is a bit embarrassing that it took over two years after retiring
From: Johannes Schindelin
`OPT_ARGUMENT()` is intended to keep the specified long option in `argv`
and not to do anything else.
However, it would make a lot of sense for the caller to know whether
this option was seen at all or not. For example, we want to teach `git
difftool` to work outside of
From: Johannes Schindelin
We will always spawn something from `git difftool`, so we will always
have to set `GIT_DIR` and `GIT_WORK_TREE`.
Signed-off-by: Johannes Schindelin
---
builtin/difftool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/difftool.c b/builtin/difftool.c
index
On 14/03/2019 09:17, Duy Nguyen wrote:
> On Tue, Mar 12, 2019 at 01:28:35PM -0400, Eric Sunshine wrote:
Again, not much of a datapoint, but I do use --orphan periodically.
The idea of "fixing" the behavior so that --orphan starts with a clean
slate is certainly appealing (since it ma
On 12/03/2019 16:43, Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 4:06 AM Phillip Wood
> wrote:
>>
>> Hi Elijah
>>
>> On 11/03/2019 17:54, Elijah Newren wrote:
>>> A few other comments that I thought of while responding elsewhere in
>>> the thread that didn't make sense to include elsewhere...
On 12/03/2019 17:05, Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 4:58 AM Duy Nguyen wrote:
>> On Tue, Mar 12, 2019 at 12:25 AM Elijah Newren wrote:
>>> On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
wrote:
>
> On 08/03/2019 09:5
ping!
Does anyone has an idea?
Jakob
Am 08.03.19 um 10:31 schrieb Jakobus Schürz:
> Hi there!
>
> Im new to this list - so hello, hope I'm welcome.
>
>
> My problem is: I have a configuration for my bash saved on a private
> git-repo. Every time, i start bash, my .bashrc checks this repo out to
On Wed, Mar 13, 2019 at 01:28:33PM +0100, Alexander Shopov wrote:
> Signed-off-by: Alexander Shopov
Thanks, applied.
Paul.
On Wed, Mar 13, 2019 at 01:06:32PM +0100, Alexander Shopov wrote:
>
>
> Hello all,
> I am resending the update of Bulgarina translation of Gitk that I last sent
> here:
> on 4 of March: https://marc.info/?l=git&m=155169580131311&w=2
> Any idea why it is not getting merged? Perhaps I missed somet
1 - 100 of 103 matches
Mail list logo
