On 10/12/2018 11:07 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Oct 12 2018, Junio C Hamano wrote:
Makes sense. If this second iteration were also time consuming,
then it probably is a good idea to split these into two separate
phases? "Counting 1...N" followed by "Inspecting 1...N" or
Hi all,
Does git load the entire index file into memory when it wants to
edit/view it? I ask because I wonder if this can become a problem with
the index file becomes arbitrarily large, like for the Linux kernel.
Thanks,
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC
"Johannes Schindelin via GitGitGadget"
writes:
> @@ -3293,6 +3312,9 @@ static int pick_commits(struct todo_list *todo_list,
> struct replay_opts *opts)
> unlink(rebase_path_stopped_sha());
> unlink(rebase_path_amend());
>
On Fri, Oct 12 2018, Junio C Hamano wrote:
> * ab/gc-doc-update (2018-10-11) 1 commit
> - gc doc: mention the commit-graph in the intro
>
> The documentation of "git gc" has been updated to mention that it
> is no longer limited to "pruning away crufts" but also updates
> ancillary files
Hi Junio,
On Fri, 12 Oct 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Hi Junio,
> >
> > On Fri, 12 Oct 2018, Junio C Hamano wrote:
> >
> >> From: Martin Koegler
> >> Date: Thu, 10 Aug 2017 20:13:08 +0200
> >>
> >> Signed-off-by: Martin Koegler
> >> Signed-off-by: Junio C
Roger Strain writes:
> After testing a previous patch at larger scale, a performance issue was
> detected when using git show to locate parent revisions, with a single
> run of the git show command taking 2 seconds or longer in a complex repo.
> When the command is required tens or hundreds of
Am 12.10.18 um 08:33 schrieb Junio C Hamano:
"Derrick Stolee via GitGitGadget" writes:
+struct topo_walk_info {};
+
+static void init_topo_walk(struct rev_info *revs)
+{
+ struct topo_walk_info *info;
+ revs->topo_walk_info = xmalloc(sizeof(struct topo_walk_info));
+ info =
On Fri, Oct 12 2018, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>>> for (i = 0; i < oids->nr; i++) {
>>> + display_progress(progress, ++j);
>>> commit = lookup_commit(the_repository, >list[i]);
>>>
>>> if (commit && !parse_commit(commit))
>>> @@
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.
Quite a lot of topics have been
To increase coverage of the multi-pack-index feature, add a
GIT_TEST_MULTI_PACK_INDEX environment variable similar to other GIT_TEST_*
variables.
After creating the environment variable and running the test suite with it
enabled, I found a few bugs in the multi-pack-index implementation. These
From: Derrick Stolee
When repacking, we may remove pack-files. This invalidates the
multi-pack-index (if it exists). Previously, we removed the
multi-pack-index file before removing any pack-file. In some cases,
the repack command may load the multi-pack-index into memory. This
may lead to later
From: Derrick Stolee
The multi-pack-index feature is tested in isolation by
t5319-multi-pack-index.sh, but there are many more interesting
scenarios in the test suite surrounding pack-file data shapes
and interactions. Since the multi-pack-index is an optional
data structure, it does not make
From: Derrick Stolee
When closing a multi-pack-index, we intend to close each pack-file
and free the struct packed_git that represents it. However, this
line was previously freeing the array of pointers, not the
pointer itself. This leads to a double-free issue.
Signed-off-by: Derrick Stolee
On Fri, Oct 12, 2018 at 07:40:37PM +0100, Thomas Gummerer wrote:
> 801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08) added
> the -Wformat-security to the flags set in config.mak.dev. In the gcc
> man page this is documented as:
>
> If -Wformat is specified, also warn
Jeff King wrote:
> On Fri, Oct 12, 2018 at 07:40:37PM +0100, Thomas Gummerer wrote:
>> 801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08) added
>> the -Wformat-security to the flags set in config.mak.dev. In the gcc
>> man page this is documented as:
>>
>> If -Wformat is
On 10/12, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Fri, Oct 12, 2018 at 07:40:37PM +0100, Thomas Gummerer wrote:
>
> >> 801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08) added
> >> the -Wformat-security to the flags set in config.mak.dev. In the gcc
> >> man page this is
Hi Junio,
On Fri, 12 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > This patch introduces that, based on ag/rebase-i-in-c.
> >
> > Changes since v2:
> >
> > * Fixed two typos.
> > * When interrupting the rebase, break now outputs a message.
>
> I
Hi Junio,
On Fri, 12 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > @@ -3293,6 +3312,9 @@ static int pick_commits(struct todo_list *todo_list,
> > struct replay_opts *opts)
> > unlink(rebase_path_stopped_sha());
> >
git diff –numstat FOLDER1 FOLDER2 works strange when run from a git
controlled folder.
The output shrinks some symbols in the diff file paths.
For example:
Create a folder and call git init, for example: `C:\test`.
mkdir C:\test
cd C:\test
git init
On Thu, Oct 11, 2018 at 10:19:22AM +0900, Junio C Hamano wrote:
> > @@ -1373,36 +1379,31 @@ static void fill_remote_ref_details(struct
> > used_atom *atom, const char *refname,
> > }
> > } else if (atom->u.remote_ref.option == RR_TRACKSHORT) {
> > if
>
> * sb/strbuf-h-update (2018-09-29) 1 commit
> - strbuf.h: format according to coding guidelines
>
> Code clean-up to serve as a BCP example.
>
> What's the status of this one after the discussion thread stopped here?
> cf.
I started rewriting the documentation according to your proposal
Hi,
Stefan Beller wrote:
> This applies on nd/the-index (b3c7eef9b05) and is the logical continuation of
> the object store series, which I sent over the last year.
>
> The previous series did take a very slow and pedantic approach,
> using a #define trick, see cfc62fc98c for details, but it
Here is a re-roll-up since I haven't received any additional corrections for
almost a week. The changes are very slight and just for clean-up so it is ready
to be promoted to master.
This is the interdiff from last time:
diff --git a/t/t5317-pack-objects-filter-objects.sh
This will make utility functions easier to create, as done by the next
patch.
Signed-off-by: Matthew DeVore
---
list-objects.c | 158 +++--
1 file changed, 74 insertions(+), 84 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index
This will be used in a follow-up patch to reduce indentation needed when
invoking the logic conditionally. i.e. rather than:
if (foo) {
while (...) {
/* this is very indented */
}
}
we will have:
if (foo)
process_tree_contents(...);
Signed-off-by:
From: Martin Koegler
Signed-off-by: Martin Koegler
Signed-off-by: Junio C Hamano
Signed-off-by: Torsten Bögershausen
---
After doing a review, I decided to send the result as a patch.
In general, the changes from off_t to size_t seem to be not really
motivated.
But if they are, they could
On Fri, 12 Oct 2018 at 14:45, Junio C Hamano wrote:
>
> Luke Diamand writes:
>
> > The branch detection code looks for branches under refs/remotes/p4/...
> > and can end up getting confused if there are unshelved changes in
> > there as well. This happens in the function p4BranchesInGit().
> >
>
Previously, we assumed only blob objects could be missing. This patch
makes rev-list handle missing trees like missing blobs. The --missing=*
and --exclude-promisor-objects flags now work for trees as they already
do for blobs. This is demonstrated in t6112.
Signed-off-by: Matthew DeVore
---
If parsing fails when revs->ignore_missing_links and
revs->exclude_promisor_objects are both false, we print the OID anyway
in the die("bad tree object...") call, so any message printed by
parse_tree_gently() is superfluous.
Signed-off-by: Matthew DeVore
---
list-objects.c | 4 +---
1 file
Currently, list-objects.c incorrectly treats all root trees of commits
as USER_GIVEN. Also, it would be easier to mark objects that are
non-user-given instead of user-given, since the places in the code
where we access an object through a reference are more obvious than
the places where we access
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11 ---
Teach list-objects the "tree:0" filter which allows for filtering
out all tree and blob objects (unless other objects are explicitly
specified by the user). The purpose of this patch is to allow smaller
partial clones.
The name of this filter - tree:0 - does not explicitly specify that
it also
The function gently_parse_list_objects_filter is either called with
errbuf=STRBUF_INIT or errbuf=NULL, but that function calls strbuf_init
when errbuf is not NULL. strbuf_init is only necessary if errbuf
contains garbage, and risks a memory leak if errbuf already has a
non-STRBUF_INIT state. It
On 10/12/2018 1:34 PM, Derrick Stolee via GitGitGadget wrote:
To increase coverage of the multi-pack-index feature, add a
GIT_TEST_MULTI_PACK_INDEX environment variable similar to other GIT_TEST_*
variables.
After creating the environment variable and running the test suite with it
enabled, I
801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08) added
the -Wformat-security to the flags set in config.mak.dev. In the gcc
man page this is documented as:
If -Wformat is specified, also warn about uses of format
functions that represent possible security
Hi,
Stefan Beller wrote:
> The submodule helper update_clone called by "git submodule update",
> clones submodules if needed. As submodules used to have the URL indicating
> if they were active, the step to resolve relative URLs was done in the
> "submodule init" step. Nowadays submodules can be
On Fri, Oct 12, 2018 at 11:24:43AM +0200, Johannes Schindelin wrote:
>
>
> On Thu, 11 Oct 2018, Lucas De Marchi wrote:
>
> > On Wed, Oct 10, 2018 at 5:02 PM brian m. carlson
> > wrote:
> > >
> > > On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> > > > Do like it's done in
Hi,
Josh Steadmon wrote:
> So this runs into problems with remote-curl (and possibly other remote
> helpers):
>
> builtin/push.c can declare whatever allowed versions it wants, but those
> are not carried over when remote-curl is started to actually talk to the
> remote. What's worse,
Josh Steadmon wrote:
> For now, I'm going to try adding an --allowed_versions flag for the
> remote helpers, but if anyone has a better idea, let me know.
I forgot to mention: the stateless-connect remote helper capability is
still experimental so you're free to change its interface (e.g. to
On Fri, Oct 12, 2018 at 10:38:45PM -0400, Jeff King wrote:
> So right now let's imagine that off_t is 64-bit, and "unsigned long" is
> 32-bit (e.g., 32-bit system, or an IL32P64 model like Windows). We'll
> repeatedly ask use_pack() for a window, and it will tell us how many
> bytes we have in
There is a problem on travis-ci with doing builds on Pull Requests
with multiple jobs. For each job it will build off the FETCH_HEAD. The
problem is that if the FETCH_HEAD changes while the build is running
(due to a commit), the subsequent jobs will build off the new
FETCH_HEAD. This results in
On Fri, Oct 12, 2018 at 04:07:25PM +0900, Junio C Hamano wrote:
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index e6316d294d..b9ca04eb8a 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -266,15 +266,15 @@ static void copy_pack_data(struct hashfile *f,
[]
> Neither v1 nor v2 of this patch compiles on 32 bit Linux; see
>
> https://travis-ci.org/git/git/jobs/440514375#L628
>
> The fixup patch below makes it compile on 32 bit and the test suite
> passes as well, but I didn't thoroughly review the changes; I only
> wanted to get 'pu' build
On Fri, Oct 12, 2018 at 10:42:29PM +0200, tbo...@web.de wrote:
> From: Martin Koegler
>
> Signed-off-by: Martin Koegler
> Signed-off-by: Junio C Hamano
> Signed-off-by: Torsten Bögershausen
> ---
>
> After doing a review, I decided to send the result as a patch.
> In general, the changes
Josh Steadmon wrote:
> On 2018.10.12 16:32, Jonathan Nieder wrote:
>> Josh Steadmon wrote:
>>> For now, I'm going to try adding an --allowed_versions flag for the
>>> remote helpers, but if anyone has a better idea, let me know.
>>
>> I forgot to mention: the stateless-connect remote helper
> On large repositories with lots of tags - git wire protocol v2 fails
> to fetch shallow changes, it fails with error `pack has XXX unresolved
> deltas`. Unfortunately I didn't find easy way to reproduce it except
> cloning+fetching chromium repository, the way jenkins does.
> Reproduction steps:
We want to load unmerged entries from HEAD into the index at stage 2 and
from MERGE_HEAD into stage 3. Similarly, folks expect merge conflicts
to look like
HEAD
content from our side
content from their side
MERGE_HEAD
not
MERGE_HEAD
content from their side
When merges involve content conflicts, merge.conflictstyle=diff3 can be
used to also show the content for the file from the base version. If
there was more than one merge base, then the "base version" is
determined by merging the merge bases to create a virtual merge base.
This means that the
On Thu, Oct 11, 2018 at 6:02 PM wrote:
>
> From: Josh Steadmon
>
> 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
On 2018.10.12 16:32, Jonathan Nieder wrote:
> Josh Steadmon wrote:
>
> > For now, I'm going to try adding an --allowed_versions flag for the
> > remote helpers, but if anyone has a better idea, let me know.
>
> I forgot to mention: the stateless-connect remote helper capability is
> still
On Thu, Oct 11, 2018 at 3:11 PM Jonathan Tan wrote:
>
> > In 8e4b0b6047 (object.c: allow parse_object to handle
> > arbitrary repositories, 2018-06-28), we forgot to pass the
> > repository down to the read_object_file.
>
> [snip]
>
> > @@ -270,7 +270,7 @@ struct object *parse_object(struct
From: Josh Steadmon
V2 of this series pulls the compiler flags out of the Makefile, to be
provided by the user depending on the combination of compiler and
fuzzing engine in use. This also makes it more compatible with
OSS-Fuzz's build process.
Josh Steadmon (2):
fuzz: Add basic fuzz testing
From: Josh Steadmon
Breaks the majority of check_packed_git_idx() into a separate function,
load_idx(). The latter function operates on arbitrary buffers, which
makes it suitable as a fuzzing test target.
Signed-off-by: Josh Steadmon
---
.gitignore | 1 +
Makefile| 1 +
On 2018.10.10 11:14, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > +FUZZ_OBJS += fuzz-pack-headers.o
> > +
> > +FUZZ_PROGRAMS += $(patsubst %.o,%,$(FUZZ_OBJS))
> > +
> > ...
> > +### Fuzz testing
> > +#
> > +.PHONY: fuzz-clean fuzz-objs fuzz-compile
>
> I take it that you anticipate the
From: Josh Steadmon
fuzz-pack-headers.c provides a fuzzing entry point compatible with
libFuzzer (and possibly other fuzzing engines).
Signed-off-by: Josh Steadmon
---
.gitignore | 2 ++
Makefile| 32
fuzz-pack-headers.c | 14
On Fri, Oct 12, 2018 at 11:54:50AM -0700, Jonathan Nieder wrote:
> > I'm not opposed to making config.mak.dev a bit more redundant to handle
> > this case, but we'd probably want to include all of -Wall, since it
> > contains many other warnings we'd want to make sure are enabled.
>
> Do you
GnuPG supports creating signatures consisting of multiple signature
packets. If such a signature is verified, it outputs all the status
messages for each signature separately. However, git currently does not
account for such scenario and gets terribly confused over getting
multiple *SIG
When using merge.conflictstyle=diff3 to have the "base version" be shown
in conflicts, there is the possibility that the base version itself has
conflicts in it. This comes about when there are more than one merge
base, and the merging of those merge bases produces a conflict.
Since this process
Each individual file involved in a rename could have also been modified
on both sides of history, meaning it may need to have content merges.
If two such files are renamed into the same location, then on top of the
two natural auto-merging messages we also have to two-way merge the
result, giving
This series builds on en/merge-cleanup. Technically, this could be
broken into three separate topics with only one of them depending on
en/merge-cleanup, but I have a subsequent series that depends on both
en/merge-cleanup and the fixes here, so I'm submitting these four
patches as a set.
Elijah
On Fri, Oct 12, 2018 at 12:44 PM Stefan Beller wrote:
> > * sb/submodule-recursive-fetch-gets-the-tip (2018-10-11) 9 commits
> > . builtin/fetch: check for submodule updates for non branch fetches
> > . fetch: retry fetching submodules if needed objects were not fetched
> > . submodule: fetch
On Thu, Oct 11, 2018 at 3:41 PM Jonathan Tan wrote:
>
> > +/*
> > + * Initialize 'out' based on the provided submodule path.
> > + *
> > + * Unlike repo_submodule_init, this tolerates submodules not present
> > + * in .gitmodules. NEEDSWORK: The repo_submodule_init behavior is
> > + *
The submodule helper update_clone called by "git submodule update",
clones submodules if needed. As submodules used to have the URL indicating
if they were active, the step to resolve relative URLs was done in the
"submodule init" step. Nowadays submodules can be configured active without
calling
On 12/10/18 16:34, Johannes Schindelin wrote:
> Hi Junio,
>
> On Fri, 12 Oct 2018, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>>> Hi Junio,
>>>
>>> On Fri, 12 Oct 2018, Junio C Hamano wrote:
>>>
From: Martin Koegler
Date: Thu, 10 Aug 2017 20:13:08 +0200
On Fri, Oct 12, 2018 at 11:50 AM Jonathan Nieder wrote:
>
> It appears that some patches use a the_index-style
> NO_THE_REPOSITORY_COMPATIBILITY_MACROS backward compatibility synonym
> and others don't. Can you say a little more about this aspect of the
> approach? Would the compatibility
Stefan Beller writes:
>> * sb/submodule-recursive-fetch-gets-the-tip (2018-10-11) 9 commits
>> . builtin/fetch: check for submodule updates for non branch fetches
>> . fetch: retry fetching submodules if needed objects were not fetched
>> . submodule: fetch in submodules git directory instead
Roger Strain writes:
> After doing some testing at scale, determined that one call was
> taking too long; replaced that with an alternate call which
> returns the same data significantly faster.
Curious where the time goes. Do you know?
> Also, if anyone has any other feedback on these I'd
Hi Era,
On Sun, 7 Oct 2018, Era wrote:
> I discovered an apparent underflow when using the —unified=0 / -U0 flag with
> git-show on a merge commit.
> Leaving the flag on its default value or 1 shows the ranges correctly.
>
> $git --no-pager show -z --no-color --pretty=%x00%s%x00%b%x00
Hi Michael,
On Wed, 10 Oct 2018, Michael Witten wrote:
> In my opinion, the `--rebase-merges' feature has been broken since the
> beginning, and the builtin version should be fixed before it is moved
> ahead.
Everybody is entitled to an opinion. My opinion differs from yours, and I
am a heavy
On Thu, 11 Oct 2018, Lucas De Marchi wrote:
> On Wed, Oct 10, 2018 at 5:02 PM brian m. carlson
> wrote:
> >
> > On Wed, Oct 10, 2018 at 08:09:16AM -0700, Lucas De Marchi wrote:
> > > Do like it's done in grep so mode doesn't end up as
> > > 016, which means range-diff doesn't work if one
SZEDER Gábor writes:
>> for (i = 0; i < oids->nr; i++) {
>> +display_progress(progress, ++j);
>> commit = lookup_commit(the_repository, >list[i]);
>>
>> if (commit && !parse_commit(commit))
>> @@ -611,19 +624,28 @@ static void close_reachable(struct
Hi Phillip,
On Thu, 11 Oct 2018, Phillip Wood wrote:
> I think this would be a useful addition to rebase, there's one small
> comment below.
>
> On 10/10/2018 09:53, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > The 'edit' command can be used to cherry-pick
Hi Junio & Eric,
On Thu, 11 Oct 2018, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> > On Wed, Oct 10, 2018 at 4:54 AM Johannes Schindelin via GitGitGadget
> > wrote:
> >> We had not documented previously what happens when an `exec` command in
> >> an interactive rebase fails. Now we do.
>
Johannes Schindelin writes:
> On Sun, 7 Oct 2018, Junio C Hamano wrote:
>
>> And then there is an unnamed misdesigned language that has a
>> regmatch() function, which takes a string that contains a regular
>> expression, but somehow requires that string to begin and end with a
>> slash for no
Hi Phillip,
On Fri, 12 Oct 2018, Phillip Wood wrote:
> Hi Johannes
> On 12/10/2018 09:35, Johannes Schindelin wrote:
> > Hi Phillip,
> >
> > On Thu, 11 Oct 2018, Phillip Wood wrote:
> >
> >> I think this would be a useful addition to rebase, there's one small
> >> comment below.
> >>
> >> On
Le 12/10/2018 à 11:54, Phillip Wood a écrit :
> On 11/10/2018 17:57, Alban Gruin wrote:
> > Hi Phillip,
> >
> > thanks for taking the time to review my patches.
> >
> > Le 11/10/2018 à 13:25, Phillip Wood a écrit :
> >> On 07/10/2018 20:54, Alban Gruin wrote:
> >>> @@ -4419,15 +4406,38 @@ int
Hi Junio,
On Thu, 6 Sep 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > This patch series completes the support for all rebase options in the
> > builtin rebase, e.g. --signoff, rerere-autoupdate, etc.
> >
> > It is based on pk/rebase -in-c-3-acts.
>
> ...
On 10/11/2018 11:01 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
CHANGES IN V4: I reduced the blame output using -s which decreases the
width. I include a summary of the commit authors at the end to help people
see the lines they wrote. This version is also copied into
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean.
Hi Stefan,
On Wed, 10 Oct 2018, Stefan Beller wrote:
> Instead of passing the sign directly to emit_line_ws_markup, pass only the
> index to lookup the sign in diff_options->output_indicators.
>
> Signed-off-by: Stefan Beller
> ---
>
> I still have this patch laying around, it simplifies the
On 11/10/2018 17:57, Alban Gruin wrote:
> Hi Phillip,
>
> thanks for taking the time to review my patches.
>
> Le 11/10/2018 à 13:25, Phillip Wood a écrit :
>> On 07/10/2018 20:54, Alban Gruin wrote:
>>> @@ -4419,15 +4406,38 @@ int sequencer_add_exec_commands(const char
>>> *commands)
>>>
Hi Junio,
On Fri, 12 Oct 2018, Junio C Hamano wrote:
> From: Martin Koegler
> Date: Thu, 10 Aug 2017 20:13:08 +0200
>
> Signed-off-by: Martin Koegler
> Signed-off-by: Junio C Hamano
> ---
>
> * I made minimal adjustments to make the change apply to today's
>codebase. I still find some
On 11/10/2018 23:40, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> On 10/10/2018 06:43, Junio C Hamano wrote:
>>> 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
Hi Lucas,
On Thu, 11 Oct 2018, Lucas De Marchi wrote:
> Do like it's done in grep so mode doesn't end up as
> 016, which means range-diff doesn't work if one has
> "submodule.diff = log" in the configuration. Without this
> while using range-diff I only get a
>
> Submodule a
Hi Johannes
On 12/10/2018 09:35, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Thu, 11 Oct 2018, Phillip Wood wrote:
>
>> I think this would be a useful addition to rebase, there's one small
>> comment below.
>>
>> On 10/10/2018 09:53, Johannes Schindelin via GitGitGadget wrote:
>>> From:
Hi Junio,
On Thu, 11 Oct 2018, Junio C Hamano wrote:
> From: Johannes Schindelin
> Date: Thu, 27 Sep 2018 14:48:17 +0200
>
> The `--gpg-sign` option takes an *optional* argument, not a mandatory
> one.
>
> This was discovered as part of the investigation of
>
On Sun, Oct 07, 2018 at 09:54:10PM +0200, Alban Gruin wrote:
> diff --git a/sequencer.c b/sequencer.c
> index 30a7fe3958..dfb8d1c974 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -4083,7 +4083,7 @@ static const char *label_oid(struct object_id *oid,
> const char *label,
> }
>
> static
From: Martin Koegler
Date: Thu, 10 Aug 2017 20:13:08 +0200
Signed-off-by: Martin Koegler
Signed-off-by: Junio C Hamano
---
* I made minimal adjustments to make the change apply to today's
codebase. I still find some choices and mixing of off_t and
size_t done by the patch a bit iffy,
Hi Junio,
On Sun, 7 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > Note: while this patch targets pk/rebase-in-c-6-final, it will not work
> > correctly without ag/rebase-i-in-c. So my suggestion is to rewrite the
> > pk/rebas-in-c-6-final branch by
"Derrick Stolee via GitGitGadget" writes:
> * revs->limited implies we run limit_list() to walk the entire
> reachable set. There are some short-cuts here, such as if we
> perform a range query like 'git rev-list COMPARE..HEAD' and we
> can stop limit_list() when all queued commits are
On Wed, 10 Oct 2018, Junio C Hamano wrote:
> Christian Hesse writes:
>
> > From: Christian Hesse
> >
> > We have targets 'install-man' and 'install-html', let's add build
> > targets as well.
> > ...
> > +man: $(GIT_SUBTREE_DOC)
> > +
> > +html: $(GIT_SUBTREE_HTML)
> > +
>
> As 'contrib'
Hi Junio,
On Sun, 7 Oct 2018, Junio C Hamano wrote:
> And then there is an unnamed misdesigned language that has a
> regmatch() function, which takes a string that contains a regular
> expression, but somehow requires that string to begin and end with a
> slash for no justifiable reason ;-).
It
Original failed to include the note that this patch is for the 'next' branch,
my apologies.
> -Original Message-
> From: Roger Strain
> Sent: Friday, October 12, 2018 8:52 AM
> To: git@vger.kernel.org
> Cc: Strain, Roger L.
> Subject: [PATCH] subtree: performance improvement for
"Johannes Schindelin via GitGitGadget"
writes:
> This patch introduces that, based on ag/rebase-i-in-c.
>
> Changes since v2:
>
> * Fixed two typos.
> * When interrupting the rebase, break now outputs a message.
I was about to merge the whole collection of topics to 'next', but
this came to
On Fri, Oct 12, 2018 at 9:34 AM Daniels Umanovskis
wrote:
> When called with --show-current, git branch will print the current
> branch name and terminate. Only the actual name gets printed,
> without refs/heads. In detached HEAD state, nothing is output.
>
> Signed-off-by: Daniels Umanovskis
>
Luke Diamand writes:
> The branch detection code looks for branches under refs/remotes/p4/...
> and can end up getting confused if there are unshelved changes in
> there as well. This happens in the function p4BranchesInGit().
>
> Instead, put the unshelved changes into
Johannes Schindelin writes:
> Hi Junio,
>
> On Fri, 12 Oct 2018, Junio C Hamano wrote:
>
>> From: Martin Koegler
>> Date: Thu, 10 Aug 2017 20:13:08 +0200
>>
>> Signed-off-by: Martin Koegler
>> Signed-off-by: Junio C Hamano
>> ---
>>
>> * I made minimal adjustments to make the change apply
On 10/12/2018 2:33 AM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
* revs->limited implies we run limit_list() to walk the entire
reachable set. There are some short-cuts here, such as if we
perform a range query like 'git rev-list COMPARE..HEAD' and we
can stop
In an effort to ensure new code is reasonably covered by the test suite,
we now have contrib/coverage-diff.sh to combine the gcov output from
'make coverage-test ; make coverage-report' with the output from 'git
diff A B' to discover _new_ lines of code that are not covered.
This report
Most of our semantic patches in 'contrib/coccinelle/object_id.cocci'
turn calls of SHA1-specific functions into calls of their
corresponding object_id counterparts, e.g. sha1_to_hex() to
oid_to_hex(). These semantic patches look something like this:
@@
expression E1;
@@
-
1 - 100 of 106 matches
Mail list logo
