Way back in 92d4c85d24 (fsck-cache: fix SIGSEGV on bad tag object,
2005-05-03), we added an fsck check that the "tagged" field of a tag
struct isn't NULL. But that was mainly protecting the printing code for
"--tags", and that code wasn't moved along with the check as part of
ba002f3b28 (builtin-fs
In 4516338243 (builtin-fsck: reports missing parent commits,
2008-02-25), we added code to check that fsck found the same number of
parents from parsing the commit itself as we see in the commit struct we
got from parse_commit_buffer(). Back then the rationale was that the
normal commit parser migh
We check in fsck_commit_buffer() that commit->tree isn't NULL, which in
turn generally comes from a previous parse by parse_commit(). But this
isn't really accomplishing anything. The two things we might care about
are:
- was there a syntactically valid "tree " line in the object? But
we've
"Johannes Schindelin via GitGitGadget"
writes:
> ...
> Further reading on auto-generated `.manifest` files:
> https://docs.microsoft.com/en-us/cpp/build/manifest-generation-in-visual-studio
>
> Signed-off-by: Johannes Schindelin
> ---
> .gitignore | 1 -
> 1 file changed, 1 deletion(-)
Thanks.
From: Johannes Schindelin
On Windows, it is possible to embed additional metadata into an
executable by linking in a "manifest", i.e. an XML document that
describes capabilities and requirements (such as minimum or maximum
Windows version). These XML documents are expected to be stored in
`.manif
On Thu, Aug 29, 2019 at 08:22:49PM +0900, Mike Hommey wrote:
> It is possible to end up in situations where a replace ref points to
> itself. In that case, it would seem better to stop the lookup rather
> than try to follow the link infinitely and fail with "replace depth too
>
It is possible to end up in situations where a replace ref points to
itself. In that case, it would seem better to stop the lookup rather
than try to follow the link infinitely and fail with "replace depth too
high".
Signed-off-by: Mike Hommey
---
replace-object.c | 2 +-
1 file
Currently, there are two ways where the return codes of Git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no
Currently, there are two ways where the return codes of Git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no
Am 20.08.19 um 09:31 schrieb Denton Liu:
> Oops, this should read
>
> git_version="$(git --version >version && sed "s/.* //"
On Tue, Aug 20, 2019 at 03:19:08AM -0400, Denton Liu wrote:
> @@ -808,20 +821,24 @@ test_expect_success 'format-patch
> --ignore-if-in-upstream HEAD' '
> git format-patch --ignore-if-in-upstream HEAD
> '
>
> -git_version="$(git --version | sed "s/.* //")"
> +test_expect_success 'get git v
Currently, there are two ways where the return codes of Git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no
>> little confused how to
> >> determine a server response has ended. Specifically, after a client sends
> >> its requested 'want', the
> >> server sends the pack content over. However, how does the client know to
> >> stop reading data? If I
ed. Specifically, after a client sends
>> its requested 'want', the
>> server sends the pack content over. However, how does the client know to
>> stop reading data? If I
>> run a simple read() of the file descriptor:
>>
>> A. If I use reading blocking,
ever, how does the
> client know to stop reading data? If I run a simple read() of the
> file descriptor:
>
> A. If I use reading blocking, the client will wait until new data is
> available, potentially forever.
> B. If I use non-blocking, the client might terminate reading for n
content over.
> However, how does the client know to stop reading data? If I run a simple
> read() of the file descriptor:
>
> A. If I use reading blocking, the client will wait until new data is
> available, potentially forever.
> B. If I use non-blocking, the client might
Hi,
I am trying to write an implementation of git clone over ssh and am a little
confused how to determine a server response has ended. Specifically, after a
client sends its requested 'want', the server sends the pack content over.
However, how does the client know to stop reading
use after seeing that
> we have no configured git dir, we then fall back to discover_git_dir(),
> which happily reports back the same bogus $GIT_DIR.
>
> So I think there'd be some more cleanup required there. But the general
> direction is that in the near future we probably ou
.
So I think there'd be some more cleanup required there. But the general
direction is that in the near future we probably ought to be checking
startup_info->have_repository and not the_repository->gitdir.
But I think in the long-term, we probably ought to be getting rid of
startup_info-&
Since the previous commit, our invariant that the_repository is never
NULL is restored, and we can stop being defensive in include_by_branch().
We can confirm the fix by showing that an onbranch config include will
not cause a segfault when run outside a git repository. I've put this in
From: Johannes Schindelin
One test case's title mentioned the then-current implementation detail
that the `--am` backend was implemented in `git-rebase--am.sh`.
This is no longer the case, so let's update the title to reflect the
current reality.
Signed-off-by: Johannes Schindelin
Signed-off-b
We assume that if setup_traverse_info() is passed a non-empty "base"
string, that string is pointing into a tree object and we can read the
object oid by skipping past the trailing NUL.
As it turns out, this is not true for either of the two calls, and we
may end up reading garbage bytes:
1. In
On Fri, Jul 26, 2019 at 8:09 AM Ævar Arnfjörð Bjarmason
wrote:
>
> It will also implicitly re-enable UTF-8 validation for PCRE v1. As
> noted in [1] we now have cases as a result where PCRE v1 is more eager
> to error out. Subsequent patches will fix that for v2, and I think
> it's fair to tell v1
On Fri, Jul 26, 2019 at 8:08 AM Ævar Arnfjörð Bjarmason
wrote:
>
> As noted in [3] there are known regexes that will fail with the lower
> stack limit, the way GNU grep fixed it is interesting, although I
> believe the implementation is overly verbose, they could make PCRE v2
> handle that gradual
Simplify the PCRE v1 code for the same reasons as for the PCRE v2 code
in the last commit. Unlike with v2 we actually used the custom stack
in v1, but let's use PCRE's built-in 32 KB one instead, since
experience with v2 shows that's enough. Most distros are already using
v2 as a default, and the u
As reported in [1] the code I added in 94da9193a6 ("grep: add support
for PCRE v2", 2017-06-01) to use a custom JIT stack has never
worked. It was incorrectly copy/pasted from code I added in
fbaceaac47 ("grep: add support for the PCRE v1 JIT API", 2017-05-25),
which did work.
Thus our intention o
On Fri, Jul 26 2019, Carlo Arenas wrote:
> On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Fri, Jul 26 2019, Carlo Arenas wrote:
>>
>> > since this moves PCRE1 out of the JIT fast path,
>>
>> I think you're mostly replying to the wrong thread. None of the patches
>> I'
On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Fri, Jul 26 2019, Carlo Arenas wrote:
>
> > since this moves PCRE1 out of the JIT fast path,
>
> I think you're mostly replying to the wrong thread. None of the patches
> I've sent disable PCRE v1 JIT, as the performance numbers
On Fri, Jul 26 2019, Carlo Arenas wrote:
> since this moves PCRE1 out of the JIT fast path,
I think you're mostly replying to the wrong thread. None of the patches
I've sent disable PCRE v1 JIT, as the performance numbers show. The JIT
stack is resized, and for v2 some dead code removed.
> int
since this moves PCRE1 out of the JIT fast path, introduces the
regression where git grep will abort if there is binary data or non
UTF-8 text in the repository/log and should be IMHO hold out until a
fix for that can be merged.
this also needs additional changes to better support NO_LIBPCRE1_JIT,
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 storage/ceph_*
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)
On Wed, Jul 24, 2019 at 1:20 PM Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Jul 24 2019, Junio C Hamano wrote:
> >
> > Does everybody use pcre2 with JIT with Git these days, or only those
> > who want to live near the bleeding edge?
>
> My informal survey of various package recipies suggests that all
On Wed, Jul 24 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Since we've haven't had any reports of users running into
>> PCRE2_ERROR_JIT_STACKLIMIT in the wild I think we can safely assume
>> that we can just use the library defaults instead and drop this
>> code.
>
> Doe
Ævar Arnfjörð Bjarmason writes:
> Since we've haven't had any reports of users running into
> PCRE2_ERROR_JIT_STACKLIMIT in the wild I think we can safely assume
> that we can just use the library defaults instead and drop this
> code.
Does everybody use pcre2 with JIT with Git these days, or o
Simplify the PCRE v1 code for the same reasons as for the PCRE v2 code
in the last commit. Unlike with v2 we actually used the custom stack
in v1, but let's use PCRE's built-in 32 KB one instead, since
experience with v2 shows that's enough. Most distros are already using
v2 as a default, and the u
As reported in [1] the code I added in 94da9193a6 ("grep: add support
for PCRE v2", 2017-06-01) to use a custom JIT stack has never
worked. It was incorrectly copy/pasted from code I added in
fbaceaac47 ("grep: add support for the PCRE v1 JIT API", 2017-05-25),
which did work.
Thus our intention o
Change test code added in c0234b2ef6 ("stat_tracking_info(): clear
object flags used during counting", 2008-07-03) to stop using the
"script" variable also used for lazy prerequisites in
test-lib-functions.sh.
Since this test uses test_i18ncmp and expects to use its own "
Change test code added in c0234b2ef6 ("stat_tracking_info(): clear
object flags used during counting", 2008-07-03) to stop using the
"script" variable also used for lazy prerequisites in
test-lib-functions.sh.
Since this test uses test_i18ncmp and expects to use its own "
Ævar Arnfjörð Bjarmason writes:
> Change test code added in c0234b2ef6 ("stat_tracking_info(): clear
> object flags used during counting", 2008-07-03) to stop using the
> "script" variable also used for lazy prerequisites in
> test-lib-functions.sh.
>
>
Change test code added in c0234b2ef6 ("stat_tracking_info(): clear
object flags used during counting", 2008-07-03) to stop using the
"script" variable also used for lazy prerequisites in
test-lib-functions.sh.
Since this test uses test_i18ncmp and expects to use its own "
On Mon, May 20, 2019 at 11:53:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Remove a reference to git-cvsimport in the intro. As can be seen from
> the history of this command[1] it was originally intended for use with
> git-cvsimport, but how it uses it (and that it uses it at all) is
> irrelevant
Remove a reference to git-cvsimport in the intro. As can be seen from
the history of this command[1] it was originally intended for use with
git-cvsimport, but how it uses it (and that it uses it at all) is
irrelevant trivia at this point.
1. See 7672db20c2 ("[PATCH] Expose object ID computation f
<<< No Message Collected >>>
From: Johannes Schindelin
One test case's title mentioned the then-current implementation detail
that the `--am` backend was implemented in `git-rebase--am.sh`.
This is no longer the case, so let's update the title to reflect the
current reality.
Signed-off-by: Johannes Schindelin
---
t/t3400
Remove the mention of specific flags from the "gc" documentation, and
leave it at describing what we'll do instead. As seen in builtin/gc.c
we'll use various repack flags depending on what we detect we need to
do, so this isn't always accurate.
More importantly, a subsequent change is about to rem
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore") of
course do accept pathspec as before.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 20 ++
Remove the mention of specific flags from the "gc" documentation, and
leave it at describing what we'll do instead. As seen in builtin/gc.c
we'll use various repack flags depending on what we detect we need to
do, so this isn't always accurate.
More importantly, a subsequent change is about to rem
Remove the mention of specific flags from the "gc" documentation, and
leave it at describing what we'll do instead. As seen in builtin/gc.c
we'll use various repack flags depending on what we detect we need to
do, so this isn't always accurate.
More importantly, a subsequent change is about to rem
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore") of
course do accept pathspec as before.
---
builtin/checkout.c | 20 +++-
1 file changed, 15 ins
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore") of
course do accept pathspec as before.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 20 ++
quot;$HTTPD_ROOT_PATH"/error.log >&4 2>/dev/null
> > test_skip_or_die $GIT_TEST_HTTPD "web server setup failed"
> > fi
> > }
> >
> > stop_httpd() {
> > - trap 'die' EXIT
> > -
> > "$LIB_HT
Junio C Hamano writes:
> I see most of these changes are removal of stop_httpd because it is
> done as part of start_httpd() to arrange it to be called at exit.
>
> But ...
> ...
> ... I see we lost many "trap 'die' EXIT" in the orignal. Is that
> something we want to lose as part of this commit
t;&4
> if test $? -ne 0
> then
> - trap 'die' EXIT
> cat "$HTTPD_ROOT_PATH"/error.log >&4 2>/dev/null
> test_skip_or_die $GIT_TEST_HTTPD "web server setup failed"
> fi
>
Use 'test_atexit' to run cleanup commands to stop httpd at the end of
the test script or upon interrupt or failure, as it is shorter,
simpler, and more robust than registering such cleanup commands in the
trap on EXIT in the test scripts.
Signed-off-by: SZEDER Gábor
---
t/lib-
From: Johannes Schindelin
Use 'test_atexit' to run cleanup commands to stop 'git-daemon' at the
end of the test script or upon interrupt or failure, as it is shorter,
simpler, and more robust than registering such cleanup commands in the
trap on EXIT in the test scripts.
Not
Use 'test_atexit' to run cleanup commands to stop the credentials
helper at the end of the test script or upon interrupt or failure, as
it is shorter, simpler, and more robust than registering such cleanup
commands in the trap on EXIT in the test scripts.
Signed-off-by: SZEDER Gábor
--
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore") of
course do accept pathspec as before.
---
builtin/checkout.c | 20 +++-
1 file changed, 15 ins
This seems to never have been intentional, just a side-effect of how
the existing code was written.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/clone.c| 8 +++-
t/t5604-clone-reference.sh | 9 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/builti
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore") of
course do accept pathspec as before.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 20 ++
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore") of
course do accept pathspec as before.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 20 ++
Lowlevel callbacks have different function signatures. Add a new field
in 'struct option' with the right type for lowlevel callbacks.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/blame.c| 2 +-
builtin/merge.c| 2 +-
builtin/update-index.c | 11
This reverts commit a85e5a01080e35da0f94bf98f5f334c64e214ce3, which is a
revert of 0d260f9a09 (parseopt: prevent KEEP_UNKNOWN and
STOP_AT_NON_OPTION from being used together - 2009-03-09).
As described in 0d260f9a09, this option combination is tricky to get
right and should be prevented unless you
This reverts commit a85e5a01080e35da0f94bf98f5f334c64e214ce3, which is a
revert of 0d260f9a09 (parseopt: prevent KEEP_UNKNOWN and
STOP_AT_NON_OPTION from being used together - 2009-03-09).
As described in 0d260f9a09, this option combination is tricky to get
right and should be prevented unless you
On Thu, Jan 17, 2019 at 5:06 AM Nguyễn Thái Ngọc Duy wrote:
>
> These two are orthogonal. One is about unknown _option_ while the
> other non-option.
Though 0d260f9a09 ("parseopt: prevent KEEP_UNKNOWN and
STOP_AT_NON_OPTION from being used together", 2009-03-09)
seemed convincing to have this?
M
Lowlevel callbacks have different function signatures. Add a new field
in 'struct option' with the right type for lowlevel callbacks.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/blame.c| 2 +-
builtin/merge.c| 2 +-
builtin/update-index.c | 11 ++-
parse-options-cb.
These two are orthogonal. One is about unknown _option_ while the
other non-option.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
parse-options.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index eb5de0da29..678b263897 100644
--- a/parse-options.c
+++ b/pars
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Signed-off-by: Sergey Organov
---
t/t3510-ch
These two are orthogonal. One is about unknown _option_ while the
other non-option.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
parse-options.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index d47e217b07..4cbcefc262 100644
--- a/parse-options.c
+++ b/pars
Lowlevel callbacks have different function signatures. Add a new field
in 'struct option' with the right type for lowlevel callbacks.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/blame.c| 2 +-
builtin/merge.c| 2 +-
builtin/update-index.c | 11 ++-
parse-options-cb.
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Signed-off-by: Sergey Organov
---
t/t3510-ch
This command is about switching branch (or creating a new one) and
should not accept pathspec. This helps simplify ambiguation
handling. The other two ("git checkout" and "git restore-files") of
course do accept pathspec as before.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 14
Hi Peff,
On Thu, 22 Nov 2018, Jeff King wrote:
> On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
>
> > So YMMV with git-s. My rule of thumb is: if I want to use this
> > myself only, I'll make it an alias. If I want to ship it (e.g. with Git
> > for Windows), I'll make it a
On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
> > So it's maybe do-able, but not quite as trivial as one might hope.
>
> A trivial alternative would be to recommend adding a man page for
> 3rd-party git-s.
>
> In other words, as soon as `git-sizer` is accompanied by `git-s
Hi Peff,
On Sat, 17 Nov 2018, Jeff King wrote:
> On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> > So maybe we should just document this interface better. It seems one
> > implicit dependency is that we expect a manpage for the tool to exist
> > for --help.
>
> Yeah
On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
> So maybe we should just document this interface better. It seems one
> implicit dependency is that we expect a manpage for the tool to exist
> for --help.
Yeah, I think this really the only problematic assumption. The rest
On Fri, Nov 16 2018, Michael Haggerty wrote:
> On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason
> wrote:
>> [...]
>> A follow-up on this: We should really fix this for other
>> reasons. I.e. compile in some "this is stuff we ourselves think is in
>> git".
>>
>> There's other manifestati
On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason
wrote:
> [...]
> A follow-up on this: We should really fix this for other
> reasons. I.e. compile in some "this is stuff we ourselves think is in
> git".
>
> There's other manifestations of this, e.g.:
>
> git-sizer --help # => shows you
part of the Makefile,
>ideally we should do exactly the same thing there so also normal
>tests and not just GIT_TEST_INSTALLED (if that worked) would test
>in the same mode.
>
>I gave making that work a bit of a try and gave up in the Makef
Hi Ævar,
On Fri, 2 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> * GIT_TEST_INSTALLED breaks entirely under this, as early as the
>heuristic for "are we built?" being "do we have git-init in
>libexecdir?". I tried a bit to make this work, but there's a lot of
>dependencies there.
I hav
t
> them to be installed as (symlinks|hardlinks|copies), no fallbacks".
... If you're happy to accept a patch that rips out this whole
conditional fallback logic and just makes it an if/elsif/elsif for
symlink/hardlink/copy this makes things a lot easier.
>> Ævar Arnfjörð Bjarm
fallbacks".
> Ævar Arnfjörð Bjarmason (5):
> Makefile: move long inline shell loops in "install" into helper
> Makefile: conform some of the code to our coding standards
> Makefile: stop hiding failures during "install"
> Makefile
uld test
in the same mode.
I gave making that work a bit of a try and gave up in the Makefile
jungle.
Ævar Arnfjörð Bjarmason (5):
Makefile: move long inline shell loops in "install" into helper
Makefile: conform some of the code to our coding standards
Change the fallback mechanism where we try to create hardlinks and
ultimately fall back on a plain copy to emit the errors it encounters
instead of hiding them away and silently falling back to copying.
Hiding these errors dates back to 3e073dc561 ("Makefile: always
provide a fallback when hardlin
Hi,
On Tue, Sep 11, 2018 at 7:42 PM SZEDER Gábor wrote:
> Lately I noticed that occasionally I ended up with an empty commit
> message after an interactive rebase...those empty commit messages are the
> consequence of a regression in v2.19.0, which bisects down to this
> patch.
>
> To reproduce t
ages was a common error case for
> git-commit to deal with, it is a rare case for rebase (or cherry-pick).
> The fact that it is rare raises the question of why it would be worth
> checking and stopping on this particular condition and not others. For
> example, why doesn't an intera
Change "fetch" to treat "+" in refspecs (aka --force) to mean we
should clobber a local tag of the same name.
This changes the long-standing behavior of "fetch" added in
853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this
change, all tag fetches effectively had --force enabled. See t
Ævar Arnfjörð Bjarmason writes:
> +
> -Unlike when pushing with linkgit:git-push[1], any updates to
> -`refs/tags/*` will be accepted without `+` in the refspec (or
> -`--force`). The receiving promiscuously considers all tag updates from
> -a remote to be forced fetches.
> +Until Git version 2
Change "fetch" to treat "+" in refspecs (aka --force) to mean we
should clobber a local tag of the same name.
This changes the long-standing behavior of "fetch" added in
853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this
change, all tag fetches effectively had --force enabled. See t
When prepare_packed_git is called with the report_garbage method
initialized, we report unexpected files in the objects directory
as garbage. Stop reporting the multi-pack-index and the pack-files
it covers as garbage.
Signed-off-by: Derrick Stolee
---
packfile.c | 7 ---
1 file changed, 4
This commit checks for the file `applying` used by `git am` in
`rebase-apply/` and if the file is present it means `git am` is in
progress so it errors out.
Signed-off-by: Pratik Karki
---
builtin/rebase.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/builtin/rebase.c b/builtin/rebase
Ævar Arnfjörð Bjarmason writes:
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index 97d3217df9..5b624caf58 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -49,11 +49,16 @@ endif::git-pull[]
>
> -f::
> --force::
Change "fetch" to treat "+" in refspecs (aka --force) to mean we
should clobber a local tag of the same name.
This changes the long-standing behavior of "fetch" added in
853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20), before this
change all tag fetches effectively had --force enabled. See th
Error messages emitted by this linting script are long and noisy,
consisting of several sections:
:: error: :
Many problem explanations ask the reader to "please" use a suggested
alternative, however, such politeness is unnecessary and just adds to
the noise and length of the line, so drop "
On Tue, Jul 3, 2018 at 8:30 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > A singe patch conversion would look like below. But for that to
> > happen, convert.c, rerere, ws.c and read-cache.c have to be converted
> > first to not use the_index.
>
> Yes, that was pretty much what I was driv
Duy Nguyen writes:
> A singe patch conversion would look like below. But for that to
> happen, convert.c, rerere, ws.c and read-cache.c have to be converted
> first to not use the_index.
Yes, that was pretty much what I was driving at. I do not have any
trouble seeing a patch that converts call
On Mon, Jun 25, 2018 at 10:27:23AM -0700, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > Signed-off-by: Nguyễn Thái Ngọc Duy
> > ---
> > apply.c | 34 +++---
> > 1 file changed, 19 insertions(+), 15 deletions(-)
>
> Until all the codepaths that reach th
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> apply.c | 34 +++---
> 1 file changed, 19 insertions(+), 15 deletions(-)
Until all the codepaths that reach these callsites to index_*
functions from cmd_main() are converted to pass "struct
Signed-off-by: Nguyễn Thái Ngọc Duy
---
entry.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/entry.c b/entry.c
index 2101201a11..ec588289fb 100644
--- a/entry.c
+++ b/entry.c
@@ -421,7 +421,8 @@ int checkout_entry(struct cache_entry *ce,
if (!check_path(path.buf
1 - 100 of 492 matches
Mail list logo
