Hi,
SZEDER Gábor wrote:
> Other Bash versions, notably 4.4.19 on macOS via homebrew (i.e. a
> newer version on the same platform) and 3.2.25 on CentOS (i.e. a
> slightly earlier version, though on a different platform) are not
> affected. ZSH in macOS (the versions shipped by default or
On Sat, Jun 2, 2018 at 11:58 PM, Elijah Newren wrote:
> builtin/merge.c contains this important requirement for merge strategies:
>
> ...the index must be in sync with the head commit. The strategies are
> responsible to ensure this.
>
> However, Documentation/git-merge.txt says:
>
>
On Wed, Jun 6, 2018 at 10:06 PM, Elijah Newren wrote:
>
> I tend to think git-rebase--merge is less popular than the other rebase
> types, leading to it being more overlooked and less well tested than the
> other ones. This git-$cmd usage seems to support that argument.
>
> Anyway, this patch
Hi Leif,
On Mon, Jun 4, 2018 at 11:48 AM, Leif Middelschulte
wrote:
> From: Leif Middelschulte
>
> Since submodules are treated similarly to ordinary files (i.e. not as 'dumb'
> pointers), an automatic merge should be mentioned if the user asks for it.
> Just as it is mentioned for oridnary
Hi,
I noticed failures from the contrib/credential/netrc tests
while building 2.18.0 release candidates. I was surprised
to see the tests being run when called with a simple 'make'
command.
The first patch in the series adds an empty 'all::' make
target to match most of our other Makefiles and
Running "make" in contrib/credential/netrc should run the "all" target
rather than the "test" target. Add an empty "all::" target like most of
our other Makefiles.
Signed-off-by: Todd Zullinger
---
contrib/credential/netrc/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git
The netrc test.pl script calls git-credential-netrc which imports the
Git module. Pass GITPERLLIB to git-credential-netrc via PERL5LIB to
ensure the in-tree Git module is used for testing.
Signed-off-by: Todd Zullinger
---
contrib/credential/netrc/test.pl | 3 +++
1 file changed, 3
Hi,
Rick van Hattem wrote:
> On 4 June 2018 at 05:40, Junio C Hamano wrote:
>> Overlong line, lack of sign-off.
>
> Apologies for the long lines, I wrote the message on Github where this
> message is properly formatted, apparently the submitgit script can be
> considered broken as it truncates
We are not passing the same args to merge strategies when we are doing an
--interactive rebase as we do with a --merge rebase. The merge strategy
should not need to be aware of which type of rebase is in effect. Add a
testcase which checks for the appropriate args.
Signed-off-by: Elijah Newren
git-rebase.sh wrote stuff like
'--ours' '--renormalize'
to .git/rebase-merge/strategy_opts. Note the double spaces.
git-rebase--interactive uses sequencer.c to parse that file, and
sequencer.c used split_cmdline() to get the individual strategy options.
After splitting, sequencer.c prefixed
git rebase has three different types: am, merge, and interactive, all of
which are implemented in terms of separate scripts. am builds on git-am,
merge builds on git-merge-recursive, and interactive builds on
git-cherry-pick. We make use of features in those lower-level commands in
the different
Signed-off-by: Elijah Newren
---
git-rebase.sh | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 40be59ecc4..a56b286372 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -276,6 +276,7 @@ do
;;
--keep-empty)
git rebase is split into three types: am, merge, and interactive. Various
options imply different types, and which mode we are using determine which
sub-script (git-rebase--$type) is executed to finish the work. Not all
options work with all types, so add tests for combinations where we expect
I tend to think git-rebase--merge is less popular than the other rebase
types, leading to it being more overlooked and less well tested than the
other ones. This git-$cmd usage seems to support that argument.
Anyway, this patch may be irrelevant if others agree with my goal to
delete
Test 8 in t5407 appears to be an accidental exact duplicate of of test 5;
the testcode is identical and has identical repo state, but the test
description is different and suggests that rebase -m followed by rebase
--skip was what was actually supposed to be tested. Modify the test to
include the
Signed-off-by: Elijah Newren
---
apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index d79e61591b..85f2c92740 100644
--- a/apply.c
+++ b/apply.c
@@ -4053,7 +4053,7 @@ static int preimage_oid_in_gitlink_patch(struct patch *p,
struct object_id *oid)
Add a simple directory rename testcase, in conjunction with each of the
types of rebases:
git-rebase--interactive
git-rebase--am
git-rebase--merge
and also use the same testcase for
git am --3way
This demonstrates an inconsistency between the different rebase backends
and which can detect
Hi everyone,
We've got a small rebase problem; I'm curious for thoughts about the
best course of action. I'll provide several options below.
In short, while interactive-based and merge-based rebases handle
directory rename detection fine, am-based rebases do not. This
inconsistency may
On Wed, Jun 06, 2018 at 10:23:53PM -0400, Jeff King wrote:
> Though maybe I am wrong that the remote-svn stuff requires python. I
> thought it did, but poking around, it looks like it's all C, and just
> the "svnrdump_sim" helper is python.
I think I was getting this mixed up with the
On Thu, Jun 07, 2018 at 12:57:04AM +, brian m. carlson wrote:
> > > Unless I'm wrong, we don't use the "local" keyword ?
> >
> > We've got a test balloon out; see 01d3a526ad (t: check whether the
> > shell supports the "local" keyword, 2017-10-26). I think it's reasonable
> > to consider
On Wed, Jun 06, 2018 at 09:49:09PM -0400, Todd Zullinger wrote:
> Ramsay Jones wrote:
> [...]
> > I don't run the p4 or svn tests, so ... :-D
>
> Heh, lucky you. :)
>
> I try to run them all as part of the fedora builds since
> they cover much more than I'd ever use. That's the main
> reason I
On Thu, Jun 07, 2018 at 01:16:14AM +0100, Ramsay Jones wrote:
> > Probably. We may want to go the same route as we did for perl in
> > a0e0ec9f7d (t: provide a perl() function which uses $PERL_PATH,
> > 2013-10-28) so that test writers don't have to remember this.
> >
> > That said, I wonder if
Ramsay Jones wrote:
[...]
> I don't run the p4 or svn tests, so ... :-D
Heh, lucky you. :)
I try to run them all as part of the fedora builds since
they cover much more than I'd ever use. That's the main
reason I noticed the bare python. That would trip me up
when it came time to build on a
I'm going to take the risk of inserting actual real-world data into the mix
rather than just speculation :-)
Here is an example of that the Rsyslog project is doing (main developers based
in Germany). I'll say as someone who's day job has been very involved with GDPR
stuff recently, this
Am a United State Army here in Afghanistan, am seeking your help to evacuate
the sum of $ 7,000,000 to you as long as I am assured it will be safe That in
your care Until I complete my service here in Afghanistan. This is not stolen
money and there are no dangers involved. I count on your
On Wed, Jun 06, 2018 at 09:02:23AM +0200, Torsten Bögershausen wrote:
> Nothing wrong with the patch.
> There is, however, a trick in t0027 to transform the different IDs back to a
> bunch of '0'.
> The content of the file use only uppercase letters, and all lowercase ad
> digits
> are converted
On Wed, Jun 06, 2018 at 04:58:46PM -0400, Jeff King wrote:
> On Wed, Jun 06, 2018 at 08:19:27AM +0200, Torsten Bögershausen wrote:
>
> > > +test_translate_f_ () {
> > > + local file="$TEST_DIRECTORY/translate/$2" &&
> >
> > Unless I'm wrong, we don't use the "local" keyword ?
>
> We've got a
On 06/06/18 22:03, Jeff King wrote:
> On Wed, Jun 06, 2018 at 01:10:52PM -0400, Todd Zullinger wrote:
>
>> g...@jeffhostetler.com wrote:
>>> +# As a sanity check, ask Python to parse our generated JSON. Let Python
>>> +# recursively dump the resulting dictionary in sorted order. Confirm that
On Wed, Jun 06 2018, Timothy Rice wrote:
>> It does seem like something which could be noted in the git
>> rm docs. Perhaps you'd care to take a stab at a patch to
>> add a note to Documentation/git-rm.txt Thomas? Maybe a note
>> at the end of the DISCUSSION section?
>
> That same
On Wed, Jun 06 2018, Thomas Fischer wrote:
> I agree that the entire chain of empty directories should not be
> tracked, as git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/ to
> still exist.
>
> Similarly, when I run 'git rm
On 06/07, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Jun 06 2018, Brandon Williams wrote:
>
> > On 06/05, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Tue, Jun 05 2018, Brandon Williams wrote:
> >>
> >> > +uploadpack.allowRefInWant::
> >> > +If this option is set, `upload-pack` will
On Wed, Jun 06 2018, Brandon Williams wrote:
> On 06/05, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Tue, Jun 05 2018, Brandon Williams wrote:
>>
>> > +uploadpack.allowRefInWant::
>> > + If this option is set, `upload-pack` will support the `ref-in-want`
>> > + feature of the protocol version 2
On 06/05, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Jun 05 2018, Brandon Williams wrote:
>
> > +uploadpack.allowRefInWant::
> > + If this option is set, `upload-pack` will support the `ref-in-want`
> > + feature of the protocol version 2 `fetch` command.
> > +
>
> I think it makes sense to
On 6/6/2018 5:03 PM, Jeff King wrote:
On Wed, Jun 06, 2018 at 01:10:52PM -0400, Todd Zullinger wrote:
g...@jeffhostetler.com wrote:
+# As a sanity check, ask Python to parse our generated JSON. Let Python
+# recursively dump the resulting dictionary in sorted order. Confirm that
+# that
On 6/6/2018 1:10 PM, Todd Zullinger wrote:
g...@jeffhostetler.com wrote:
+# As a sanity check, ask Python to parse our generated JSON. Let Python
+# recursively dump the resulting dictionary in sorted order. Confirm that
+# that matches our expectations.
+test_expect_success PYTHON 'parse
On Wed, Jun 06, 2018 at 01:10:52PM -0400, Todd Zullinger wrote:
> g...@jeffhostetler.com wrote:
> > +# As a sanity check, ask Python to parse our generated JSON. Let Python
> > +# recursively dump the resulting dictionary in sorted order. Confirm that
> > +# that matches our expectations.
> >
On Wed, Jun 06, 2018 at 08:19:27AM +0200, Torsten Bögershausen wrote:
> > +test_translate_f_ () {
> > + local file="$TEST_DIRECTORY/translate/$2" &&
>
> Unless I'm wrong, we don't use the "local" keyword ?
We've got a test balloon out; see 01d3a526ad (t: check whether the
shell supports
Signed-off-by: Jonathan Tan
---
negotiator/default.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/negotiator/default.c b/negotiator/default.c
index b8f45cf78..a9e52c943 100644
--- a/negotiator/default.c
+++ b/negotiator/default.c
@@ -46,11 +46,10 @@ static
Reduce the number of global variables by making the priority queue and
the count of non-common commits in it local, passing them as a struct to
various functions where necessary.
This also helps in the case that fetch_pack() is invoked twice in the
same process (when tag following is required
Introduce the new files fetch-negotiator.{h,c}, which contains an API
behind which the details of negotiation are abstracted. Currently, only
one algorithm is available: the existing one.
This patch is written to be easily reviewed: static functions are
moved verbatim from fetch-pack.c to
If tag following is required when using a transport that does not
support tag following, fetch_pack() will be invoked twice in the same
process, necessitating a clearing of the object flags used by
fetch_pack() sometime during the second invocation. This is currently
done in find_common(), which
Thanks, Jonathan Nieder, for your comments.
This patch set now includes a patch at the beginning to split up
everything_local(), making it clear which functions have side effects
and which don't, and a patch at the end to reformat some comments.
While I was implementing the suggestions, there
When "ACK %s ready" is received, find_common() clears rev_list in an
attempt to stop further "have" lines from being sent [1]. It is much
more readable to explicitly break from the loop instead, so do this.
This means that the memory in priority queue will be reclaimed only upon
program exit,
The function everything_local(), despite its name, also (1) marks
commits as COMPLETE and COMMON_REF and (2) invokes filter_refs() as
important side effects. Extract (1) into its own function
(mark_complete_and_common_ref()) and remove
(2).
The restoring of save_commit_buffer, which was
In negotiation using protocol v2, fetch-pack sometimes does not make
full use of the information obtained in the ref advertisement:
specifically, that if the server advertises a commit that the client
also has, the client never needs to inform the server that it has the
commit's parents, since it
When receiving 'ACK continue' for a common commit, check if
the commit was already known to be common and mark it as such if not up
front. This should make future refactoring of how the information about
common commits is stored more straightforward.
No visible change intended.
Signed-off-by:
On Thu, 7 Jun 2018, Timothy Rice wrote:
> > It does seem like something which could be noted in the git
> > rm docs. Perhaps you'd care to take a stab at a patch to
> > add a note to Documentation/git-rm.txt Thomas? Maybe a note
> > at the end of the DISCUSSION section?
>
> That same
> It does seem like something which could be noted in the git
> rm docs. Perhaps you'd care to take a stab at a patch to
> add a note to Documentation/git-rm.txt Thomas? Maybe a note
> at the end of the DISCUSSION section?
That same documentation could mention a common workaround for when
On Wed, Jun 06, 2018 at 04:01:38PM -0400, Todd Zullinger wrote:
> Thomas Fischer wrote:
> > I agree that the entire chain of empty directories should not be tracked,
> > as git tracks content, not files.
> >
> > However, when I run 'rm path/to/some/file', I expect path/to/some/ to still
> >
Thomas Fischer wrote:
> I agree that the entire chain of empty directories should not be tracked, as
> git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/ to still
> exist.
>
> Similarly, when I run 'git rm path/to/some/file', I expect
On Wed, Jun 6, 2018 at 9:32 PM, Thomas Fischer
wrote:
> OVERVIEW
>
> "git rm" will remove more files than specified. This is either a bug or
> undocumented behavior (not in the man pages).
The behavior is intended, with a question mark. This change is
introduced in d9b814cc97 (Add builtin "git
On Wed, 6 Jun 2018, Thomas Fischer wrote:
> I agree that the entire chain of empty directories should not be
> tracked, as git tracks content, not files.
>
> However, when I run 'rm path/to/some/file', I expect path/to/some/
> to still exist.
why?
> Similarly, when I run 'git rm
I agree that the entire chain of empty directories should not be tracked, as
git tracks content, not files.
However, when I run 'rm path/to/some/file', I expect path/to/some/ to still
exist.
Similarly, when I run 'git rm path/to/some/file', I expect path/to/some/ to
exist, *albeit untracked*.
On Wed, May 30, 2018 at 2:47 AM, Stefan Beller wrote:
> diff --git a/object.c b/object.c
> index 4de4fa58d59..def3c71cac2 100644
> --- a/object.c
> +++ b/object.c
> @@ -177,7 +177,7 @@ void *object_as_type(struct object *obj, enum object_type
> type, int quiet)
> }
> }
>
> -struct
On Wed, 6 Jun 2018, Thomas Fischer wrote:
> OVERVIEW
>
> "git rm" will remove more files than specified. This is either a bug or
> undocumented behavior (not in the man pages).
>
> SETUP
>
> 1. In a git repository, create an empty directory OR a chain of empty
> directories
>
> $ mkdir -p
On Wed, May 30, 2018 at 2:48 AM, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> commit.c | 29 +++--
> commit.h | 2 ++
> object.c | 5 +
> object.h | 2 ++
> 4 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/commit.c b/commit.c
>
OVERVIEW
"git rm" will remove more files than specified. This is either a bug or
undocumented behavior (not in the man pages).
SETUP
1. In a git repository, create an empty directory OR a chain of empty
directories
$ mkdir -p path/to/some/
2. Create a file in the deepest directory and add
On Wed, May 30, 2018 at 2:47 AM, Stefan Beller wrote:
> Add a repository argument to allow the callers of lookup_tree
> to be more specific about which repository to act on. This is a small
> mechanical change; it doesn't change the implementation to handle
> repositories other than
On Wed, May 30, 2018 at 10:03 AM, Eric Sunshine wrote:
> Dscho recently implemented a 'tbdiff' replacement as a Git builtin named
> git-branch-diff[1] which computes differences between two versions of a
> patch series. Such a diff can be a useful aid for reviewers when
> inserted into a cover
On Tuesday 05 June 2018 09:01 PM, Duy Nguyen wrote:
> I'll leave it to submodule people to fix this :)
>
I'm Ccing the only one I know to gain attention.
--
Sivaraam
QUOTE:
“The three principal virtues of a programmer are Laziness, Impatience,
and Hubris.”
- Camel book
Sivaraam?
On Wed, Jun 6, 2018 at 1:18 PM, Anthony Sottile wrote:
> On Wed, Jun 6, 2018 at 10:17 AM, Eric Sunshine
> wrote:
>> On Wed, Jun 6, 2018 at 1:15 PM, Eric Sunshine
>> wrote:
>>> On Mon, Jun 4, 2018 at 4:17 PM, Anthony Sottile wrote:
+ for w in I am all CRLF; do echo $w; done |
On Wed, Jun 6, 2018 at 10:17 AM, Eric Sunshine wrote:
> On Wed, Jun 6, 2018 at 1:15 PM, Eric Sunshine wrote:
>> On Mon, Jun 4, 2018 at 4:17 PM, Anthony Sottile wrote:
>>> + for w in I am all CRLF; do echo $w; done | append_cr >allcrlf &&
>>
>> Simpler: printf "%s\n" I am all CRLF |
On Wed, Jun 6, 2018 at 1:15 PM, Eric Sunshine wrote:
> On Mon, Jun 4, 2018 at 4:17 PM, Anthony Sottile wrote:
>> + for w in I am all CRLF; do echo $w; done | append_cr >allcrlf &&
>
> Simpler: printf "%s\n" I am all CRLF | append_cr >allcrlf &&
Or even simpler:
printf "%s\r\n" I am all
On Mon, Jun 4, 2018 at 4:17 PM, Anthony Sottile wrote:
> A regression introduced in 8462ff43e42ab67cecd16fdfb59451a53cc8a945 caused
> autocrlf rewrites to produce a warning message despite setting safecrlf=false.
>
> Signed-off-by: Anthony Sottile
> ---
> diff --git a/t/t0020-crlf.sh
g...@jeffhostetler.com wrote:
> +# As a sanity check, ask Python to parse our generated JSON. Let Python
> +# recursively dump the resulting dictionary in sorted order. Confirm that
> +# that matches our expectations.
> +test_expect_success PYTHON 'parse JSON using Python' '
[...]
> + python
On 06/06, Nguyễn Thái Ngọc Duy wrote:
> Make some index API take an index_state instead of assuming the_index
> in read-cache.c. All external call sites are converted blindly to keep
> the patch simple and retain current behavior. Individual call sites
> may receive further updates to use the
Make the attr API take an index_state instead of assuming the_index in
attr code. All call sites are converted blindly to keep the patch
simple and retain current behavior. Individual call sites may receive
further updates to use the right index instead of the_index.
There is one ugly temporary
Signed-off-by: Nguyễn Thái Ngọc Duy
---
apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index fc42a0eadf..82f681972f 100644
--- a/apply.c
+++ b/apply.c
@@ -4090,7 +4090,7 @@ static int build_fake_ancestor(struct apply_state *state,
struct patch
Since attr checking API now take the index, there's no need to set an
index in advance with this call. Most call sites are straightforward
because they either pass the_index or NULL (which defaults back to
the_index previously). There's only one suspicious call site in
unpack-trees.c where it sets
Make some index API take an index_state instead of assuming the_index
in read-cache.c. All external call sites are converted blindly to keep
the patch simple and retain current behavior. Individual call sites
may receive further updates to use the right index instead of the_index.
Signed-off-by:
Signed-off-by: Nguyễn Thái Ngọc Duy
---
resolve-undo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/resolve-undo.c b/resolve-undo.c
index 383231b011..2377995d6d 100644
--- a/resolve-undo.c
+++ b/resolve-undo.c
@@ -1,3 +1,4 @@
+#define NO_THE_INDEX_COMPATIBILITY_MACROS
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pathspec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pathspec.c b/pathspec.c
index 897cb9cbbe..6f005996fd 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -37,7 +37,7 @@ void add_pathspec_matches_against_index(const struct pathspec
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/difftool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/difftool.c b/builtin/difftool.c
index fb2ccfe6f0..c7d6296762 100644
--- a/builtin/difftool.c
+++ b/builtin/difftool.c
@@ -321,7 +321,7 @@ static int
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/grep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 2eae397e92..a8cef2b159 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -497,7 +497,7 @@ static int grep_cache(struct grep_opt
Make the match_patchspec API and friends take an index_state instead
of assuming the_index in dir.c. All external call sites are converted
blindly to keep the patch simple and retain current behavior.
Individual call sites may receive further updates to use the right
index instead of the_index.
Make the convert API take an index_state instead of assuming the_index
in convert.c. All external call sites are converted blindly to keep
the patch simple and retain current behavior. Individual call sites
may receive further updates to use the right index instead of
the_index.
Signed-off-by:
write_eolinfo() does take an istate as function argument and it should
be used instead of the_index.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/ls-files.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index
checkout-index.c needs update because if checkout->istate is NULL,
ie_match_stat() will crash. Previously this is ie_match_stat(_index, ..)
so it will not crash, but it is not technically correct either.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout-index.c | 1 +
entry.c
While the_index is not actually a macro, its use throughout the code
base is dangerous because developers sometimes may not see that some
function is using the_index (instead of some other index that the devs
are interested in).
By keeping the_index part of this NO_ macro, we try to reduce its
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index d2257e0d82..4dbcab3727 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -230,7 +230,7 @@ static int
Signed-off-by: Nguyễn Thái Ngọc Duy
---
preload-index.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/preload-index.c b/preload-index.c
index d61d7662d5..cc2b579791 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2008 Linus
Signed-off-by: Nguyễn Thái Ngọc Duy
---
submodule.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/submodule.c b/submodule.c
index 955560bdbb..3aed76e3ee 100644
--- a/submodule.c
+++ b/submodule.c
@@ -93,7 +93,7 @@ int update_path_in_gitmodules(const char *oldpath,
Signed-off-by: Nguyễn Thái Ngọc Duy
---
convert.h | 56 ---
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/convert.h b/convert.h
index 01385d9288..0a0fa15b58 100644
--- a/convert.h
+++ b/convert.h
@@ -57,35 +57,36 @@ struct
On 06/06, Duy Nguyen wrote:
> On Wed, Jun 6, 2018 at 6:50 PM, Brandon Williams wrote:
> > On 06/06, Nguyễn Thái Ngọc Duy wrote:
> >> Make the attr API take an index_state instead of assuming the_index in
> >> attr code. All call sites are converted blindly to keep the patch
> >> simple and retain
Signed-off-by: Nguyễn Thái Ngọc Duy
---
attr.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/attr.h b/attr.h
index 442d464db6..46340010bb 100644
--- a/attr.h
+++ b/attr.h
@@ -42,31 +42,31 @@ struct attr_check {
struct attr_stack *stack;
On Wed, Jun 6, 2018 at 6:50 PM, Brandon Williams wrote:
> On 06/06, Nguyễn Thái Ngọc Duy wrote:
>> Make the attr API take an index_state instead of assuming the_index in
>> attr code. All call sites are converted blindly to keep the patch
>> simple and retain current behavior. Individual call
On 06/06, Nguyễn Thái Ngọc Duy wrote:
> Since attr checking API now take the index, there's no need to set an
> index in advance with this call. Most call sites are straightforward
> because they either pass the_index or NULL (which defaults back to
> the_index previously). There's only one
Both functions that are updated in this commit are called by
verify_absent(), which is part of the "unpack-trees" operation that is
supposed to work on any index file specified by the caller. Thanks to
Brandon [1] [2], an implicit dependency on the_index is exposed. This
commit fixes it.
In both
On 06/06, Nguyễn Thái Ngọc Duy wrote:
> Make the attr API take an index_state instead of assuming the_index in
> attr code. All call sites are converted blindly to keep the patch
> simple and retain current behavior. Individual call sites may receive
> further updates to use the right index
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..5d06aa9c98 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const
Prior to fba92be8f7, this code implicitly (and incorrectly) assumes
the_index when running the exclude machinery. fba92be8f7 helps show
this problem clearer because unpack-trees operation is supposed to
work on whatever index the caller specifies... not specifically
the_index.
Update the code to
This function mark_new_skip_worktree() has an argument named the_index
which is also the name of a global variable. While they have different
types (the global the_index is not a pointer) mistakes can easily
happen and it's also confusing for readers. Rename the function
argument to something
v4 fixes some commit messages and killed a couple more the_index
references after I tried to merge this with 'pu'
diff --git a/apply.c b/apply.c
index 811ff2ad5e..82f681972f 100644
--- a/apply.c
+++ b/apply.c
@@ -4090,9 +4090,9 @@ static int build_fake_ancestor(struct apply_state *state,
struct
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/unpack-trees.h b/unpack-trees.h
index c2b434c606..534358fcc5 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -82,8 +82,8 @@ struct unpack_trees_options {
On Tuesday 05 June 2018 04:54 PM, SZEDER Gábor wrote:
>
> Though arguably the test name could be more descriptive and tell why
> it should fail.
>
That's arguable, indeed. I was about to send a patch that gives a better
description for the test. I didn't do it as I started wondering, Is it
even
On Mon, Jun 04, 2018 at 01:17:42PM -0700, Anthony Sottile wrote:
> A regression introduced in 8462ff43e42ab67cecd16fdfb59451a53cc8a945 caused
> autocrlf rewrites to produce a warning message despite setting safecrlf=false.
>
> Signed-off-by: Anthony Sottile
> ---
> config.c| 2 +-
>
On 06/06/18 08:39, Nguyễn Thái Ngọc Duy wrote:
> Make the attr API take an index_state instead of assuming the_index in
> attr code. All call sites are converted blindly to keep the patch
> simple and retain current behavior. Individual call sites may receive
> further updates to use the right
On 6/6/2018 8:26 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Jun 06 2018, Derrick Stolee wrote:
On 6/6/2018 8:11 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Jun 06 2018, Derrick Stolee wrote:
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 39
On Wed, Jun 06 2018, Derrick Stolee wrote:
> On 6/6/2018 8:11 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Jun 06 2018, Derrick Stolee wrote:
>>
>>> Signed-off-by: Derrick Stolee
>>> ---
>>> builtin/commit-graph.c | 39 +--
>>> commit-graph.c |
On Wed, Jun 06 2018, Derrick Stolee wrote:
> diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
> index c0c1ff09b9..846396665e 100755
> --- a/t/t5318-commit-graph.sh
> +++ b/t/t5318-commit-graph.sh
> @@ -249,6 +249,15 @@ test_expect_success 'git commit-graph verify' '
>
>
1 - 100 of 163 matches
Mail list logo
