On 10/25/2017 10:10 PM, Eric Sunshine wrote:
> On Wed, Oct 25, 2017 at 5:53 AM, Michael Haggerty
> wrote:
>> Since commit dc39e09942 (files_ref_store: use a transaction to update
>> packed refs, 2017-09-08), we've been rewriting the `packed-refs` file
>> unnecessarily when deleting a loose refere
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
The best identification of a blob hash is done via a its path at a
given commit, which this implements.
[1] https://stackoverflow.com/que
With traverse_trees_and_blobs factored out of the main traverse function,
the next patch can introduce an in-order revision walking with ease.
Signed-off-by: Stefan Beller
---
list-objects.c | 46 --
1 file changed, 28 insertions(+), 18 deletions(-)
d
This will be useful shortly.
Signed-off-by: Stefan Beller
---
list-objects.c | 2 ++
revision.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/list-objects.c b/list-objects.c
index 0ee0551604..ef64a237d3 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -237,6 +237,
Occasionally a user is given an object hash from a blob as an error message
or other output (e.g. [1]).
It would be useful to get a further description of such a blob, such as
the (commit, path) tuple where this blob was introduced.
This implements the answer in builtin/describe, but I am not sur
I have a charity proposal for you
From: Jacob Keller
I noticed a failure with git rebase interactive mode which causes "exec"
commands to be run with GIT_DIR set. When GIT_DIR is in the environment,
then any command which results in running a git command in
a subdirectory will fail because GIT_DIR=".git".
This unfortunately brea
The fsmonitor command inherits the PWD of its caller, which may be
anywhere in the working copy. This makes is difficult for the
fsmonitor command to operate on the whole repository. Specifically,
for the watchman integration, this causes each subdirectory to get its
own watch entry.
Set the CWD
Updates since v2:
- Fix tab which crept into 1/4
- Fixed the benchmarking code in the commit message in 2/4 to just
always load JSON::XS -- the previous version was the version where
I'd broken that to force loading of JSON::PP.
- Remove the --no-pretty from the t/ version of query-watc
Signed-off-by: Alex Vandiver
---
Documentation/git.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 1fca63634..720db196e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -594,6 +594,10 @@ into it.
Unsetting the varia
If the fsmonitor extension is used in conjunction with the split index
extension, the set of entries in the index when it is first loaded is
only a subset of the real index. This leads to only the non-"base"
index being marked as CE_FSMONITOR_VALID.
Delay the expansion of the ewah bitmap until af
This provides modest performance savings. Benchmarking with the
following program, with and without `--no-pretty`, we find savings of
23% (0.316s -> 0.242s) in the git repository, and savings of 8% (5.24s
-> 4.86s) on a large repository with 580k files in the working copy.
#!/usr/bin/perl
On Sat, 2017-10-28 at 00:11 +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Oct 27 2017, Joe Perches jotted:
[]
> > git grep performance has already been
> > quite successfully improved.
>
> ...and I have WIP patches to use the PCRE engine for patterns without -P
> which I intend to start sending
On Thu, 26 Oct 2017, Ben Peart wrote:
> I saw your response but actually can't replicate it locally. I've been
> running with Watchman integration on all my repos for months and my "watchman
> watch-list" command only shows the root of the various working directories -
> no subdirectories.
Weird.
There has be some desire to add additional flags to the diff machineery
(https://public-inbox.org/git/20171024000931.14814-1-sbel...@google.com/) but
due to the limits of the number of bits in an unsigned int on some systems we
can't add any additonal flags to the 'flags' variable. This series con
Instead of explicitly setting the 'DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG'
flag, use the 'DIFF_OPT_SET' macro.
Signed-off-by: Brandon Williams
---
builtin/reset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 9cd89b230..ea2fad5a0 100644
-
Instead of explicitly setting the 'DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG'
flag, use the 'DIFF_OPT_SET' macro.
Signed-off-by: Brandon Williams
---
builtin/add.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/add.c b/builtin/add.c
index a648cf4c5..b70e8a779 100644
--- a/b
We have have reached the limit of the number of flags that can be stored
in a single unsigned int. In order to allow for more flags to be added
to the diff machinery in the future this patch converts the flags to be
stored in bitfields in 'struct diff_flags'.
Signed-off-by: Brandon Williams
---
On Fri, Oct 27 2017, Joe Perches jotted:
> On Thu, 2017-10-26 at 10:45 -0700, Stefan Beller wrote:
>> On Thu, Oct 26, 2017 at 10:41 AM, Joe Perches wrote:
>> > On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:
>> > > + Avar who knows a thing about pcre (I assume the regex compilation
>> >
On 27 October 2017 at 17:06, Pranit Bauva wrote:
> + for (i = 0; i < argc; i++) {
> + if (!strcmp(argv[i], "--term-good"))
> + printf(_("%s\n"), terms->term_good);
> + else if (!strcmp(argv[i], "--term-bad"))
> + printf(
> * sb/submodule-recursive-checkout-detach-head (2017-07-28) 2 commits
> (merged to 'next' on 2017-10-26 at 30994b4c76)
> + Documentation/checkout: clarify submodule HEADs to be detached
> + recursive submodules: detach HEAD from new state
>
> "git checkout --recursive" may overwrite and rewin
Pranit Bauva writes:
> - bisect_write "$state" "$rev"
> + git bisect--helper --bisect-write "$state" "$rev" "$TERM_GOOD"
> "$TERM_BAD" || exit
I can see why two extra "terms" parameters need to be passed to this
helper at this step; looking at patches around 4/8 and 6/8
Pranit Bauva writes:
> +static int bisect_reset(const char *commit)
> +{
> + struct strbuf branch = STRBUF_INIT;
> +
> + if (!commit) {
> + if (strbuf_read_file(&branch, git_path_bisect_start(), 0) < 1)
> + return !printf(_("We are not bisecting.\n"));
> +
On 27 October 2017 at 17:06, Pranit Bauva wrote:
> + /*
> +* have bad (or new) but not good (or old). We could bisect
> +* although this is less optimum.
> +*/
> + fprintf(stderr, _("Warning: bisecting only with a %s
> co
On 27 October 2017 at 17:06, Pranit Bauva wrote:
> +static void free_terms(struct bisect_terms *terms)
> +{
> + if (!terms->term_good)
> + free((void *) terms->term_good);
> + if (!terms->term_bad)
> + free((void *) terms->term_bad);
> +}
These look like no
On Wed, Oct 25, 2017 at 6:03 AM, Andrey Okoshkin wrote:
> Get 'GIT_MERGE_VERBOSITY' environment variable only once in
> init_merge_options() and store the pointer to its value for the further check.
> No intervening calls to getenv(), putenv(), setenv() or unsetenv() are done
> between the initial
On Thu, 2017-10-26 at 10:45 -0700, Stefan Beller wrote:
> On Thu, Oct 26, 2017 at 10:41 AM, Joe Perches wrote:
> > On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:
> > > + Avar who knows a thing about pcre (I assume the regex compilation
> > > has impact on grep speed)
> > >
> > > On Thu,
On Fri, Oct 27, 2017 at 12:12 AM, Junio C Hamano wrote:
> René Scharfe writes:
>
>> Am 25.10.2017 um 20:49 schrieb Stefan Beller:
>>> +/*
>>> + * Compare the strings l1 with l2 which are of size s1 and s2 respectively.
>>> + * Returns 1 if the strings are deemed equal, 0 otherwise.
>>> + * The `f
There is no need to forward-declare these functions, as they are used
after their implementation only.
Signed-off-by: Stefan Beller
---
xdiff/xdiffi.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 93a65680a1..0a4ea948f9 100644
--- a/x
> Let's do this bit-shuffling as a preliminary clean-up.
These 2 patches can go on top of that as well.
Thanks,
Stefan
Stefan Beller (2):
xdiff/xdiff.h: remove unused flags
xdiff/xdiffi.c: remove unneeded function declarations
xdiff/xdiff.h | 8
xdiff/xdiffi.c | 17 -
These flags were there since the beginning (3443546f6e (Use a *real*
built-in diff generator, 2006-03-24), but were never used. Remove them.
Signed-off-by: Stefan Beller
---
xdiff/xdiff.h | 8
1 file changed, 8 deletions(-)
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 457cac32d8..0
On Thu, Oct 26, 2017 at 11:13 PM, Junio C Hamano wrote:
> Subject: [PATCH] xdiff: reassign xpparm_t.flags bits
>
> We have packed the bits too tightly in such a way that it is not
> easy to add a new type of whitespace ignoring option, a new type
> of LCS algorithm, or a new type of post-cleanup h
Junio C Hamano writes:
> Andrey Okoshkin writes:
>
>> I'm not sure why only ENOENT error of lstat() is considered as an
>> error but passing by other errno values leads to reading of
>> uninitialized 'struct stat st' variable. It means that the
>> populated 'diff_filespec' structure may be inco
Andrey Okoshkin writes:
> I'm not sure why only ENOENT error of lstat() is considered as an
> error but passing by other errno values leads to reading of
> uninitialized 'struct stat st' variable. It means that the
> populated 'diff_filespec' structure may be incorrectly filled.
Entirely correc
Hello,
Is there anything like this:
$ git merge b
[... lot of conflicts ...]
$ git re-merge -X ours -- x/ # Leaves 0 conflicts in x/
$ git re-merge -X theirs -- y/ # Leaves 0 conflicts in y/
[... resolve the rest of conflicts manually ...]
$ git commit
[*] I do mean '-X' above, not '-s'.
-- S
On Fri, Oct 27, 2017 at 09:55:58AM -0400, Adrian Kappel wrote:
> Hello all, not sure if the issue I've come across is a known bug or
> addressable, but wanted to report it just in-case.
Thanks for the detailed description - my question is inline
>
>
> ** Summary
> --
Hey,
I forgot to mention. One can find the travis build here[1] which is passing.
[1]: https://travis-ci.org/git/git/builds/293725346
Regards,
Pranit Bauva
Hi Lars,
On Thu, 26 Oct 2017, Lars Schneider wrote:
> > On 26 Oct 2017, at 09:09, Johannes Sixt wrote:
> >
> > Am 25.10.2017 um 14:19 schrieb Johannes Schindelin:
> >> I envy you for the blessing of such a clean C++ source that you do not
> >> have any, say, Unix shell script in it. Try this, a
'' In einer kurzen Einführung,
Ich bin ein Rechtsanwalt Meinze Klaus Peter, aus Deutschland, lebe
zurzeit in London, ich habe dir eine E-Mail über deine verstorbene
Familienangehörige verspätet. Ich habe keine Antwort von dir erhalten.
Die verstorbene Person ist eine Bürgerin deines Landes mit dem
Hi Alex,
On Wed, 25 Oct 2017, Alex Vandiver wrote:
> [Johannes asked about the speedup when using --no-pretty]
>
> ...so a modest 8% speedup. I note that those numbers are for a perl
> with JSON::XS installed; without it installed, the runtime is so long
> that I gave up waiting for it.
Very ni
Hi Bryan,
On Thu, 26 Oct 2017, Bryan Turner wrote:
> On Thu, Oct 26, 2017 at 2:07 AM, Jacob Keller wrote:
> > On Wed, Oct 25, 2017 at 10:38 PM, Junio C Hamano wrote:
> >> Johannes Schindelin writes:
> >>
> >>> Note that the correct blib path starts with `C:\BuildAgent\_work` and
> >>> the line
Hi Alex,
On Wed, 25 Oct 2017, Alex Vandiver wrote:
> On Fri, 20 Oct 2017, Johannes Schindelin wrote:
> > This is super expensive, as it means a full-blown new process instead of
> > just a simple environment variable expansion.
> >
> > The idea behind using `PWD` instead was that Git will alread
Reimplement `bisect_reset` shell function in C and add a `--bisect-reset`
subcommand to `git bisect--helper` to call it from git-bisect.sh .
Using `bisect_reset` subcommand is a temporary measure to port shell
functions to C so as to use the existing test suite. As more functions
are ported, this
Reimplement the `bisect_start` shell function partially in C and add
`bisect-start` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
The last part is not converted because it calls another shell function
`bisect_start` shell function will be completed after the `bisect_next`
shel
Reimplement the `get_terms` and `bisect_terms` shell function in C and
add `bisect-terms` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
Using `--bisect-terms` subcommand is a temporary measure to port shell
function in C so as to use the existing test suite. As more functions
Reimplement `bisect_next_check` shell function in C and add
`bisect-next-check` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
`bisect_voc` shell function is no longer useful now and is replaced by
using a char *[] of "new|bad" and "good|old" values.
Using `--bisect-next-check
Reimplement the `check_and_set_terms` shell function in C and add
`check-and-set-terms` subcommand to `git bisect--helper` to call it from
git-bisect.sh
Using `--check-and-set-terms` subcommand is a temporary measure to port
shell function in C so as to use the existing test suite. As more
functio
is_empty_file() can help to refactor a lot of code. This will be very
helpful in porting "git bisect" to C.
Suggested-by: Torsten Bögershausen
Mentored-by: Lars Schneider
Mentored-by: Christian Couder
Signed-off-by: Pranit Bauva
---
builtin/am.c | 20 ++--
cache.h | 3 ++
Reimplement the `bisect_write` shell function in C and add a
`bisect-write` subcommand to `git bisect--helper` to call it from
git-bisect.sh
Using `--bisect-write` subcommand is a temporary measure to port shell
function in C so as to use the existing test suite. As more functions
are ported, this
Signed-off-by: Pranit Bauva
---
t/t6030-bisect-porcelain.sh | 120 ++--
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 55835ee4a4715..f9e61c6540e57 100755
--- a/t/t6030-bisect-
Hi Junio,
On Thu, 26 Oct 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Note that the correct blib path starts with `C:\BuildAgent\_work` and
> > the line
> >
> > use lib (split(/:/, $ENV{GITPERLLIB}));
> >
> > splits off the drive letter from the rest of the path. Obviousl
On 10/26/2017 9:20 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
From: Jeff Hostetler
Refactor add_excludes() to separate the reading of the
exclude file into a buffer and the parsing of the buffer
into exclude_list items.
Add add_excludes_from_blob_to_list() to allow an exclude
file b
Hi Peff,
On Wed, 25 Oct 2017, Jeff King wrote:
> On Wed, Oct 25, 2017 at 11:35:44PM +0200, Johannes Schindelin wrote:
>
> > > > Or alternatively we could prefix the assignment by
> > > >
> > > > test -n "$TEST_SHELL_PATH" ||
> > > >
> > > > or use the pattern
> > > >
> > > > T
I've long been confused by something in the man page for gitignore. I think
it's unclear and I'd like to propose a change. The passage is this (source at
https://git.kernel.org/pub/scm/git/git-manpages.git/tree/man5/gitignore.5):
Two consecutive asterisks ("**") in patterns matched against ful
Hello all, not sure if the issue I've come across is a known bug or
addressable, but wanted to report it just in-case.
** Summary
--
Using the [includeIf] configuration statement with a symlink'd gitdir
will not work if the symlink i
On Okt 27 2017, Alvaro del Castillo wrote:
> We're wondering why "fetch-pack" (when is running from the command
> line) doesn't handle "https://"; protocol. It only works with "git://".
>
> For instance, this doesn't work:
>
> $ git fetch-pack https://github.com/git/git refs/heads/master
> fatal:
> On 27 Oct 2017, at 14:11, Lars Schneider wrote:
>
>
>> On 21 Oct 2017, at 00:22, Johannes Schindelin
>> wrote:
>>
>> Hi team,
>>
>> [cutting linux-kernel]
>>
>> On Fri, 20 Oct 2017, Junio C Hamano wrote:
>>
>>> A release candidate Git v2.15.0-rc2 is now available for testing
>>> at the
> On 21 Oct 2017, at 00:22, Johannes Schindelin
> wrote:
>
> Hi team,
>
> [cutting linux-kernel]
>
> On Fri, 20 Oct 2017, Junio C Hamano wrote:
>
>> A release candidate Git v2.15.0-rc2 is now available for testing
>> at the usual places.
>
> The Git for Windows equivalent is now available f
Dear all,
We're wondering why "fetch-pack" (when is running from the command
line) doesn't handle "https://"; protocol. It only works with "git://".
For instance, this doesn't work:
$ git fetch-pack https://github.com/git/git refs/heads/master
fatal: I don't handle protocol 'https'
while this d
Add lstat() error handling not only for ENOENT case.
Otherwise uninitialised 'struct stat st' variable is used later in case of
lstat() non-ENOENT failure which leads to processing of rubbish values of
file mode ('S_ISLNK(st.st_mode)' check) or size ('xsize_t(st.st_size)').
Signed-off-by: Andrey O
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The topics that are cooking in 'ne
Hi Jonathan,
I can't disagree with you - the right solution is to fix the build/release
process to support
signed tagging. It's just too many of them to fix: jenkins, maven, IDE, etc. My
naive assumption
was that if a tool (git) has a switch to enable some functionality, why not
have a possibil
- Mail original -
De: "Jacob Keller"
Hi Jacob,
> I think that this could easily be built by a separate script which provides
> git release command line and uses tags under the hood in a
> well formed way.
True, the difficulty is not technical, the whole scheme is basic and KISS.
>
René Scharfe writes:
> Am 25.10.2017 um 20:49 schrieb Stefan Beller:
>> +/*
>> + * Compare the strings l1 with l2 which are of size s1 and s2 respectively.
>> + * Returns 1 if the strings are deemed equal, 0 otherwise.
>> + * The `flags` given as XDF_WHITESPACE_FLAGS determine how white spaces
>>
64 matches
Mail list logo