On Wed, Oct 23, 2019 at 8:04 AM Denton Liu wrote:
> Currently, apply does not respect the merge.conflictStyle setting.
> Demonstrate this by making the 'apply with --3way' test case generic and
> extending it to show that the configuration of
> merge.conflictStyle = d
This fixes a bug where even if `merge.conflictStyle = diff3`, running
`git apply --3way` would not output the base.
Patches 1-3 are general cleanup for t4108, 4 demonstrates the bug and 5
actually fixes it.
Denton Liu (5):
t4108: replace create_file with test_write_lines
t4108: remove git
Currently, apply does not respect the merge.conflictStyle setting.
Demonstrate this by making the 'apply with --3way' test case generic and
extending it to show that the configuration of
merge.conflictStyle = diff3 causes a breakage.
Change print_sanitized_diff() to als
d-off-by: Denton Liu
---
apply.c | 2 +-
t/t4108-apply-threeway.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/apply.c b/apply.c
index f8a046a6a5..b9291f5f7b 100644
--- a/apply.c
+++ b/apply.c
@@ -32,7 +32,7 @@ static void git_apply_config(void)
{
git_con
%s:%d"),
>> state->patch_input_file, state->linenr);
>> }
>
> Do not forget that you can run "git apply" and feed the patch from
> its standard input, e.g.
>
> $ git apply$ git show -R | git apply
>
> Make sure state-&g
Junio C Hamano writes:
>> An alternate design was considered which involved printing the line
>> numbers relative to the output of `git am --show-current-patch` (in
>> other words, the actual mail file that's provided to am). This design
>> was not chosen because am does not store the whole mail
. This assumption, however,
> is incorrect. The line count really refers to the
> .git/rebase-apply/patch file genrated by am.
>
> Teach am to print the location of corrupted patch files so that users of
s/corrupted/corrupt/;
> the tool will know where to look when fixing their corr
count really refers to the
.git/rebase-apply/patch file genrated by am.
Teach am to print the location of corrupted patch files so that users of
the tool will know where to look when fixing their corrupted patch. Thus
the error message will look like this:
error: corrupt patch at .git/rebase-
directory of
the work tree, and neither is it inside the parent directory of
`GIT_DIR`.
This fixes the problem where `git stash apply` would report pretty much
everything deleted or untracked when run inside a worktree's
subdirectory.
To make sure that we do not introduce the "reverse
do stash quite often (now that git stash's performance is a joy on Windows).
Changes since v1:
* We now make sure to also set GIT_DIR.
Johannes Schindelin (1):
stash apply: report status correctly even in a worktree's subdirectory
builtin/stash.c | 4
t/t390
ee.sh
> > @@ -0,0 +1,27 @@
> > +#!/bin/sh
> > +#
> > +# Copyright (c) 2019 Johannes E Schindelin
> > +#
> > +
> > +test_description='Test git stash in a worktree'
> > +
> > +. ./test-lib.sh
> > +
> > +test_expec
b.sh
> +
> +test_expect_success 'setup' '
> + test_commit initial &&
> + git worktree add wt &&
> + test_commit -C wt in-worktree
> +'
> +
> +test_expect_success 'apply in subdirectory' '
> + mkdir wt/subd
tree, and
neither is it inside the parent directory of `GIT_DIR`.
This fixes the problem where `git stash apply` would report pretty much
everything deleted or untracked when run inside a worktree's
subdirectory.
Signed-off-by: Johannes Schindelin
---
builtin/stash.c | 2 ++
t
do stash quite often (now that git stash's performance is a joy on Windows).
Johannes Schindelin (1):
stash apply: report status correctly even in a worktree's subdirectory
builtin/stash.c | 2 ++
t/t3908-stash-in-worktree.sh | 27 +++
2 files c
Hi Eugen,
On Thu, 12 Sep 2019, Eugen Konkov wrote:
> $ git --version
> git version 2.20.1
First thing to try is whether Git v2.23.0 still exposes that bug.
Ciao,
Johannes
Hello Git,
Next commands cause the error:
$ git pull
fatal: It seems that there is already a rebase-apply directory, and
I wonder if you are in the middle of another rebase. If that is the
case, please try
git rebase (--continue | --abort | --skip)
If that is not the case, please
Johannes Schindelin writes:
> Hi Denton,
>
> On Wed, 4 Sep 2019, Denton Liu wrote:
>
>> After running Coccinelle on all sources inside compat/ that were created
>> by us[1], it was found that compat/mingw.c violated an array.cocci rule
>> in two places and, thus
Hi Denton,
On Wed, 4 Sep 2019, Denton Liu wrote:
> After running Coccinelle on all sources inside compat/ that were created
> by us[1], it was found that compat/mingw.c violated an array.cocci rule
> in two places and, thus, a patch was generated. Apply this patch so that
> all com
After running Coccinelle on all sources inside compat/ that were created
by us[1], it was found that compat/mingw.c violated an array.cocci rule
in two places and, thus, a patch was generated. Apply this patch so that
all compat/ sources created by us follows all cocci rules.
[1]: Do not run
In the procedure apply_or_revert_range_or_line, if the patch does not
apply successfully, a dialog is shown, but execution proceeds after
that. Instead, return early on error so the parts that come after this
don't work on top of an error state.
Signed-off-by: Pratyush Yadav
---
lib/dif
Phillip Wood writes:
> I spent some time digging into this and the attributes are reloaded
> before each pick. This is because check_updates() called by
> unpack_trees() calls git_attr_set_direction(GIT_ATTR_CHECKOUT) at the
> start of the function and git_attr_set_direction(GIT_ATTR_CHECKIN) at
On 20/08/2019 19:32, Phillip Wood wrote:
On 20/08/2019 19:24, Junio C Hamano wrote:
Phillip Wood writes:
Do you know why -m and -i aren't affected?
I had to look, but I believe the answer is because they use the
sequencer, and the sequencer calls git merge-recursive as a separate
process, a
Jeff King writes:
> This started with 8a0fc8d19d (stash: convert apply to builtin,
> 2019-02-25), which is in v2.22.0. Interestingly, do_stash_apply() does
> in fact call refresh_cache(). But it looks like we don't ever write it
> out to disk. So when we later call merg
ep 1; touch file" would work.
cp file other
mv other file
# now try to apply the stash
git stash apply
The final command gives me:
error: Your local changes to the following files would be overwritten by
merge:
file
Please commit your changes or stash them before you m
On 20/08/2019 19:24, Junio C Hamano wrote:
Phillip Wood writes:
Do you know why -m and -i aren't affected?
I had to look, but I believe the answer is because they use the
sequencer, and the sequencer calls git merge-recursive as a separate
process, and so the writing of the tree is only done
Phillip Wood writes:
>>> Do you know why -m and -i aren't affected?
>>
>> I had to look, but I believe the answer is because they use the
>> sequencer, and the sequencer calls git merge-recursive as a separate
>> process, and so the writing of the tree is only done in a subprocess,
>> which can't
On 20/08/2019 04:05, brian m. carlson wrote:
On 2019-08-19 at 09:55:27, Phillip Wood wrote:
On 19/08/2019 10:41, Phillip Wood wrote:
[...]
diff --git a/convert.c b/convert.c
index 94ff837649..030e9b81b9 100644
--- a/convert.c
+++ b/convert.c
@@ -1293,10 +1293,11 @@ struct conv_attrs {
c
Hi Brian
On 20/08/2019 03:45, brian m. carlson wrote:
On 2019-08-19 at 09:41:42, Phillip Wood wrote:
Hi Brian
On 18/08/2019 19:44, brian m. carlson wrote:
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
git
On 2019-08-19 at 09:55:27, Phillip Wood wrote:
> On 19/08/2019 10:41, Phillip Wood wrote:
> > [...]
> > > diff --git a/convert.c b/convert.c
> > > index 94ff837649..030e9b81b9 100644
> > > --- a/convert.c
> > > +++ b/convert.c
> > > @@ -1293,10 +1293,11 @@ struct conv_attrs {
> > > const char
On 2019-08-19 at 09:41:42, Phillip Wood wrote:
> Hi Brian
>
> On 18/08/2019 19:44, brian m. carlson wrote:
> > When applying multiple patches with git am, or when rebasing using the
> > am backend, it's possible that one of our patches has updated a
> > gitattributes file. Currently, we cache this
On 19/08/2019 10:41, Phillip Wood wrote:
[...]
diff --git a/convert.c b/convert.c
index 94ff837649..030e9b81b9 100644
--- a/convert.c
+++ b/convert.c
@@ -1293,10 +1293,11 @@ struct conv_attrs {
const char *working_tree_encoding; /* Supported encoding or
default encoding if NULL */
};
+
Hi Brian
On 18/08/2019 19:44, brian m. carlson wrote:
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
gitattributes file. Currently, we cache this information, so if a
file in a subsequent patch has attributes
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
gitattributes file. Currently, we cache this information, so if a
file in a subsequent patch has attributes applied, the file will be
written out with the attribute
On 2019-08-15 at 22:10:29, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "brian m. carlson" writes:
> >
> >> When applying multiple patches with git am, or when rebasing using the
> >> am backend, it's possible that one of our patches has updated a
> >> gitattributes file. Currently, we c
Junio C Hamano writes:
> "brian m. carlson" writes:
>
>> When applying multiple patches with git am, or when rebasing using the
>> am backend, it's possible that one of our patches has updated a
>> gitattributes file. Currently, we cache this information, so if a
>> file in a subsequent patch ha
On 2019-08-13 at 22:37:56, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > +test_expect_success 'rebase --am and .gitattributes' '
> > + test_create_repo attributes &&
> > + (
> > + cd attributes &&
> > + test_commit init &&
> > + test_config filter.test
"brian m. carlson" writes:
> +test_expect_success 'rebase --am and .gitattributes' '
> + test_create_repo attributes &&
> + (
> + cd attributes &&
> + test_commit init &&
> + test_config filter.test.clean "sed -e
> '\''s/smudged/clean/g'\''" &&
> +
ttributes applied, the file will be
> written out with the attributes in place as of the time we started the
> rebase or am operation, not with the attributes applied by the previous
> patch. This problem does not occur when using the -m or -i flags to
> rebase.
Back when "am"
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
gitattributes file. Currently, we cache this information, so if a
file in a subsequent patch has attributes applied, the file will be
written out with the attribute
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
gitattributes file. Currently, we cache this information, so if a
file in a subsequent patch has attributes applied, the file will be
written out with the attribute
On 2019-08-09 at 13:51:49, Jeff King wrote:
> On Fri, Aug 09, 2019 at 02:43:18PM +0200, SZEDER Gábor wrote:
> > But there is an other subtlety here: when I read the commit message
> > saying "patch that touches a path ending in ".gitattributes"." and saw
> > the new call to strip_path_suffix(), I i
On Fri, Aug 09, 2019 at 02:43:18PM +0200, SZEDER Gábor wrote:
> > I think you could do this with:
> >
> > size_t len;
> > if (strip_suffix(patch->new_name, GITATTRIBUTES_FILE, &len) &&
> > len > 0 && is_dir_sep(patch->new_name[len-1]))
> > flush_attributes = 1;
> >
> > Not su
On Fri, Aug 09, 2019 at 07:36:14AM -0400, Jeff King wrote:
> On Fri, Aug 09, 2019 at 11:25:52AM +, brian m. carlson wrote:
>
> > > > + if (!flush_attributes && patch->new_name) {
> > > > + char *dummy =
> > > > strip_path_suffix(patch->new_n
On 2019-08-09 at 11:36:14, Jeff King wrote:
> I think you could do this with:
>
> size_t len;
> if (strip_suffix(patch->new_name, GITATTRIBUTES_FILE, &len) &&
> len > 0 && is_dir_sep(patch->new_name[len-1]))
> flush_attributes = 1;
>
> Not sure if that is better or worse. It a
On Fri, Aug 09, 2019 at 11:25:52AM +, brian m. carlson wrote:
> > > + if (!flush_attributes && patch->new_name) {
> > > + char *dummy =
> > > strip_path_suffix(patch->new_name, GITATTRIBUTES_FILE);
> >
> > It's a shame that 'strip_path_suffix' doesn't
On 2019-08-09 at 11:14:52, Taylor Blau wrote:
> > diff --git a/apply.c b/apply.c
> > index cde95369bb..b959b88b8e 100644
> > --- a/apply.c
> > +++ b/apply.c
> > @@ -4643,6 +4643,7 @@ static int apply_patch(struct apply_state *state,
> > struct patch *list = NULL, **listp = &list;
> > int sk
Hi brian,
On Fri, Aug 09, 2019 at 10:02:17AM +, brian m. carlson wrote:
> When applying multiple patches with git am, or when rebasing using the
> am backend, it's possible that one of our patches has updated a
> gitattributes file. Currently, we cache this information, so if a
> file in a sub
When applying multiple patches with git am, or when rebasing using the
am backend, it's possible that one of our patches has updated a
gitattributes file. Currently, we cache this information, so if a
file in a subsequent patch has attributes applied, the file will be
written out with the attribute
I create 001.patch in dir, ceph_master
ceph_master
|--- .git
|--- src
|--- tools
|--- ...
local project directory:
storage
|---.git
|---ceph_**.*.**
|--- src
|--- tools
|--- ...
I'm trying to apply the patch, and git apply patch doesn't give me any errors.
like this
cd sto
Signed-off-by: simon gao
---
apply.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index 4992eca..47b16aa 100644
--- a/apply.c
+++ b/apply.c
@@ -2093,8 +2093,10 @@ static int use_patch(struct apply_state *state, struct
patch *p)
/* Paths outside
Signed-off-by: simon gao
---
apply.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/apply.c b/apply.c
index 4992eca..f66a6ff 100644
--- a/apply.c
+++ b/apply.c
@@ -2094,6 +2094,7 @@ static int use_patch(struct apply_state *state, struct
patch *p)
if (state->prefix && *state->prefix)
ruct strbuf *root,
+ int *linenr,
+ int p_value,
+ const char *line,
+ int len,
+ unsigned int size,
+ struct patch *patch);
+
/*
* Some aspects of the apply behavior are controlled by the following
* bits in the "options" parameter passed to apply_all_patches().
--
2.22.0.510.g264f2c817a
name(state->root, line, NULL, state->p_value,
TERM_TAB);
return 0;
}
@@ -949,7 +955,7 @@ static int gitdiff_verify_name(struct apply_state *state,
if (isnull)
return error(_("git apply: bad git-diff - expected
/dev/null, got %s
7 @@ static int gitdiff_verify_name(struct apply_state *state,
int side)
{
if (!*name && !isnull) {
- *name = find_name(state, line, NULL, state->p_value, TERM_TAB);
+ *name = find_name(&state->root, line
Currently the 'check_header_line()' function takes 'struct
apply_state' as parameter, even though it only needs the linenr from
that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
Currently the 'git_header_name()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only wa
Currently the 'skip_tree_prefix()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
public-inbox.org links include the whole message ID by default. This
means the message can still be found even if the site goes away, which
is not the case with the marc.info link. Replace the marc.info link
with a more future proof one.
Signed-off-by: Thomas Gummerer
---
apply.c | 2 +-
1 fil
On 07/09, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Maybe it would be even better to name it 'struct gitdiff_data', as
> > it's really only used for those few functions?
>
> Is it really the case where "these three are only used by the
> codepath you made public"? If so, I agree tha
Thomas Gummerer writes:
> Maybe it would be even better to name it 'struct gitdiff_data', as
> it's really only used for those few functions?
Is it really the case where "these three are only used by the
codepath you made public"? If so, I agree that "gitdiff_data" is a
perfectly good name for
d say 'parse_git_diff_header()' now, instead of
parse_git_header of course. Will fix that in the reroll.
> > Signed-off-by: Thomas Gummerer
> > ---
>
> Thanks for these refactoring patches on "apply" machinery in the
> early part of the series. I not
Thomas Gummerer writes:
> Make parse_git_header a "public" function in apply.h, so we can re-use
> it in range-diff in a subsequent commit.
>
> Signed-off-by: Thomas Gummerer
> ---
Thanks for these refactoring patches on "apply" machinery in the
early part
7 @@ static int gitdiff_verify_name(struct apply_state *state,
int side)
{
if (!*name && !isnull) {
- *name = find_name(state, line, NULL, state->p_value, TERM_TAB);
+ *name = find_name(&state->root, line
* Returns -1 on failure, the length of the parsed header otherwise.
+ */
+int parse_git_diff_header(struct strbuf *root,
+ int *linenr,
+ int p_value,
+ const char *line,
+ int len,
+
+ *name = find_name(state->root, line, NULL, state->p_value,
TERM_TAB);
return 0;
}
@@ -949,7 +955,7 @@ static int gitdiff_verify_name(struct apply_state *state,
if (isnull)
return error(_("gi
Currently the 'git_header_name()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only wa
Currently the 'check_header_line()' function takes 'struct
apply_state' as parameter, even though it only needs the linenr from
that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
Currently the 'skip_tree_prefix()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
public-inbox.org links include the whole message ID by default. This
means the message can still be found even if the site goes away, which
is not the case with the marc.info link. Replace the marc.info link
with a more future proof one.
Signed-off-by: Thomas Gummerer
---
apply.c | 2 +-
1 fil
Hi Thomas,
On Fri, 5 Jul 2019, Thomas Gummerer wrote:
> Currently the 'gitdiff_*()' functions take 'struct apply_state' as
> parameter, even though they only needs the root, linenr and p_value
> from that struct.
>
> These functions are in the callchain of 'parse_git_header()', which we
> want to
> + int *linenr,
> + int p_value,
> + const char *line,
> + int len,
> + unsigned int size,
> + struct patch *patch);
> +
> /*
> * Some aspects of the apply be
Currently the 'git_header_name()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only wa
7 @@ static int gitdiff_verify_name(struct apply_state *state,
int side)
{
if (!*name && !isnull) {
- *name = find_name(state, line, NULL, state->p_value, TERM_TAB);
+ *name = find_name(&state->root, line
Currently the 'check_header_line()' function takes 'struct
apply_state' as parameter, even though it only needs the linenr from
that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
public-inbox.org links include the whole message ID by default. This
means the message can still be found even if the site goes away, which
is not the case with the marc.info link. Replace the marc.info link
with a more future proof one.
Signed-off-by: Thomas Gummerer
---
apply.c | 2 +-
1 fil
Currently the 'skip_tree_prefix()' function takes 'struct apply_state'
as parameter, even though it only needs the p_value from that struct.
This function is in the callchain of 'parse_git_header()', which we
want to make more generally useful in a subsequent commit. To make
that happen we only w
name(state->root, line, NULL, state->p_value,
TERM_TAB);
return 0;
}
@@ -949,7 +955,7 @@ static int gitdiff_verify_name(struct apply_state *state,
if (isnull)
return error(_("git apply: bad git-diff - expected
/dev/null, got %s
int p_value,
+const char *line,
+int len,
+unsigned int size,
+struct patch *patch);
+
/*
* Some aspects of the apply behavior are controlled by the following
* bits in the "options" parameter passed to apply_all_patches().
--
2.22.0.510.g264f2c817a
On Thu, Apr 11, 2019 at 03:16:22PM -0400, Can Gemicioglu wrote:
> I noticed a problem when trying to apply a patch file that contained
> many separate patches in a single file.
To quote the first line of its manpage :) 'git apply' is meant to
"Apply a patch to files and/or
Hi,
I noticed a problem when trying to apply a patch file that contained many
separate patches in a single file. Trying to apply this patch gave me a "No
such file or directory" error for one of the files in the middle and after
looking around I realised this file was also created
> It fixes not just this issue, but now the whole test suite passes with
> GIT_TEST_FSMONITOR, i.e. this test that's been failing for ~2 years also
> works now:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubli
> c-
> inbox.org%2Fgit%2F87k1vwn9qe.fsf%40evledraar.gmail.com%2F
t; >> On Tue, Feb 26 2019, Thomas Gummerer wrote:
>> >>
>> >> > From: Joel Teichroeb
>> >> >
>> >> > Add a builtin helper for performing stash commands. Converting
>> >> > all at once proved hard to review, so starting with just ap
eichroeb
> >> >
> >> > Add a builtin helper for performing stash commands. Converting
> >> > all at once proved hard to review, so starting with just apply
> >> > lets conversion get started without the other commands being
> >> > finished
Hi folks,
The main purpose of `git apply --check` is to see if a patch can apply.
It's not intuitive to a user, just from the command name, that "no
output" means your patch can apply cleanly.
Furthermore, `git apply --check --verbose` only says that it is
checking the pat
h commands. Converting
>> > all at once proved hard to review, so starting with just apply
>> > lets conversion get started without the other commands being
>> > finished.
>> >
>> > The helper is being implemented as a drop in replacement for
&
Hi Ævar,
On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Feb 26 2019, Thomas Gummerer wrote:
>
> > From: Joel Teichroeb
> >
> > Add a builtin helper for performing stash commands. Converting
> > all at once proved hard to review, so starting with
On Tue, Feb 26 2019, Thomas Gummerer wrote:
> From: Joel Teichroeb
>
> Add a builtin helper for performing stash commands. Converting
> all at once proved hard to review, so starting with just apply
> lets conversion get started without the other commands being
> finished.
From: Joel Teichroeb
Add a builtin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
lets conversion get started without the other commands being
finished.
The helper is being implemented as a drop in replacement for
stash so that
We use the "def" parameter in find_name_common() for some heuristics,
but they are not necessary with the less-ambiguous GNU format. Let's
drop this unused parameter.
Signed-off-by: Jeff King
---
apply.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/apply.c b/apply.c
i
For some reason submodule.recurse applies to everything except clone.
Is there a reason for this strange inconsistency?
Cheers,
Tim
From: Joel Teichroeb
Add a builtin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
lets conversion get started without the other commands being
finished.
The helper is being implemented as a drop in replacement for
stash so that
Christian Halstrick writes:
> Question:
> - is this because the index which jgit created is so corrupt that only
> special commands
> like "git status" can repair it?
No.
> - or is "git apply" not trying hard enough to consume a index with
> smudg
I see that when I call "git apply --3way ..." on an index which was
previously created
by JGit and which contains smudged entries the command fails with
message "error: foo.txt:
does not match index". If I do a "git status" afterwards and then the
same "git a
Normally changes from git-apply are not worth logging because they
come from a file and can be recovered from there. This option will
mostly be used by add--interactive.pl where patches are generated
during an interactive add session and are very much worth logging.
The logging is a bit more
From: Joel Teichroeb
Add a builtin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
lets conversion get started without the other commands being
finished.
The helper is being implemented as a drop in replacement for
stash so that
On 2018.11.12 12:54, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> When editing patches e.g. in `git add -e`, it is quite common that a
> hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing.
>
> This use case was broken by a
From: Johannes Schindelin
When editing patches e.g. in `git add -e`, it is quite common that a
hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing.
This use case was broken by ad6e8ed37bc1 (apply: reject a hunk that does
not do anything, 2015-06-01) with the good intention
Jeff King writes:
> The options callback for "git apply --no-include" is not ready to handle
> the "unset" parameter, and as a result will segfault when it adds a NULL
> argument to the include list (likewise for "--no-exclude").
>
> In theory this mi
The option callback for "apply --whitespace" exits with status "1" on
error. It makes more sense for it to just return an error to
parse-options. That code will exit, too, but it will use status "129"
that is customary for option errors.
The exit() dates back to a
The options callback for "git apply --no-include" is not ready to handle
the "unset" parameter, and as a result will segfault when it adds a NULL
argument to the include list (likewise for "--no-exclude").
In theory this might be used to clear the list, but since b
1 - 100 of 1632 matches
Mail list logo