On Mon, 12 Nov 2018 at 13:31, Jeff King wrote:
> On Mon, Nov 12, 2018 at 12:47:42AM +0100, Mateusz Loskot wrote:
> >
> > TL;TR: Is this normal a repository migrated to Git LFS inflates multiple
> > times
> > and how to deal with it?
>
> That does sound odd to me. People with more LFS experience
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly ignore the unrecognized section,
but in the process they loudly warn
ignoring IEOT extension
resulting in confusion
Documentation/technical/index-format explains:
4-byte extension signature. If the first byte is 'A'..'Z' the
extension is optional and can be ignored.
This allows gracefully introducing a new index extension without
having to rely on all readers having support for it. Mandatory
> +index.recordOffsetTable::
> + Specifies whether the index file should include an "Index Entry
> + Offset Table" section. This reduces index load time on
> + multiprocessor machines but produces a message "ignoring IEOT
> + extension" when reading the index using Git versions
Jonathan Nieder writes:
> As with EOIE, popular versions of Git do not support the new IEOT
> extension yet. When accessing a Git repository written by a more
> modern version of Git, they correctly ignore the unrecognized section,
> but in the process they loudly warn
>
> ignoring IEOT
Dear
Good day. This is Kevin from Future Mould and Plastic Technology Co.,Ltd.
We supply plastic products for SUZUKI with high quality and competitive price.
For instance, Dashboard panel, Steering wheel cover, Control Panel, Air
conditioner outlet, Seat fitting, Cup holder, Gloves box, Rear
Stefan Beller writes:
>> + if (have_advertised_versions_already)
>> + BUG(_("attempting to register an allowed protocol version
>> after advertisement"));
>
> If this is a real BUG (due to wrong program flow) instead of bad user input,
> we would not want to burden the
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>>> On the other hand, for a file-scope static that is likely to stay as a
>>> non-API function but a local helper, it may not be worth it.
>>
>> Oh, do you think that `reset_head()` is likely to stay as non-API
>> function? I found myself
Jonathan Nieder writes:
> We almost obey that convention, but there is a problem: when
> encountering an unrecognized optional extension, we write
>
> ignoring FNCY extension
>
> to stderr, which alarms users.
Then the same comment as 2/3 applies to this step.
Junio C Hamano wrote:
> How about
>
> hint: ignoring an optional IEOT extension
>
> to make it clear that it is totally harmless?
>
> With that, we can add advise.unknownIndexExtension=false to turn all
> of them off with a single switch.
I like it. Expect a patch soon (tonight or
Jeff King writes:
>> I wonder if "The worktree at /local/src/wt1 has this branch checked
>> out" is something the user of %(worktree) atom, or a variant thereof
>> e.g. "%(worktree:detailed)", may want to learn, but because that
>> information is lost when this function returns, such an
Rafael Ascensão writes:
> But I can see where personal preference starts to play a role here, as
> the logical solution isn't good enough. Which makes the case for being
> able to configure a bit stronger.
Yeah, our preference over time has always been "do not add to our
default color palette
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When calling `merge` on a branch that has already been merged, that
> `merge` is skipped quietly, but currently a MERGE_HEAD file is being
> left behind and will then be grabbed by the next `pick` (that did
> not
stead...@google.com writes:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for server-side error
> messages, as well
stead...@google.com writes:
> When a smart HTTP server sends an error message via pkt-line,
> remote-curl will fail to detect the error (which usually results in
> incorrectly falling back to dumb-HTTP mode).
>
> This patch adds a check in discover_refs() for server-side error
> messages, as well
Hello ,
My name is Sgt Major John Dailey. I am here in Afghanistan , I came
upon a project I think we can work together on. I and my partner (1st
Lt. Daniel Farkas ) have the sum of $15 Million United State Dollars
which we got from a Crude Oil Deal in Iraq before he was killed by an
explosion
Jonathan Nieder writes:
> Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
> 2018-10-10) Git defaults to writing the new EOIE section when writing
> out an index file. Usually that is a good thing because it improves
> threaded performance, but when a Git repository is shared with
Johannes Schindelin writes:
>> On the other hand, for a file-scope static that is likely to stay as a
>> non-API function but a local helper, it may not be worth it.
>
> Oh, do you think that `reset_head()` is likely to stay as non-API
> function? I found myself in the need of repeating this
Rafael Ascensão writes:
> The documentation of `--exclude=` option from rev-list and rev-parse
> explicitly states that exclude patterns *should not* start with 'refs/'
> when used with `--branches`, `--tags` or `--remotes`.
>
> However, following this advice results in refereces not being
From: Johannes Schindelin
When we detect that a `merge` can be skipped because the merged commit
is already an ancestor of HEAD, we do not need to commit, therefore
writing the MERGE_HEAD file is useless.
It is actually worse than useless: a subsequent `git commit` will pick
it up and think
From: Johannes Schindelin
Every once in a while, the interactive rebase makes sure that no stale
files are lying around. These days, we need to include MERGE_HEAD into
that set of files, as the `merge` command will generate them.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 2 ++
1
I noticed a couple of weeks ago that I had bogus merge commits after my
rebases, where the original commits had been regular commits.
This set me out on the adventure that is reflected in this patch series.
Of course, the thing I wanted to fix is demonstrated by 1/5 and fixed in
2/5. But while
From: Johannes Schindelin
The scripted version of the rebase used to execute `git reset --hard`
when skipping or aborting. When we ported this to C, we did update the
worktree and some reflogs, but we failed to imitate `git reset --hard`'s
behavior regarding files in .git/ such as MERGE_HEAD.
From: Johannes Schindelin
Since `git rebase -r` was introduced, that is possible. But our
machinery did not think that possible, and failed to say anything about
the rebase in progress when in the middle of a merge.
Let's work around that in the minimal fashion.
Signed-off-by: Johannes
From: Johannes Schindelin
When calling `merge` on a branch that has already been merged, that
`merge` is skipped quietly, but currently a MERGE_HEAD file is being
left behind and will then be grabbed by the next `pick` (that did
not want to create a *merge* commit).
Demonstrate this.
Hi,
Ben Peart wrote:
> Ben Peart (6):
> read-cache: clean up casting and byte decoding
> eoie: add End of Index Entry (EOIE) extension
> config: add new index.threads config setting
> read-cache: load cache extensions on a worker thread
> ieot: add Index Entry Offset Table (IEOT)
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance, but when a Git repository is shared with older
versions of Git, it
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Every once in a while, the interactive rebase makes sure that no stale
> files are lying around. These days, we need to include MERGE_HEAD into
> that set of files, as the `merge` command will generate them.
>
>
stead...@google.com writes:
> OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in
> CFLAGS causes lots of build warnings. Using separate CXXFLAGS avoids
> this.
We are not a C++ shop, so allow me to show ignorance about how
projects that are OSS-Fuzz-enabled work. Do they use
On Sun, Nov 11, 2018 at 01:33:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
> The users who need protection against git deleting their files the most
> are exactly the sort of users who aren't expert-level enough to
> understand the nuances of how the semantics of .gitignore and "precious"
> are
Johan Herland writes:
> On Sun, Nov 11, 2018 at 10:49 AM Carlo Marcelo Arenas Belón
> wrote:
>>
>> 511726e4b1 ("builtin/notes: fix premature failure when trying to add
>> the empty blob", 2014-11-09) removed the check for !len but left a
>> call to free the buffer that will be otherwise NULL
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The scripted version of the rebase used to execute `git reset --hard`
> when skipping or aborting. When we ported this to C, we did update the
> worktree and some reflogs, but we failed to imitate `git reset
Jeff King writes:
>> You mean something like
>>
>> v->s = xstrfmt("%"PRIdMAX, (intmax_t)oi->disk_size);
>
> I think elsewhere we simply use PRIuMAX for printing large sizes via
> off_t; we know this value isn't going to be negative.
>
> I'm not opposed to PRIdMAX, which
stead...@google.com writes:
> Currently the client advertises that it supports the wire protocol
> version set in the protocol.version config. However, not all services
> support the same set of protocol versions. When connecting to
> git-receive-pack, the client automatically downgrades to v0 if
Fredi Fowler writes:
Here is a space for you to justify the change and sign off your
patch (see Documentation/SubmittingPatches).
> ---
> Subject: Re: [RFC PATCH] Using no- for options instead of duplication
Try to see if you can format the title in ": "
form first, please. I'll come back to
On Mon, Nov 12, 2018 at 3:41 AM Carlo Marcelo Arenas Belón
wrote:
> b968372279 ("read-cache: unlink old sharedindex files", 2017-03-06)
> introduced get_shared_index_expire_date using unsigned long to track
> the modification times of a shared index.
>
> dddbad728c ("timestamp_t: a new data type
On Mon, Nov 12, 2018 at 09:35:31AM +0800, yan ke wrote:
> > This would be awesome to handle issue directly with git:
> > Having an offline version of the issues synced to the gitlab/github issues.
> > A lot of work is done on the issues and it is lost when migrating
> > from one service to the
"Per Lundberg" wrote:
> On 11/11/18 5:41 PM, Duy Nguyen wrote:
> > On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason
> > wrote:
>
> >> That will lose no data, and in the very rare cases where a checkout of
> >> tracked files would overwrite an ignored pattern, we can just error out
> >>
Ævar Arnfjörð Bjarmason writes:
> What I'd add to your list is:
>
> * Some projects (I've seen this in the wild) add e.g. *.mp3 or whatever
> else usually doesn't belong in the repo as a "soft ignore". This is
> something we've never recommended, but have implicitly supported since
> the
On Sun, Nov 11, 2018 at 9:10 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 11 2018, Jeff King wrote:
>
> > On Sat, Nov 10, 2018 at 10:23:05PM -0800, Elijah Newren wrote:
> >
> >> ABORT and ERROR happen to have the same value, but come from differnt
> >> enums. Use the one from the correct
On Sun, Nov 11, 2018 at 11:50:00PM +0100, Martin Delille wrote:
> This would be awesome to handle issue directly with git: Having an
> offline version of the issues synced to the gitlab/github issues. A
> lot of work is done on the issues and it is lost when migrating from
> one service to the
Carlo Marcelo Arenas Belón writes:
> b968372279 ("read-cache: unlink old sharedindex files", 2017-03-06)
> introduced get_shared_index_expire_date using unsigned long to track
> the modification times of a shared index.
>
> dddbad728c ("timestamp_t: a new data type for timestamps", 2017-04-26)
when dddbad728c ("timestamp_t: a new data type for timestamps", 2017-04-26)
was introduced, the fallback to use approxidate that was introduced in
14ac2864dc ("commit: accept more date formats for "--date"", 2014-05-01)
was not updated to use the new type instead of unsigned long.
Signed-off-by:
b968372279 ("read-cache: unlink old sharedindex files", 2017-03-06)
introduced get_shared_index_expire_date using unsigned long to track
the modification times of a shared index.
dddbad728c ("timestamp_t: a new data type for timestamps", 2017-04-26)
shows why that might problematic so move to
specially problematic in Windows where unsigned long is only 32bit wide
and therefore the assumption that a time_t would fit will lead to loss
of precision in a 64bit OS.
builtin/commit.c | 4 ++--
read-cache.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
nbelakov...@gmail.com writes:
> diff --git a/color.h b/color.h
> index 98894d6a17..857653df73 100644
> --- a/color.h
> +++ b/color.h
> @@ -42,6 +42,24 @@ struct strbuf;
> #define GIT_COLOR_FAINT_BLUE "\033[2;34m"
> #define GIT_COLOR_FAINT_MAGENTA "\033[2;35m"
> #define
Hi Peff,
On Fri, 9 Nov 2018, Jeff King wrote:
> On Fri, Nov 09, 2018 at 06:21:41PM +0100, Johannes Schindelin wrote:
>
> > Actually, you got me thinking about the desc.buffer. And I think there is
> > one corner case where it could cause a problem: `struct tree_desc desc[2]`
> > does not
Torsten Bögershausen writes:
> Thanks, is there a chance to kill a typo here ?
> s/comopared/compared/
> - A temporally variable "size" is used, promoted int uintmax_t and the
> comopared
Done. Thanks.
On Mon, Nov 12 2018, Konstantin Khomoutov wrote:
> On Mon, Nov 12, 2018 at 09:35:31AM +0800, yan ke wrote:
>
>> > This would be awesome to handle issue directly with git:
>> > Having an offline version of the issues synced to the gitlab/github issues.
>> > A lot of work is done on the issues
nbelakov...@gmail.com writes:
>
> +static int worktree_head_atom_parser(const struct ref_format *format,
> + struct
> used_atom *atom,
> + const
> char
On 11/10/18 06:46, Nguyễn Thái Ngọc Duy wrote:
> Commit 43662b23ab (format-patch: keep cover-letter diffstat wrapped in
> 72 columns - 2018-01-24) uncondtionally sets stat width to 72 when
> generating diffstat for the cover letter, ignoring --stat from command
> line. But it should only do so
There are still some more possible improvements around this code but
they are orthogonal to this change :
* migrate to approxidate_careful or parse_expiry_date
* maybe make sure only approxidate are used for expiration
Changes in v2:
* improved commit message as suggested by Eric
* failsafe
On Sun, Nov 11, 2018 at 09:10:17PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > This is a good argument for naming these SIGNED_TAG_ABORT, etc. But this
> > is obviously an improvement in the meantime.
>
> In C enum values aren't the types of the enum, but I'd thought someone
> would have added a
From: Johannes Schindelin
Currently, we only accept the flag indicating whether the HEAD should be
detached not. In the next commit, we want to introduce another flag: to
toggle between emulating `reset --hard` vs `checkout -q`.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 9
In our tests with large repositories, we noticed a serious regression of the
performance of git rebase when using the built-in vs the shell script
version. It boils down to an incorrect conversion of a git checkout -q:
instead of using a twoway_merge as git checkout does, we used a oneway_merge
From: Johannes Schindelin
The same clean-up code is repeated quite a few times; Let's DRY up the
code some.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/builtin/rebase.c
From: Johannes Schindelin
When we converted a `git checkout -q $onto^0` call to use
`reset_head()`, we inadvertently incurred a change from a twoway_merge
to a oneway_merge, as if we wanted a `git reset --hard` instead.
This has performance ramifications under certain, though, as the
On Sun, Nov 11, 2018 at 11:16:50AM +0100, Torsten Bögershausen wrote:
> > I like the overall direction. I feel a little funny doing this step now,
> > and not as part of a series to convert individual variables. But I
> > cannot offhand think of any reason that it would behave badly even if
> >
On Mon, Nov 12 2018, Jeff King wrote:
> On Mon, Nov 12, 2018 at 12:47:42AM +0100, Mateusz Loskot wrote:
>
>> Hi,
>>
>> I'm posting here for the first time and I hope it's the right place to ask
>> questions about Git LFS.
>>
>> TL;TR: Is this normal a repository migrated to Git LFS inflates
On Sun, Nov 11, 2018 at 12:44:47AM -0800, Elijah Newren wrote:
> > > These patches were driven by the needs of git-repo-filter[1], but most
> > > if not all of them should be independently useful.
> >
> > I left lots of comments. Some of the earlier ones may just be showing my
> > confusion about
On Mon, Nov 12, 2018 at 01:03:25PM +0100, Johannes Schindelin wrote:
> > oi.disk_size is off_t; do we know "long long"
> >
> >(1) is available widely enough (I think it is from c99)?
> >
> >(2) is sufficiently wide so that we can safely cast off_t to?
> >
> >(3) will stay to be
Hi,
On Fri, 2 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Move a 37 line for-loop mess out of "install" and into a helper
> script. This started out fairly innocent but over the years has grown
> into a hard-to-maintain monster, and my recent ad874608d8 ("Makefile:
> optionally symlink
On Sun, Nov 11, 2018 at 03:58:30PM -0800, nbelakov...@gmail.com wrote:
> From: Nickolai Belakovski
>
> Add an atom expressing whether the particular ref is checked out in a
> linked worktree.
>
> Signed-off-by: Nickolai Belakovski
> ---
> ref-filter.c | 31
On Sun, Nov 11, 2018 at 12:42:58AM -0800, Elijah Newren wrote:
> > > fast-export output is traditionally used as an input to a fast-import
> > > program, but it is also useful to help gather statistics about the
> > > history of a repository (particularly when --no-data is also passed).
> > > For
Hi,
Thank you very much!
The git-bug project is what I'm looking for even if it is not very interesting
without gitlab connection.
There is an issue about it on Gitlab:
https://gitlab.com/gitlab-org/gitlab-ce/issues/50435
Maybe some encouragment from git core developer would help!
I also
By setting the GIT_TEST_INSTALLED variable to the path of an installed Git
executable, it is possible to run the test suite also on a specific
installed version (as opposed to a version built from scratch).
The only thing this needs that is unlikely to be installed is the test
helper(s).
From: Johannes Schindelin
It makes very, very little sense to test the built git-sh-i18n when the
user asked specifically to test another one.
Signed-off-by: Johannes Schindelin
---
t/lib-gettext.sh | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/t/lib-gettext.sh
From: Johannes Schindelin
It really makes very, very little sense to use a different git
executable than the one the caller indicated via setting the environment
variable GIT_TEST_INSTALLED.
Signed-off-by: Johannes Schindelin
---
t/test-lib-functions.sh | 3 ++-
1 file changed, 2
From: Johannes Schindelin
In the bin-wrappers/* scripts, we already take pains to use `git.exe`
rather than `git`, as this could pick up the wrong thing on Windows
(i.e. if there exists a `git` file or directory in the build directory).
Now we do the same in the tests' start-up code.
This also
From: Johannes Schindelin
We really need to be able to find the test helpers... Really. This
change was forgotten when we moved the test helpers into t/helper/
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Mon, Nov 12, 2018 at 07:20:28PM +0900, Junio C Hamano wrote:
> nbelakov...@gmail.com writes:
>
> > diff --git a/color.h b/color.h
> > index 98894d6a17..857653df73 100644
> > --- a/color.h
> > +++ b/color.h
> > @@ -42,6 +42,24 @@ struct strbuf;
> > #define GIT_COLOR_FAINT_BLUE
On Sun, Nov 11, 2018 at 12:32:22AM -0800, Elijah Newren wrote:
> > > Documentation/git-fast-export.txt | 7 +++
> > > builtin/fast-export.c | 20 +++-
> > > fast-import.c | 17 +
> > > t/t9350-fast-export.sh| 17
Hi Junio,
On Mon, 12 Nov 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> > static int reset_head(struct object_id *oid, const char *action,
> >> > - const char *switch_to_branch, int detach_head,
> >> > + const char *switch_to_branch,
Hi Carlo,
On Mon, 12 Nov 2018, Carlo Marcelo Arenas Belón wrote:
> specially problematic in Windows where unsigned long is only 32bit wide
> and therefore the assumption that a time_t would fit will lead to loss
> of precision in a 64bit OS.
Both patches look correct to me.
Thanks!
Dscho
>
>
On Mon, Nov 12, 2018 at 07:11:23PM +0900, Junio C Hamano wrote:
> > + }
> > +
> > + string_list_sort(>u.worktree_heads);
> > +
> > + free_worktrees(worktrees);
> > + return 0;
> > +}
>
> So..., this function collects any and all branches that are checked
> out in some worktree, and sort
On Sat, Nov 10, 2018 at 11:38:45PM -0800, Elijah Newren wrote:
> > Hmm. That's the right thing to do if we're considering the export to be
> > an independent unit. But what if I'm just rewriting a portion of history
> > like:
> >
> > git fast-export HEAD~5..HEAD | some_filter | git fast-import
On Mon, Nov 12 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> What I'd add to your list is:
>>
>> * Some projects (I've seen this in the wild) add e.g. *.mp3 or whatever
>> else usually doesn't belong in the repo as a "soft ignore". This is
>> something we've never
While trying to set up some aliases for my own use, I found out that
--exclude with --branches behave differently depending if the latter
uses globs.
I tried to fix it making my 2nd contribution. :)
Cheers,
Rafael Ascensão (2):
refs: show --exclude failure with --branches/tags/remotes=glob
`--exclude` from rev-list and rev-parse fails to exclude references if
the next `--branches`, `--tags` or `--remotes` use the optional
inclusive glob because those options are implemented as particular cases
of `--glob=`, which itself requires that exclude patterns begin with
'refs/'.
But it
The documentation of `--exclude=` option from rev-list and rev-parse
explicitly states that exclude patterns *should not* start with 'refs/'
when used with `--branches`, `--tags` or `--remotes`.
However, following this advice results in refereces not being excluded
if the next `--branches`,
Hi Ævar,
On Fri, 2 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Back when git was initially written the likes of "git-add", "git-init"
> etc. were installed in the user's $PATH. A few years later everything,
> with a few exceptions like git-upload-pack and git-receive-pack, was
> expected to be
On Sun, Nov 11, 2018 at 12:01:43AM -0800, Elijah Newren wrote:
> > It does seem funny that the behavior for the earlier case (bounded
> > commits) and this case (skipping some commits) are different. Would you
> > ever want to keep walking backwards to find an ancestor in the earlier
> > case? Or
On Mon, Nov 12, 2018 at 02:03:20PM +0900, Junio C Hamano wrote:
> > + } else if (!strcmp(name, "objectsize")) {
> > v->value = oi->size;
> > v->s = xstrfmt("%lu", oi->size);
>
> This is not a suggestion but is a genuine question, but I wonder if
Hi,
On Mon, 12 Nov 2018, Junio C Hamano wrote:
> Olga Telezhnaya writes:
>
> > @@ -876,11 +882,13 @@ static void grab_common_values(struct atom_value
> > *val, int deref, struct expand_
> > name++;
> > if (!strcmp(name, "objecttype"))
> >
On Mon, Nov 12, 2018 at 12:47:42AM +0100, Mateusz Loskot wrote:
> Hi,
>
> I'm posting here for the first time and I hope it's the right place to ask
> questions about Git LFS.
>
> TL;TR: Is this normal a repository migrated to Git LFS inflates multiple times
> and how to deal with it?
That
Ævar Arnfjörð Bjarmason writes:
>> Or only selected "*.o" (vendor supplied binary blob) kept tracked
>> while everything else is built from the source.
>> ...
> But it also does get used for "mostly we don't want this file, but
> sometimes we do" use-case, so that's something we need to deal
Hi Ævar,
On Fri, 2 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> * GIT_TEST_INSTALLED breaks entirely under this, as early as the
>heuristic for "are we built?" being "do we have git-init in
>libexecdir?". I tried a bit to make this work, but there's a lot of
>dependencies there.
I
From: Johannes Schindelin
We really only need the test helpers in that case, but that is not what
we test for. So let's skip the test for now when we know that we want to
test an installed Git.
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1
Hi,
On Mon, 12 Nov 2018, Johannes Schindelin via GitGitGadget wrote:
> In our tests with large repositories, we noticed a serious regression of the
> performance of git rebase when using the built-in vs the shell script
> version. It boils down to an incorrect conversion of a git checkout -q:
>
On Sat, Nov 10, 2018 at 03:04:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
> d) As shown in the linked E-Mails of mine you sometimes pay a 2-3 second
>*fixed* cost even for a very small (think ~100-200 objects) push/fetch
>that would otherwise take milliseconds with Jeff's version of this
>
Here's the series I mentioned earlier in the thread to cache loose
objects when answering has_object_file(..., OBJECT_INFO_QUICK). For
those just joining us, this makes operations that look up a lot of
missing objects (like "index-pack" looking for collisions) faster. This
is mostly targeted at
On 11/12/2018 9:49 AM, Jeff King wrote:
When we generate loose file paths for the main object directory, the
caller provides a buffer to loose_object_path (formerly sha1_file_name).
The callers generally keep their own static buffer to avoid excessive
reallocations.
But for alternate
On Mon, Nov 12 2018, Jeff King wrote:
> In cases where we expect to ask has_sha1_file() about a lot of objects
> that we are not likely to have (e.g., during fetch negotiation), we
> already use OBJECT_INFO_QUICK to sacrifice accuracy (due to racing with
> a simultaneous write or repack) for
On 11/12/2018 9:54 AM, Jeff King wrote:
In cases where we expect to ask has_sha1_file() about a lot of objects
that we are not likely to have (e.g., during fetch negotiation), we
already use OBJECT_INFO_QUICK to sacrifice accuracy (due to racing with
a simultaneous write or repack) for speed (we
On Mon, Nov 12, 2018 at 05:01:02PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > There's some obvious hand-waving in the paragraphs above. I would love
> > it if somebody with an NFS system could do some before/after timings
> > with various numbers of loose objects, to get a sense of where the
> >
On Thu, Nov 08, 2018 at 11:20:47PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Just a comment on this from the series:
>
> Note that it is possible for this to actually be _slower_. We'll do a
> full readdir() to fill the cache, so if you have a very large number of
> loose objects and a
In preparation for unifying the handling of alt odb's and the normal
repo object directory, let's use a more neutral name. This patch is
purely mechanical, swapping the type name, and converting any variables
named "alt" to "odb". There should be no functional change, but it will
reduce the noise
The sha1_file_name() function is used to generate the path to a loose
object in the object directory. It doesn't make much sense for it to
append, since the the path we write may be absolute (i.e., you cannot
reliably build up a path with it). Because many callers use it with a
static buffer, they
Commit 024aa4696c (fetch-pack.c: use oidset to check existence of loose
object, 2018-03-14) added a cache to avoid calling stat() for a bunch of
loose objects we don't have.
Now that OBJECT_INFO_QUICK handles this caching itself, we can drop the
custom solution.
Note that this might perform
Hi Elijah,
On Wed, 7 Nov 2018, Elijah Newren wrote:
> 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
1 - 100 of 167 matches
Mail list logo
