From: Nickolai Belakovski
lock_reason_valid is renamed to is_locked and lock_reason is removed as
a field of the worktree struct. Lock reason can be obtained instead by a
standalone function.
This is done in order to make the worktree struct more intuitive when it
is used elsewhere in the
The motivation for the change is some work that I'm doing to add a
worktree atom in ref-filter.c. I wanted that atom to be able to access
all fields of the worktree struct and noticed that lock_reason wasn't
getting populated so I figured I'd go and fix that.
I figured that since get_worktrees is
Uwe Kleine-König writes:
> Without passing --allow-unrelated-histories the command sequence
> fails as intended since commit e379fdf34fee ("merge: refuse to create
> too cool a merge by default"). To setup a subtree merging unrelated
> histories is normal, so add the option to the howto
On Mon, Oct 22, 2018 at 07:39:35PM +0200, SZEDER Gábor wrote:
> I don't really like how this or the previous RFC patch series deal
> with semantic patches (or how some past patch series dealt with them,
> for that matter), for various reasons:
> [..]
I am a little late to this thread, but it
"lhf...@163.com" writes:
> I have a good idea, add a file to git that is the opposite of .gitignore...,
Do negative patterns in .gitignore file help without inventing
anything new?
Carlo Marcelo Arenas Belón writes:
> sequencer.c: In function ‘write_basic_state’:
> sequencer.c:2392:37: warning: zero-length gnu_printf format string
> [-Wformat-zero-length]
>write_file(rebase_path_verbose(), "");
The change may squelch the above warning, but doesn't it change the
On Wed, Oct 24, 2018 at 12:55:33AM -0700, David Aguilar wrote:
> > So I think we should generally recommend against such generic names
> > during the naming phase. At this point, I'm not sure the pain of
> > changing now is any less than the pain of changing later if and when
> > there's a
Ramsay Jones writes:
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index f6f4c21a54..a2d1b8b116 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -2728,6 +2728,9 @@ rerere.enabled::
>> `$GIT_DIR`, e.g. if "rerere" was previously used
Eric Sunshine writes:
>> +test_commit 1 &&
>> +test_config user.useconfigonly true &&
>> +test_config stash.usebuiltin true &&
>> +sane_unset GIT_AUTHOR_NAME &&
>> +sane_unset GIT_AUTHOR_EMAIL &&
>> +sane_unset GIT_COMMITTER_NAME &&
>> +sane_unset GIT_COMMITTER_EMAIL
Slavica writes:
> On 23-Oct-18 8:52 PM, Christian Couder wrote:
>> On Tue, Oct 23, 2018 at 6:35 PM Slavica wrote:
>>> This is part of enhancement request that ask for `git stash` to work even
>>> if `user.name` is not configured.
>>> The issue is discussed here:
>>>
Johannes Schindelin writes:
>> HOME is set to TRASH_DIRECTORY in t/test-lib.sh already, and we do
>> so to avoid getting affected by the real $HOME/.gitconfig of the
>> user who happens to be running the test suite.
>
> My bad. I should have checked. I was under the impression that we set
>
Johannes Schindelin writes:
> On Wed, 24 Oct 2018, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>> > Changes since v1:
>> >
>> > * Fixed a grammar mistake in the second commit message.
>>
>> Thanks. I think this matches what I earlier queued on 'pu' with
Jeff King writes:
> I do hope that some options will just be no-brainers to enable always,
> though (e.g., I think in the long run commit-graph should just default
> to "on"; it's cheap to keep up to date and helps proportionally to the
> repo size).
Same here.
We should strive to make any
Duy Nguyen writes:
> The person who writes
>
> printf(_("%s"), getenv("foo"));
>
> may not go through the same thought process as with complexFunction().
> If _() calls getenv(), because you the order of parameter evaluation
> is unspecified, you cannot be sure if getenv("foo") will be called
>
When a requested feature cannot be activated because the version of
cURL library used to build Git with is too old, most of the codepaths
give a warning like "$Feature is not supported with cURL < $Version",
marked for l10n. A few of them, however, did not follow that pattern
and said things like
Eric Sunshine writes:
> On Mon, Oct 15, 2018 at 6:14 AM Brendan Forster via GitGitGadget
> wrote:
>> This config value is only used if http.sslBackend is set to "schannel",
>> which forces cURL to use the Windows Certificate Store when validating
>> server certificates associated with a remote
On Wed, Oct 24, 2018 at 7:41 PM brian m. carlson
wrote:
> diff --git a/sha256/block/sha256.h b/sha256/block/sha256.h
> new file mode 100644
> index 00..38f02f7e6c
> --- /dev/null
> +++ b/sha256/block/sha256.h
> @@ -0,0 +1,26 @@
> +#ifndef SHA256_BLOCK_SHA256_H
> +#define
Instead of using hard-coded constants for object sizes, use
the_hash_algo to look them up. In addition, use a function call to look
up the object ID version and produce the correct value. For now, we use
version 1, which means to use the default algorithm used in the rest of
the repository.
The transition plan anticipates us using a syntax such as "^{sha1}" for
disambiguation. Since this is a syntax some people will be typing a
lot, it makes sense to provide a short, easy-to-type syntax. Omitting
the dash doesn't create any ambiguity; however, it does make the syntax
shorter and
Generally, one gets better performance out of cryptographic routines
written in assembly than C, and this is also true for SHA-256. In
addition, most Linux distributions cannot distribute Git linked against
OpenSSL for licensing reasons.
Most systems with GnuPG will also have libgcrypt, since it
Add a utility (which is less for the testsuite and more for developers)
that can compute hash speeds for whatever hash algorithms are
implemented. This allows developers to test their personal systems to
determine the performance characteristics of various algorithms.
Signed-off-by: brian m.
This series provides a functional SHA-256 implementation and wires it
up, along with some housekeeping patches to make it suitable for
testing.
While I was fixing the macros, I wondered if I could make the code a bit
cleaner by using inline functions. I tried it and found that not only
did it
SHA-1 is weak and we need to transition to a new hash function. For
some time, we have referred to this new function as NewHash. Recently,
we decided to pick SHA-256 as NewHash.
Add a basic implementation of SHA-256 based off libtomcrypt, which is in
the public domain. Optimize it and
Since we're going to have multiple hash algorithms to test, it makes
sense to share as much of the test code as possible. Convert the sha1
helper for the test-tool to be generic and move it out into its own
module. This will allow us to share most of this code with our NewHash
implementation.
We have in the past had some unfortunate endianness issues with some
SHA-1 implementations we ship, especially on big-endian machines. Add
an explicit test using the test helper to catch these issues and point
them out prominently. This test can also be used as a staging ground
for people
In 183a638b7d ("hashcmp: assert constant hash size", 2018-08-23), we
modified hashcmp to assert that the hash size was always 20 to help it
optimize and inline calls to memcmp. In a future series, we replaced
many calls to hashcmp and oidcmp with calls to hasheq and oideq to
improve inlining
There are several ways we might refer to a hash algorithm: by name, such
as in the config file; by format ID, such as in a pack; or internally,
by a pointer to the hash_algos array. Provide functions to look up hash
algorithms based on these various forms and return the internal constant
used for
Currently, we have functions that turn an arbitrary SHA-1 value or an
object ID into hex format, either using a static buffer or with a
user-provided buffer. Add variants of these functions that can handle
an arbitrary hash algorithm, specified by constant. Update the
documentation as well.
We already have OpenSSL routines available for SHA-1, so add routines
for SHA-256 as well.
On a Core i7-6600U, this SHA-256 implementation compares favorably to
the SHA1DC SHA-1 implementation:
SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks)
SHA-256: 165 MiB/s (64 byte chunks); 408
There is one place we need the hash algorithm block size: the HMAC code
for push certs. Expose this constant in struct git_hash_algo and expose
values for SHA-1 and for the largest value of any hash.
Signed-off-by: brian m. carlson
---
cache.h | 4
hash.h | 3 +++
sha1-file.c | 2
I have a good idea, add a file to git that is the opposite of .gitignore,
whitelist, the code in the development directory can be submitted to git
version control, you can only submit the source code in the src directory,
without concern for development tools and operations.System and other
On Mon, Oct 22, 2018 at 11:54:06AM -0700, Stefan Beller wrote:
> For the sake of a good history, I would think running 'make coccicheck'
> and applying the resulting patches would be best as part of the (dirty)
> merge of any topic that proposes new semantic patches, but that would
> add load to
On 25/10/2018 02:09, Jeff King wrote:
> On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> but then you lose the default handling. I think if we added a new
>>> option, it would either be:
>>>
>>> # interpret a value directly; use default on empty,
Johannes Schindelin writes:
> On Wed, 24 Oct 2018, Jeff King wrote:
>
>> t5410 creates a sample script "alternate-refs", and sets
>> core.alternateRefsCommand to just "alternate-refs". That
>> shouldn't work, as "." is not in our $PATH, and so we should
>> not find it.
>>
>> However, due to a
Duy Nguyen writes:
> OK. Just to be sure we're on the same page. Am I waiting for all
> config changes to land in 'master', or do I rebase my series on
> 'next'? I usually base on 'master' but the mention of 'next' here
> confuses me a bit.
I was hoping that you can do something like:
$ git
On Thu, Oct 25, 2018 at 10:00:31AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > but then you lose the default handling. I think if we added a new
> > option, it would either be:
> >
> > # interpret a value directly; use default on empty, I guess?
> > git config --default=false
---
po/vi.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/vi.po b/po/vi.po
index bc79319b6..e646825ed 100644
--- a/po/vi.po
+++ b/po/vi.po
@@ -13663,7 +13663,7 @@ msgstr "Đánh số các đối tượng"
#: builtin/pack-objects.c:3382
#, c-format
msgid "Total % (delta %),
Jeff King writes:
> but then you lose the default handling. I think if we added a new
> option, it would either be:
>
> # interpret a value directly; use default on empty, I guess?
> git config --default=false --type=bool --interpret-value "$GIT_WHATEVER_ENV"
>
> or
>
> # less flexible,
sequencer.c: In function ‘write_basic_state’:
sequencer.c:2392:37: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
write_file(rebase_path_verbose(), "");
Signed-off-by: Carlo Marcelo Arenas Belón
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, Oct 24, 2018 at 11:48:20AM -0400, Derrick Stolee wrote:
> Generally, there are a lot of config settings that are likely in the "if you
> have a big repo, then you should use this" category. However, there is
> rarely a one-size-fits-all solution to these problems, just like there are
>
On Wed, Oct 24, 2018 at 09:37:43AM +0200, Johannes Schindelin wrote:
> Hi brian,
>
> On Wed, 24 Oct 2018, brian m. carlson wrote:
> > These lines strike me as a bit odd. As far as I'm aware, Unix systems
> > don't return anything useful in this field when calling fstat on a pipe.
> > Is there a
On Wed, Oct 24, 2018 at 4:06 PM Slavica Djukic
wrote:
> This is part of enhancement request that ask for 'git stash' to work
> even if 'user.name' and 'user.email' are not configured.
> Due to an implementation detail, git-stash undesirably requires
> 'user.name' and 'user.email' to be set, but
From: Slavica
This is part of enhancement request that ask for 'git stash' to work
even if 'user.name' and 'user.email' are not configured.
Due to an implementation detail, git-stash undesirably requires
'user.name' and 'user.email' to be set, but shouldn't.
The issue is discussed here:
Changes since v1:
*changed test title
*removed subshell and HOME override
*fixed weird identation
*unset() replaced with sane_unset()
Slavica (1):
[Outreachy] t3903-stash: test without configured user name
t/t3903-stash.sh | 13 +
1 file changed, 13 insertions(+)
If we have `submodule.diff = log' in the configuration file
or `--submodule=log' is given as argument, range-diff fails
to compare both diffs and we only get the following output:
Submodule a 000...000 (new submodule)
Even if the repository doesn't have any submodule.
That's because
On Wed, Oct 24 2018, Duy Nguyen wrote:
> On Tue, Oct 23, 2018 at 6:45 PM Ævar Arnfjörð Bjarmason
> wrote:
>> >> The effect of what I'm suggesting here, and which my WIP patch in
>> >> <875zxtd59e@evledraar.gmail.com> implements is that we'd do a
>> >> one-time getenv() for each process
On Wed, Oct 24, 2018 at 02:18:43PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Lucas De Marchi writes:
> >
> >> Your reply arrived just a little after I sent the v2, so I thought it
> >> was just the race and you would end up seeing the unread email in the
> >> same thread.
Signed-off-by: Denton Liu
---
Documentation/diff-config.txt | 8
Documentation/merge-config.txt | 6 ++
2 files changed, 14 insertions(+)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 85bca83c3..e64d983c3 100644
---
Signed-off-by: Denton Liu
Signed-off-by: Anmol Mago
Signed-off-by: Brian Ho
Signed-off-by: David Lu
Signed-off-by: Ryan Wang
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
In line with how difftool accepts a -g/--[no-]gui option, make mergetool
accept the same option in order to use the `merge.guitool` variable to
find the default mergetool instead of `merge.tool`.
Signed-off-by: Denton Liu
Signed-off-by: Anmol Mago
Signed-off-by: Brian Ho
Signed-off-by: David
This adds another patch on top of the existing patchset in order to document the
guitool keys for `git config`. This way, the completions script will now be able
to complete these key values as well.
Denton Liu (3):
mergetool: accept -g/--[no-]gui as arguments
completion: support `git
Hi,
On Wed, 24 Oct 2018, Johannes Schindelin wrote:
> On Wed, 24 Oct 2018, Junio C Hamano wrote:
>
> > Jonathan, do you see any issues with the use of lookup_commit() in
> > this change wrt lazy clone? I am wondering what happens when the
> > commit in question is at, an immediate parent of,
From: Johannes Schindelin
`git repack` can drop unreachable commits without further warning,
making the corresponding entries in `.git/shallow` invalid, which causes
serious problems when deepening the branches.
One scenario where unreachable commits are dropped by `git repack` is
when a `git
From: Johannes Schindelin
The `prune_shallow()` function wants a full reachability check to be
completed before it goes to work, to ensure that all unreachable entries
are removed from the shallow file.
However, in the upcoming patch we do not even want to go that far. We
really only need to
Under certain circumstances, commits that were reachable can be made
unreachable, e.g. via git fetch --prune. These commits might have been
packed already, in which case git repack -adlf will just drop them without
giving them the usual grace period before an eventual git prune (via git gc)
prunes
From: Johannes Schindelin
A `git fetch --prune` can turn previously-reachable objects unreachable,
even commits that are in the `shallow` list. A subsequent `git repack
-ad` will then unceremoniously drop those unreachable commits, and the
`shallow` list will become stale. This means that when
On 10/23/2018 4:03 PM, Ævar Arnfjörð Bjarmason wrote:
[snip]
The --ahead-behind config setting stalled on-list before:
https://public-inbox.org/git/36e3a9c3-f7e2-4100-1bfc-647b809a0...@jeffhostetler.com/
Now we have this similarly themed thing.
I think we need to be mindful of how changes like
In fact, per
https://github.com/git/git/commit/859b7f1d0e742493d2a9396794cd9040213ad846,
having only a negative pattern is like having a catch-all positive
pattern and the negative pattern (since git 2.13.0).
Thus, adding the positive pattern yields the same results:
> git --no-pager grep foo
Hi Junio,
On Wed, 24 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > Changes since v1:
> >
> > * Fixed a grammar mistake in the second commit message.
>
> Thanks. I think this matches what I earlier queued on 'pu' with
> Stephen's typofix squashed
Hi Junio,
On Wed, 24 Oct 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 24 Oct 2018, Junio C Hamano wrote:
> >
> >> Slavica writes:
> >>
> >> > +test_expect_failure 'stash with HOME as non-existing directory' '
> >> > +test_commit 1 &&
> >> > +test_config
On Wed, Oct 24, 2018 at 4:55 PM Christophe Bliard
wrote:
>
> Hi,
>
> I observed an unexpected behavior while using git grep with both git
> 2.19.1 and 2.14.3. Here is how to reproduce it:
>
> > git init
> Initialized empty Git repository in /private/tmp/hello/.git/
> > echo foo > fileA
> > echo
On Wed, Oct 24, 2018 at 2:16 PM rk42_gg wrote:
>
> Dear Git Developer,
>
> I have started translating Pro Git v2 book into Vietnamese at
> https://github.com/rocket42/progit2-vi
Great!
> Pls show me how to add it to "*Translations started for*" section in
> https://git-scm.com/book/en/v2
This
On Wed, Oct 24, 2018 at 4:56 AM Junio C Hamano wrote:
> How we should get there is a different story. I think Duy's series
> needs at least another update to move the split pieces into its own
> subdirectory of Documentation/, and it is not all that urgent, while
> this three-patch series (with
Hi,
I observed an unexpected behavior while using git grep with both git
2.19.1 and 2.14.3. Here is how to reproduce it:
> git init
Initialized empty Git repository in /private/tmp/hello/.git/
> echo foo > fileA
> echo 'foo is false+' > fileB
> git add fileA
> git commit -m fileA
[master
On Tue, Oct 23, 2018 at 8:47 PM Ben Peart wrote:
>
>
>
> On 10/22/2018 10:45 AM, Duy Nguyen wrote:
> > On Mon, Oct 22, 2018 at 3:38 PM Ben Peart wrote:
> >>
> >> From: Ben Peart
> >>
> >> Add a reset.quiet config setting that sets the default value of the --quiet
> >> flag when running the
On Tue, Oct 23, 2018 at 6:45 PM Ævar Arnfjörð Bjarmason
wrote:
> >> The effect of what I'm suggesting here, and which my WIP patch in
> >> <875zxtd59e@evledraar.gmail.com> implements is that we'd do a
> >> one-time getenv() for each process that prints a _() message that we
> >> aren't doing
On 23-Oct-18 8:52 PM, Christian Couder wrote:
On Tue, Oct 23, 2018 at 6:35 PM Slavica wrote:
This is part of enhancement request that ask for `git stash` to work even if
`user.name` is not configured.
The issue is discussed here:
On 10/21/2018 10:43 PM, brian m. carlson wrote:
Instead of using hard-coded constants for object sizes, use
the_hash_algo to look them up. In addition, use a function call to look
up the object ID version and produce the correct value. For now, we use
version 1, which means to use the default
On 10/23/2018 4:32 PM, Thomas Gummerer wrote:
On 10/22, René Scharfe wrote:
Am 22.10.2018 um 23:10 schrieb Thomas Gummerer:
Anyway, your implied question was discussed back then. Derrick wrote:
The reason to sort is to hopefully minimize the amount we walk by
exploring the "lower"
Ping, thanks.
--
tejun
Dear Git Developer,
I have started translating Pro Git v2 book into Vietnamese at
https://github.com/rocket42/progit2-vi
Pls show me how to add it to "*Translations started for*" section in
https://git-scm.com/book/en/v2
Thank you very much!
--
Full Name: Nguyễn Văn Hùng
On Tue, 16 Oct 2018 at 05:27, Junio C Hamano wrote:
>
> Luke Diamand writes:
>
> > This is the same as my earlier patch other than fixing the
> > documentation to reflect the change to the destination branch,
> > as noticed by Junio.
>
> Also you set up when-finished driver for clean-up before
Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
test parameter to only be a GIT_TEST_GETTEXT_POISON= runtime
parameter, to be consistent with other parameters documented in
"Running tests with special setups" in t/README.
When I added GETTEXT_POISON in bb946bba76 ("i18n: add
<>
Congratulation.docx
Description: Binary data
Hi everyone,
The 44th edition of Git Rev News is now published:
https://git.github.io/rev_news/2018/10/24/edition-44/
Enjoy,
Christian, Jakub, Markus and Gabriel.
"Johannes Schindelin via GitGitGadget"
writes:
> Changes since v1:
>
> * Fixed a grammar mistake in the second commit message.
Thanks. I think this matches what I earlier queued on 'pu' with
Stephen's typofix squashed in, so we are good already.
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 24 Oct 2018, Junio C Hamano wrote:
>
>> Slavica writes:
>>
>> > +test_expect_failure 'stash with HOME as non-existing directory' '
>> > +test_commit 1 &&
>> > +test_config user.useconfigonly true &&
>> > +test_config
On Wed, 24 Oct 2018 at 11:24, Junio C Hamano wrote:
> Andreas Gruenbacher writes:
> >> All other glob options do show_reference with for_each_ref_in() and
> >> then calls clear_ref_exclusion(), and logically the patch makes
> >> sense.
> >>
> >> What is the "problem" this patch fixes, though?
Hi Peff,
On Wed, 24 Oct 2018, Jeff King wrote:
> On Wed, Oct 24, 2018 at 11:01:54AM +0200, Johannes Schindelin wrote:
>
> > > @@ -910,6 +921,7 @@ int start_command(struct child_process *cmd)
> > > }
> > > #endif
> > >
> > > +end_of_spawn:
> >
> > Sadly, this fails to build on Windows:
> >
Andreas Gruenbacher writes:
>> All other glob options do show_reference with for_each_ref_in() and
>> then calls clear_ref_exclusion(), and logically the patch makes
>> sense.
>>
>> What is the "problem" this patch fixes, though? Is it easy to add a
>> new test to t/6018-rev-list-glob.sh to
From: Johannes Schindelin
When switching the current working directory, say, in PowerShell, it is
quite possible to use a different capitalization than the one that is
recorded on disk. While doing the same in `cmd.exe` adjusts the
capitalization magically, that does not happen in PowerShell so
On Windows, file names are recorded case-sensitively, but looked up
case-insensitively. Therefore, it is possible to switch to a directory by
using incorrect case, e.g. cd documentation will still get you into the
Documentation subdirectory.
In Powershell, doing so will however report the
From: Anton Serbulov
`GetLongPathName()` function may fail when it is unable to query
the parent directory of a path component to determine the long name
for that component. It happens, because it uses `FindFirstFile()`
function for each next short part of path. The `FindFirstFile()`
requires
Hi Stephen,
On Tue, 23 Oct 2018, Stephen & Linda Smith wrote:
> On Tuesday, October 23, 2018 3:52:49 AM MST you wrote:
> > From: Anton Serbulov
> >
> > `GetLongPathName()` function may fail when it is unable to query
> > the parent directory of a path component to determine the long name
> >
On Wed, Oct 24, 2018 at 11:01:54AM +0200, Johannes Schindelin wrote:
> > @@ -910,6 +921,7 @@ int start_command(struct child_process *cmd)
> > }
> > #endif
> >
> > +end_of_spawn:
>
> Sadly, this fails to build on Windows:
>
> run-command.c: In function 'start_command':
>
Hi Peff,
On Wed, 24 Oct 2018, Jeff King wrote:
> Since commit e3a434468f (run-command: use the
> async-signal-safe execv instead of execvp, 2017-04-19),
> prepare_cmd() does its own PATH lookup for any commands we
> run (on non-Windows platforms).
>
> However, its logic does not match the old
On Wed, 24 Oct 2018 at 06:35, Junio C Hamano wrote:
> Andreas Gruenbacher writes:
>
> > Commit [1] added the --exclude option to revision.c. The --all,
> > --branches, --tags, --remotes, and --glob options clear the exclude
> > list. Shortly therafter, commit [2] added the same to 'git
Hi Peff,
On Wed, 24 Oct 2018, Jeff King wrote:
> t5410 creates a sample script "alternate-refs", and sets
> core.alternateRefsCommand to just "alternate-refs". That
> shouldn't work, as "." is not in our $PATH, and so we should
> not find it.
>
> However, due to a bug in run-command.c, we
Hi Peff,
On Wed, 24 Oct 2018, Jeff King wrote:
> The upload_pack_config() callback uses an if/else chain
> like:
>
> if (!strcmp(var, "a"))
> ...
> else if (!strcmp(var, "b"))
> ...
> etc
>
> This works as long as the conditions are mutually exclusive,
> but one of them is not.
Hi Junio,
me again. I was wrong.
On Wed, 24 Oct 2018, Johannes Schindelin wrote:
> On Wed, 24 Oct 2018, Junio C Hamano wrote:
>
> > "Johannes Schindelin via GitGitGadget"
> > writes:
> >
> > > +...
> > > + d="$(git -C shallow-server rev-parse --verify D)" &&
> > > + git -C shallow-server
On Sat, Oct 20, 2018 at 08:47:35AM +0200, Christian Couder wrote:
> > Make “git tag –contains ” less chatty if is invalid
> > “git tag – contains ” prints the whole help text if is
> > invalid. It should only show the error message instead.
> > Thread:
> >
Hi Junio,
On Wed, 24 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > +...
> > + d="$(git -C shallow-server rev-parse --verify D)" &&
> > + git -C shallow-server checkout master &&
> > +
> > +...
> > + ! grep $d shallow-client/.git/shallow &&
>
>
On Wed, Oct 24, 2018 at 2:39 AM wrote:
> lock_reason is now populated during the execution of get_worktrees
>
> is_worktree_locked has been simplified, renamed, and changed to internal
> linkage. It is simplified to only return the lock reason (or NULL in case
> there is no lock reason) and to
Without passing --allow-unrelated-histories the command sequence
fails as intended since commit e379fdf34fee ("merge: refuse to create
too cool a merge by default"). To setup a subtree merging unrelated
histories is normal, so add the option to the howto document.
Signed-off-by: Uwe Kleine-König
Hi Junio,
On Wed, 24 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > diff --git a/builtin/repack.c b/builtin/repack.c
> > index c6a7943d5..9217fc832 100644
> > --- a/builtin/repack.c
> > +++ b/builtin/repack.c
> > @@ -549,6 +549,12 @@ int cmd_repack(int
Hi Junio & Jonathan,
On Wed, 24 Oct 2018, Junio C Hamano wrote:
> Jonathan, do you see any issues with the use of lookup_commit() in
> this change wrt lazy clone? I am wondering what happens when the
> commit in question is at, an immediate parent of, or an immediate
> child of a promisor
On Tue, Sep 18, 2018 at 02:22:22PM -0400, Jeff King wrote:
> On Mon, Sep 17, 2018 at 11:25:31AM +0200, Christian Couder wrote:
>
> > > (Also, to be clear, this is all _only_ about "Git Cola". The "git-cola"
> > > command is explicitly OK in the policy because that's how commands
> > > work).
> >
On Wed, Oct 24, 2018 at 02:45:49PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Notes on the implementation:
> >
> > * The only reason we need a new "git-sh-i18n--helper" and the
> >corresponding "test-tool gettext-poison" is to expose
> >git_env_bool() to
Hi Junio,
On Wed, 24 Oct 2018, Junio C Hamano wrote:
> Slavica writes:
>
> > +test_expect_failure 'stash with HOME as non-existing directory' '
> > +test_commit 1 &&
> > +test_config user.useconfigonly true &&
> > +test_config stash.usebuiltin true &&
> > +(
> > +
Since commit e3a434468f (run-command: use the
async-signal-safe execv instead of execvp, 2017-04-19),
prepare_cmd() does its own PATH lookup for any commands we
run (on non-Windows platforms).
However, its logic does not match the old execvp call when
we fail to find a matching entry in the PATH.
1 - 100 of 108 matches
Mail list logo
