Our object_directory struct has a loose objects cache that all users of
the struct can see. But the only one that knows how to load the cache is
find_short_object_filename(). Let's extract that logic in to a reusable
function.
While we're at it, let's also reset the cache when we re-read the
Our handling of alternate object directories is needlessly different
from the main object directory. As a result, many places in the code
basically look like this:
do_something(r->objects->objdir);
for (odb = r->objects->alt_odb_list; odb; odb = odb->next)
do_something(odb->path);
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 directories, each struct carries its own scratch
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
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 run-command API makes no promises about what is left in a struct
child_process after a command finishes, and it's not safe to simply
reuse it again for a similar command. In particular:
- if you use child->args or child->env_array, they are cleared after
finish_command()
- likewise,
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
Using strip_suffix() lets us avoid repeating ourselves. It also makes
the handling of "/" a bit less subtle (we strip one less character than
we matched in order to leave it in place, but we can just as easily
include the "/" when we add more path components).
Signed-off-by: Jeff King
---
On Mon, Nov 12 2018, Johannes Schindelin wrote:
> 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
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
>
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
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:
>
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
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
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
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
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
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
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).
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
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
`--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`,
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
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
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
Æ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
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 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
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
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, 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
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 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 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
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 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 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 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
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
>
>
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"))
> >
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
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,
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
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
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)
Æ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 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
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
nbelakov...@gmail.com writes:
>
> +static int worktree_head_atom_parser(const struct ref_format *format,
> + struct
> used_atom *atom,
> + const
> char
"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
> >>
On Mon, Nov 12 2018, Matthieu Moy wrote:
> "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
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
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
On Thu, Nov 01 2018, Elijah Newren wrote:
> On Wed, Oct 31, 2018 at 12:16 PM Lars Schneider
> wrote:
>> > On Sep 24, 2018, at 7:24 PM, Elijah Newren wrote:
>> > On Sun, Sep 23, 2018 at 6:08 AM Lars Schneider
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I recently had to purge files from large
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 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
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
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(-)
Good day to you!
Here is the soa up to MAY 2018
Pls find the updated statement as attached for your checking.
Kindly confirm it and provide your payment schedule to us.
Looking forward to hear from you, thank you!
Kindly check and reply us as soon as possible!
Best Regards,
G.C. Solanki
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.
101 - 167 of 167 matches
Mail list logo
