On Fri, Jan 05, 2018 at 11:46:24AM -0500, Jeff Hostetler wrote:
> > I'm mildly negative on this "level 2" config. If influencing the
> > porcelain via config creates compatibility headaches, then why would we
> > allow it here? And if it doesn't, then why do we need to protect against
> > it? This
Hi,
Brief description:
When two tags are pointing to the same commit, e.g. tagA and tagB, if I do `git
checkout tagA` then `git checkout tagB`, and then `git status`, it shows `HEAD
detached at tagA`
Expected behaviour:
I'm expecting it to show `HEAD detached at tagB`, though I understand this
Enable Git to resolve its own binary location using a variety of
OS-specific and generic methods, including:
- procfs via "/proc/self/exe" (Linux)
- _NSGetExecutablePath (Darwin)
- KERN_PROC_PATHNAME sysctl on BSDs.
- argv0, if absolute (all, including Windows).
This is used to enable RUNTIME_PRE
(Send #2, since I failed to CC everyone in the first posting).
This patch set expands support for the RUNTIME_PREFIX configuration flag,
currently only used on Windows builds, to include Linux, Darwin, and
FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its
ancillary paths rela
Currently, the generated Perl script headers are emitted by commands in
the Makefile. This mechanism restricts options to introduce alternative
header content, needed by Perl runtime prefix support, and obscures the
origin of the Perl script header.
Change the Makefile to generate a header by proc
Add a new Makefile flag, RUNTIME_PREFIX_PERL, which, when enabled,
configures Perl scripts to locate the Git installation's Perl support
libraries by resolving against the script's path, rather than
hard-coding that path at build-time.
Enabling RUNTIME_PREFIX_PERL overrides the system-specific Per
On 1/7/2018 5:42 PM, Ævar Arnfjörð Bjarmason wrote:
On Sun, Jan 07 2018, Derrick Stolee jotted:
git log --oneline --raw --parents
Num Packs | Before MIDX | After MIDX | Rel % | 1 pack %
--+-+++--
1 | 35.64 s |35.28 s | -1
Hi,
On Fri, Jan 5, 2018 at 12:18 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Fri, 5 Jan 2018, Matthieu Moy wrote:
>
>> If we go for it, we need:
>>
>> * Admins
>>
>> * Potential mentors
>
> Count me in as a potential mentor.
I am ok to be admin and mentor.
>> * List of microproject and project
c3a9ad3117 ("oidset: add iterator methods to oidset", 2017-11-21)
introduced a 'oidset_init()' function in oidset.h, which has void as
return type, but returns an expression.
This makes the solaris compiler fail with:
"oidset.h", line 30: void function cannot return value
As the return type
On Sun, Jan 07 2018, Derrick Stolee jotted:
> git log --oneline --raw --parents
>
> Num Packs | Before MIDX | After MIDX | Rel % | 1 pack %
> --+-+++--
> 1 | 35.64 s |35.28 s | -1.0% | -1.0%
>24 | 90.81 s |40.
Thanks Brandon and Lars for comments on the previous round.
Previous rounds were at <20171210212202.28231-1-t.gumme...@gmail.com>
and <20171217225122.28941-1-t.gumme...@gmail.com>.
Changes since the previous round:
- reworked the patches to no longer try to use struct repository for
worktrees,
read_index_from() takes a path argument for the location of the index
file. For reading the shared index in split index mode however it just
ignores that path argument, and reads it from the gitdir of the current
repository.
This works as long as an index in the_repository is read. Once that
cha
Split index mode only has a few dedicated tests, but as the index is
involved in nearly every git operation, this doesn't quite cover all the
ways repositories with split index can break. To use split index mode
throughout the test suite a GIT_TEST_SPLIT_INDEX environment variable
can be set, whic
In a96d3cc3f6 ("cache-tree: reject entries with null sha1", 2017-04-21)
we made sure that broken cache entries do not get propagated to new
trees. Part of that was making sure not to re-use an existing cache
tree that includes a null oid.
It did so by dropping the cache tree in 'do_write_index()'
On Sun, Jan 07, 2018 at 03:57:59PM -0500, Randall S. Becker wrote:
> I'm looking for a proper (i.e. not sneaky) way to detect the platform I am
> on during testing so that some tests can be modified/skipped other than
> using the standard set of dependencies. In particular, the maximum path on
> cu
Hi All,
I'm looking for a proper (i.e. not sneaky) way to detect the platform I am
on during testing so that some tests can be modified/skipped other than
using the standard set of dependencies. In particular, the maximum path on
current NonStop platforms is 8-bit 2048 bytes. It appears that there
On 01/04, Thomas Gummerer wrote:
> On 12/18, Lars Schneider wrote:
> > [snip]
> > For now I think that looks good. Maybe we could define additional test
> > configurations with an environment variable. That could be an array variable
> > defined in the lib-travis.ci "case" statement:
> > https://g
The write_midx_file() method takes a list of packfiles and indexed
objects with offset information and writes according to the format
in Documentation/technical/pack-format.txt. The chunks are separated
into methods.
Signed-off-by: Derrick Stolee
---
Makefile | 1 +
midx.c | 412
Commentary: As we extend the function of the midx builtin, I expand the
SYNOPSIS row of "git-midx.txt" but do not create multiple rows. If this
builtin doesn't change too much, I will rewrite the SYNOPSIS to be multi-
lined, such as in "git-branch.txt".
-- >8 --
Create, document, and implement th
There may be multiple MIDX files in a single pack directory. The primary
file is pointed to by a pointer file "midx-head" that contains an OID.
The MIDX file to load is then given by "midx-.midx".
This head file will be especially important when the MIDX files are
extended to be incremental and we
As we write new MIDX files, the existing files are probably not needed. Supply
the "--delete-expired" flag to remove these files during the "--write" sub-
command.
Signed-off-by: Derrick Stolee
---
Documentation/git-midx.txt | 4
builtin/midx.c | 15 ++-
midx.c
When writing a new MIDX file, it is faster to use an existing MIDX file
to load the object list and pack offsets and to only inspect pack-indexes
for packs not already covered by the MIDX file.
Signed-off-by: Derrick Stolee
---
builtin/midx.c | 34 +++---
midx.c
The MIDX file stores pack offset information for a list of objects. The
nth_midxed_object_* methods provide ways to extract this information.
Signed-off-by: Derrick Stolee
---
midx.c | 55 +++
midx.h | 15 +++
2 files changed, 70 in
Test interactions between the midx builtin and other Git operations.
Use both a full repo and a bare repo to ensure the pack directory
redirection works correctly.
Signed-off-by: Derrick Stolee
---
t/t5318-midx.sh | 100
1 file changed, 1
Using a binary search, we can navigate to the position n within a
MIDX file where an object appears in the ordered list of objects.
Signed-off-by: Derrick Stolee
---
midx.c | 30 ++
midx.h | 9 +
2 files changed, 39 insertions(+)
diff --git a/midx.c b/midx.c
Create unique_in_midx() to mimic behavior of unique_in_pack().
Create find_abbrev_len_for_midx() to mimic behavior of
find_abbrev_len_for_pack().
Consume these methods when interacting with abbreviations.
Signed-off-by: Derrick Stolee
---
sha1_name.c | 70 ++
Commentary: I included the pack directory of the MIDX file as a FLEX_ARRAY
at the end of the midxed_git struct, similar to how the pack name appears
at the end of the packed_git struct. A colleague mentioned this pattern is
confusing and possibly dangerous so I should consider changing it. If there
When looking for a packed object, first check the MIDX for that object.
This reduces thrashing in the MRU list of packfiles.
Signed-off-by: Derrick Stolee
---
midx.c | 84 ++
midx.h | 3 +++
packfile.c | 5 +++-
3 files change
As a way to troubleshoot unforeseen problems with MIDX files, provide
a way to delete "midx-head" and the MIDX it references.
Signed-off-by: Derrick Stolee
---
Documentation/git-midx.txt | 12 +++-
builtin/midx.c | 31 ++-
t/t5318-midx.sh
The MIDX files contain a complete object count, so we can report the number
of objects in the MIDX. The count remains approximate as there may be overlap
between the packfiles not referenced by the MIDX.
Signed-off-by: Derrick Stolee
---
packfile.c | 8 ++--
1 file changed, 6 insertions(+),
Perform some basic read-only operations that load objects and find
abbreviations. As this functionality begins to reference MIDX files,
ensure the output matches when using MIDX files and when not using them.
Signed-off-by: Derrick Stolee
---
t/t5318-midx.sh | 31 +++
Replace prepare_packed_git() with prepare_packed_git_internal(use_midx) to
allow some consumers of prepare_packed_git() with a way to load MIDX files.
Consumers should only use the new method if they are prepared to use the
midxed_git struct alongside the packed_git struct.
If a packfile is found
As the multi-pack-index feature is being developed, we use a config
setting 'core.midx' to enable all use of MIDX files.
Since MIDX files are designed as a way to augment the existing data
stores in Git, turning this setting off will revert to previous
behavior without needing to downgrade. This c
Commentary: This file format uses the large offsets from the pack-index
version 2 format, but drops the CRC32 hashes from that format.
Also: I included the HASH footer at the end only because it is already in
the pack and pack-index formats, but not because it is particularly useful
here. If possi
This RFC includes a new way to index the objects in multiple packs
using one file, called the multi-pack index (MIDX).
The commits are split into parts as follows:
[01] - A full design document.
[02] - The full file format for MIDX files.
[03] - Creation of core.midx config setting.
[04-12] -
A multi-pack-index (MIDX) file indexes the objects in multiple
packfiles in a single pack directory. After a simple fixed-size
header, the version 1 file format uses chunks to specify
different regions of the data that correspond to different types
of data, including:
- List of OIDs in lex-order
-
This patch set expands support for the RUNTIME_PREFIX configuration flag,
currently only used on Windows builds, to include Linux, Darwin, and
FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its
ancillary paths relative to the runtime location of its executable
rather than hard-
On 24/12/17 11:52, Mark Nauwelaerts wrote:
From: Mark Nauwelaerts
When using fast-export/fast-import to interface/bridge with another VCS
that explicitly tracks copy/rename as metadata, fast-export's ability
to report filecopy/filerename is quite useful (if not essential).
There has been a fix
On 27.12.2017 22:44, Junio C Hamano wrote:
Ivan Pozdeev writes:
Not sure if I should add a CVE-2009-0037 reference as well.
Not in an end-user facing message like this one, I would say.
To me, as an end user, the current message had no meaning at all. It
even sounds like I'm better off for
--
Hello dear, My name is Ruth, i am 26yrs old, i'm a free minded,open
hearted girl,i'm one of the few that still believes in friendship, love,
trust and signs, am very much single and ready to mingle. i will like to
be your friend if you don't mind, i hope you will not take my request
for g
I recently made two changes to nearby lines (approx. 3 lines b/w them)
in a file and wanted to stash one part of it and not the other. I tried
to use "git stash -p" for this. I split the hunk of concern (of course,
they came out as a single hunk) and gave 'y' for one and 'n' for the
other. The stas
On Thu, Jan 4, 2018 at 3:49 AM, Ævar Arnfjörð Bjarmason
wrote:
> From: Nguyễn Thái Ngọc Duy
>
> A follow-up to the recently fixed bugs in the untracked
> invalidation. If opendir() fails it should show a warning, perhaps
> this should die, but if this ever happens the error is probably
> recovera
On Sat, Jan 06, 2018 at 01:48:01AM +0100, lars.schnei...@autodesk.com wrote:
> From: Lars Schneider
>
> Hi,
>
> Patches 1-5 and 6 are helper functions and preparation.
> Patch 6 is the actual change.
>
> I am still torn between "checkout-encoding" and "working-tree-encoding"
> as attribute name
43 matches
Mail list logo
