RE: incorrect ssl directory set on git-scm

> From Jo zeve > > git-scm comes with ca-bundle.trust.crt and cert.pem, it currently (2.6.4) > assumes that they are stored in > > \mingw32\libexec\ssl\certs > \mingw32\libexec\ssl > > which is not true, they are in > > \mingw32\ssl\certs > \mingw32\ssl > The location of the CA certs is

Re: [PATCH] git-p4.py: add support for filetype change

On 21 December 2015 at 13:09, Romain Picard wrote: > After changing the type of a file in the git repository, it is not possible to > "git p4 publish" the commit to perforce. This is due to the fact that the git > "T" status is not handled in git-p4.py. This can

how to put existing git repo on web server

Hi, I hope this is the right mailing list to ask this: I have an existing git repo and I would like to make the repo available through my web server so that remote users can clone/fetch the repo. They don't need to commit. So far, I've found some documentation basically telling me to create a

bug: incorrect ssl directory set on git-scm

git-scm comes with ca-bundle.trust.crt and cert.pem, it currently (2.6.4) assumes that they are stored in \mingw32\libexec\ssl\certs \mingw32\libexec\ssl which is not true, they are in \mingw32\ssl\certs \mingw32\ssl -- To unsubscribe from this list: send the line "unsubscribe git" in the body

[PATCH 1/6] blame: remove obsolete comment

That "someday" in the comment happened two years later in b65982b (Optimize "diff-index --cached" using cache-tree - 2009-05-20) Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/blame.c | 5 - 1 file changed, 5 deletions(-) diff --git a/builtin/blame.c b/builtin/blame.c

[PATCH 3/6] apply: fix adding new files on i-t-a entries

Suppose that you came up with some contents to register at path F in your working tree, told Git about your intention with "add -N F", and then tried to apply a patch that wants to _create_ F: Without this patch, we would say "F already exists so a patch to create is incompatible with our current

[PATCH 2/6] Add and use convenient macro ce_intent_to_add()

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/rm.c | 2 +- cache-tree.c | 2 +- cache.h | 1 + read-cache.c | 4 ++-- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/builtin/rm.c b/builtin/rm.c index 3304bff..74a7a43 100644 --- a/builtin/rm.c +++

[PATCH 4/6] apply: make sure check_preimage() does not leave empty file on error

The test case probably describes the test scenario the best. We have a patch to modify some file but the base file is gone. Because check_preimage() finds an index entry with the same old_name, it tries to restore the on-disk base file with cached content with checkout_target() and move on. If

[PATCH 0/6] nd/ita-cleanup updates

Most of the updates are in commit message (see the old thread [1]). I give up on adding new tests for git-apply, finally admitting I don't know that command that well. Code change from 'pu' version is entirely in 5/6: diff --git a/builtin/checkout-index.c b/builtin/checkout-index.c index

[PATCH 5/6] checkout(-index): do not checkout i-t-a entries

The cached blob of i-t-a entries are empty blob. By checkout, we delete the content we have. Don't do it. This is done higher up instead of inside checkout_entry() because we would have limited options in there: silently ignore, loudly ignore, die. At higher level we can do better reporting. For

[PATCH 6/6] grep: make it clear i-t-a entries are ignored

The expression "!S_ISREG(ce)" covers i-t-a entries as well because ce->ce_mode would be zero then. I could make a comment saying that, but it's probably better just to comment with code, in case i-t-a entry content changes in future. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH] dir.c: clean the entire struct in clear_exclude_list()

Make sure "el" can be reuseable again. The problem was el->alloc is not cleared and may cause segfaults next time because add_exclude() thinks el->excludes (being NULL) has enough space. Just clear the entire struct to be safe. Signed-off-by: Nguyễn Thái Ngọc Duy --- This was

[RFC] git-send-email: do not double-escape quotes from mutt

mutt saves aliases with escaped quotes in the form of: alias dot \"Dot U. Sir\" When we pass through our sanitize_address routine, we end up with double-escaping: To: "\\\"Dot U. Sir\\\" Remove the escaping in mutt only for now, as

[PATCH v2 4/6] worktree: make core.sparseCheckout and core.ignoreStat per-worktree

The first one must be per-worktree because info/sparse-checkout already is. The second one shares the same nature and should also be per-worktree. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-worktree.txt | 2 +-

[PATCH v2 3/6] setup.c: remove special case of core.worktree and core.bare

core.worktree and core.bare, which are treated specially in 31e26eb [1], are now defined per-worktree with repo extension worktree=1 and the special treatment reverted. The test "$GIT_DIR/common overrides core.worktree" in t1501 from 31e26eb verifies that the behavior is still correct after this

[PATCH v2 2/6] config.c: move worktree-specific variables to .git/worktrees/...

In multiple worktree setup, a set of variables will be read from $GIT_DIR/worktrees//config instead of $GIT_DIR/config, when the config variables are accessed from a linked worktree. When accessed from the main worktree, the same set is still read from $GIT_DIR/config. This mechanism is needed

[PATCH v2 5/6] config.c: allow to un-share certain config in multi-worktree setup

Repo ext worktree=1 provides a set of config vars that _must_ be per-worktree. However, the user may want to make some more config vars per-worktree, depending on their workflow. include.path is extended to make this possible. If the given path is in the form "$GIT_xyz/abc" then "$GIT_xyz" will

[PATCH v2 1/6] Define new repo extension to manage multiple worktree behaviors

Multiple worktree setup is still evolving and its behavior may be changed in future. But we do not want to break existing worktree setups. A new set of extensions, worktree=X, is recognized to tell Git what multiple worktree "version" is being used so that Git can behavior accordingly. This

[PATCH v2 0/6] Split .git/config in multiple worktree setup

New design. We now define multiworktree behavior with config var extensions.worktree. Latest git must support all older behavior versions. If config file says "version 1", even if latest version is 3, git must behave like version 1. This covers all aspects of multi-worktree, not just config files.

[PATCH] worktree: stop supporting moving worktrees manually

The current update_linked_gitdir() has a bug that can create "gitdir" file in non-multi-worktree setup. Instead of fixing this, we step back a bit. The original design was probably not well thought out. For now, if the user manually moves a worktree, they have to fix up "gitdir" file manually or

[PATCH v2 6/6] worktree: bump worktree version to 1 on "worktree add"

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/worktree.c | 33 + 1 file changed, 33 insertions(+) diff --git a/builtin/worktree.c b/builtin/worktree.c index 475b958..2ec9c36 100644 --- a/builtin/worktree.c +++ b/builtin/worktree.c @@ -184,6