On 07/18/2014 12:10 AM, Jonathan Nieder wrote:
Hi,
Kyle J. McKay wrote:
When I then try to fetch using a "git://host/..." URL where "host"
is an mDNS host name, the 0010 patch causes git to attempt to lookup
a DNS SRV record on the non-mDNS regular DNS service (a violation of
RFC 6762 [4] sect
Using memset and then manually setting values of the string-list
members is not future proof as the internal representation of
string-list may change any time.
Use `string_list_init()` or STRING_LIST_INIT_* macros instead of
memset.
Signed-off-by: Tanay Abhra
---
builtin/commit.c | 3 +--
merge
The string-list API has STRING_LIST_INIT_* macros to be used
to define variables with initializers, but lacks functions
to initialize an uninitialized piece of memory to be used as
a string-list at the run-time.
Introduce `string_list_init()` function for that.
Signed-off-by: Tanay Abhra
---
Doc
Currently `git_config()` uses a callback mechanism and file rereads for
config values. Due to this approach, it is not uncommon for the config
files to be parsed several times during the run of a git program, with
different callbacks picking out different variables useful to themselves.
Add a `con
Expose the `config_set` C API as a set of simple commands in order to
facilitate testing. Add tests for the `config_set` API as well as for
`git_config_get_*()` family for the usual config files.
Signed-off-by: Matthieu Moy
Signed-off-by: Tanay Abhra
---
.gitignore| 1 +
Makefile
Hi,
[PATCH V11]: very minor fixes. check [13] for discussion.
[PATCH v10]: Minor fixes according to [12]. Re added string_list initializer
function.
Thanks to Junio and Matthieu for their suggestions.
[PATCH v9]: Applied most of the review comments mentioned in [11]. Mostly
asthetic ch
On Jul 18, 2014, at 17:19, Jonathan Nieder wrote:
Kyle J. McKay wrote:
On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:
"Git URLs" as described e.g. in git-clone(1) weren't intended to be
actual URIs.
According to RFC 3968 section 1.1.3:
"A URI can be further classified as a locator, a nam
Kyle J. McKay wrote:
> On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:
>> Kyle J. McKay wrote:
>>> You might also want to take a look at [1] which suggests that when
>>> doing SRV lookups for URLs they should be done regardless of whether
>>> or not a port number is present (which then eliminate
On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:
Kyle J. McKay wrote:
You might also want to take a look at [1] which suggests that when
doing SRV lookups for URLs they should be done regardless of whether
or not a port number is present (which then eliminates the RFC 3986
issue the current S
On Fri, Jul 18, 2014 at 09:14:05PM +0200, René Scharfe wrote:
> If inlining is really better is another matter; I don't understand how
> 1a812f3a (hashcmp(): inline memcmp() by hand to optimize) could have made
> git gc 18% faster, as it claimed. I would expect memcmp(), which can
> compare more
Hmm, the primary reason for this seems to be because you are going to handle
multiple refs at a time, some of them might fail to lock due to this
lowest-level
helper to unlink failing, some others may fail to lock due to some other reason,
and the user may want to be able to differentiate various m
Ronnie Sahlberg writes:
> Move the check for check_refname_format from lock_any_ref_for_update
> to lock_ref_sha1_basic. At some later stage we will get rid of
> lock_any_ref_for_update completely.
>
> If lock_ref_sha1_basic fails the check_refname_format test, set errno to
> EINVAL before return
Ronnie Sahlberg writes:
> We call read_ref_full with a pointer to flags from rename_ref but since
> we never actually use the returned flags we can just pass NULL here instead.
Sensible, at least for the current callers. I had to wonder if
rename_ref() would never want to take advantage of the
Ronnie Sahlberg writes:
> Signed-off-by: Ronnie Sahlberg
> ---
> git-compat-util.h | 6 ++
> wrapper.c | 18 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index b6f03b3..426bc98 100644
> --- a/git-compat-util.h
> +++
Ronnie Sahlberg writes:
> Signed-off-by: Ronnie Sahlberg
> ---
> wrapper.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/wrapper.c b/wrapper.c
> index bc1bfb8..740e193 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -429,14 +429,12 @@ int xmkstemp_mode(
Dennis Kaarsemaker writes:
> My use case for this is checking out the same branch (or commit, so
> already on a detached HEAD) in multiple different places to run
> independent actions (e.g. make test with different compiler options, or
> creating several different packages) and I would really ap
On vr, 2014-07-18 at 10:36 -0700, Junio C Hamano wrote:
> Michael J Gruber writes:
>
> > I really like the new --to feature and will convert all my "new workdir"
> > checkouts to that. But that detached checkout is so easy to miss - in fact
> > I noticed it only when I compared "new-workdir" to "
Junio C Hamano writes:
> Tanay Abhra writes:
>
>> +test_expect_success 'proper error on non-existant files' '
>> +echo "Error (-1) reading configuration file non-existant-file." >expect
>> &&
>
> s/tant/tent/ perhaps?
> cf. http://en.wiktionary.org/wiki/non-existant
It seems so. My bad.
>
Am 18.07.2014 23:18, schrieb Junio C Hamano:
René Scharfe writes:
Use the existing argv_array member instead of providing our own. This
way we don't have to initialize or clean it up explicitly. Because of
that automatic cleanup, we need to keep our own reference to the
command name instead
René Scharfe writes:
> Use the existing argv_array member instead of providing our own. This
> way we don't have to initialize or clean it up explicitly. Because of
> that automatic cleanup, we need to keep our own reference to the
> command name instead of using .argv[0] to print the warning a
Julián Landerreche writes:
>> By running "git pull", the user may obtain yet newer commits from
>> the upstream, which very likely will happen in an active project, or
>> "git fetch" launched by "git pull" will return without doing
>> anything after noticing there is nothing new.
>>
>> As long as
Julián Landerreche wrote:
> A more verbose, educational output could read:
>
> (use "git pull" to fetch newer commits from upstream and update your local
> branch)
> (use "git merge" to update your local branch)
Yes, I like this idea, with a few qualifications:
1. The first line is long.
Am 18.07.2014 15:08, schrieb Nguyễn Thái Ngọc Duy:
> diff --git a/lockfile.c b/lockfile.c
> index 8fbcb6a..a70d107 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -280,3 +280,19 @@ void rollback_lock_file(struct lock_file *lk)
> }
> lk->filename[0] = 0;
> }
> +
> +void make_locked_pa
Use the existing argv_array member instead of providing our own. This
way we don't have to initialize or clean it up explicitly. Because of
that automatic cleanup, we need to keep our own reference to the
command name instead of using .argv[0] to print the warning at the end.
Signed-off-by: Rene
> By running "git pull", the user may obtain yet newer commits from
> the upstream, which very likely will happen in an active project, or
> "git fetch" launched by "git pull" will return without doing
> anything after noticing there is nothing new.
>
> As long as the updates to the upstream is als
Am 18.07.2014 21:10, schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Use the existing argv_array member instead of providing our own. This
>> way we don't have to initialize or clean it up explicitly.
>>
>> Signed-off-by: Rene Scharfe
>> ---
>
> The change below looks so trivial and I ca
Julián Landerreche writes:
> when running "git status", if the current branch can be
> fast-forwarded, the user get this message:
>
> On branch master
> Your branch is behind 'origin/master' by 6 commits, and can be
> fast-forwarded.
> (use "git pull" to update your local branch)
>
> The
Am 18.07.2014 20:42, schrieb Jonathan Nieder:
René Scharfe wrote:
Signed-off-by: Rene Scharfe
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Before:
$ size git-fast-import
textdata bss dec hex filename
8041386768 754160 1565066
René Scharfe writes:
> Use the existing argv_array member instead of providing our own. This
> way we don't have to initialize or clean it up explicitly.
>
> Signed-off-by: Rene Scharfe
> ---
The change below looks so trivial and I cannot offhand see why it
would break t9020 in a reproducible
Hi,
when running "git status", if the current branch can be
fast-forwarded, the user get this message:
On branch master
Your branch is behind 'origin/master' by 6 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
The suggestion of using "git pull" for updat
Hello Karsten,
you wrote:
> However, if it *did* compile for you, I wonder where ALLOC_GROW (as of #02/13)
> and alloc_nr (as of #10/13) came from? Or did we recently remove '#include
> "cache.h"'
> from upstream mingw.c?
you are right, the include needs to be added.
To test my modifications, I
René Scharfe wrote:
> Signed-off-by: Rene Scharfe
> ---
> fast-import.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Before:
$ size git-fast-import
textdata bss dec hex filename
8041386768 754160 1565066 17e18a git-fast-import
After:
$ size git-fa
Karsten Blees writes:
> Am 17.07.2014 17:37, schrieb Stepan Kasal:
>> From: Johannes Schindelin
>>
>> The bash Git for Windows uses (i.e. the MSys bash) cannot pass
>> command-line arguments with high bits set verbatim to non-MSys programs,
>> but instead converts those characters with high bit
Nguyễn Thái Ngọc Duy writes:
> (alias R=$GIT_COMMON_DIR/repos/)
>
> - linked checkouts are supposed to keep its location in $R/gitdir up
>to date. The use case is auto fixup after a manual checkout move.
>
> - linked checkouts are supposed to update mtime of $R/gitdir. If
>$R/gitdir's m
Am 18.07.2014 15:02, schrieb Fredrik Gustafsson:
> On Fri, Jul 18, 2014 at 02:08:36PM +0200, Thomas Braun wrote:
>> Am 18.07.2014 12:14, schrieb Armbruster Joachim (BEG/EMS1):
>>> Hello,
>>>
>>> We split a monolithic repository into ~50 submodules. The stored data
>>> has the same size. In the 1:1
Nguyễn Thái Ngọc Duy writes:
> Locked paths are saved in a linked list so that if something wrong
> happens, *.lock are removed. This works fine if we keep cwd the same,
> which is true 99% of time except:
>
> - update-index and read-tree hold the lock on $GIT_DIR/index really
>early, then
Michael J Gruber writes:
> I really like the new --to feature and will convert all my "new workdir"
> checkouts to that. But that detached checkout is so easy to miss - in fact
> I noticed it only when I compared "new-workdir" to "checkout --to" for a
> test repo with one branch, to see what a co
Kyle J. McKay wrote:
> You might also want to take a look at [1] which suggests that when
> doing SRV lookups for URLs they should be done regardless of whether
> or not a port number is present (which then eliminates the RFC 3986
> issue the current SRV lookup code has).
"Git URLs" as described
Tanay Abhra writes:
> The string-list API has STRING_LIST_INIT_* macros to be used
> to define variables with initializers, but lacks functions
> to initialise an uninitialized piece of memory to be used as
> a string-list at the run-time.
> Introduce `string_list_init()` function for that.
>
> S
Hi,
Thanks for the patch. I've had this issue today
and the patch has fixed it. I hope the patch makes
its way to Git.
Ralf
> Hi Eric,
>
> thanks a lot for the reference.
>
> I added the Reported-by: and Signed-off-by: lines to the commit message.
>
>Fabian
>
> -- >8 --
> Subject: rebase
Tanay Abhra writes:
> +test_expect_success 'proper error on non-existant files' '
> + echo "Error (-1) reading configuration file non-existant-file." >expect
> &&
s/tant/tent/ perhaps?
cf. http://en.wiktionary.org/wiki/non-existant
> +test_expect_success 'proper error on non-accessible fil
Fabian Ruch writes:
> It makes the next patch easier to understand because the finalising
> command line "git commit --allow-empty --amend --no-post-rewrite -n
> --no-edit" seems to be simply moved to the end of do_pick. Substituting
> --no-edit for -C there would make that log message overly lon
Karsten Blees writes:
> Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
>> e.g. "git init". Make it static too to reduce stack usage.
>
> But wouldn't this increase overall memory usage? Stack memory
> will be reused by subsequent code, while static memory cannot
> be reused (but still increas
Signed-off-by: Rene Scharfe
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fast-import.c b/fast-import.c
index fa635f7..d73f58c 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2324,7 +2324,7 @@ static void file_change_m(const char *p, struct branch *b)
Use the existing argv_array member instead of providing our own. This
way we don't have to initialize or clean it up explicitly.
Signed-off-by: Rene Scharfe
---
remote-testsvn.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/remote-testsvn.c b/remote-testsvn.c
i
Use the existing argv_array member instead of building the arguments
list using a string array and a strbuf. This way we don't need magic
number constants and allocations are cleaned up for us automatically
by run_command().
Signed-off-by: Rene Scharfe
---
transport.c | 28 -
Am 18.07.2014 12:49, schrieb Duy Nguyen:
> On Fri, Jul 18, 2014 at 6:03 AM, Karsten Blees
> wrote:
>> Am 17.07.2014 19:05, schrieb René Scharfe:
>>> Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
>> [...]
>>> "These routines have traditionally been used by programs to save the
>>> name of a w
If a client certificate is required to connect to svn, "git svn branch"
always prompt the user for the certificate location and password,
even though those parameters are stored in svn file "server"
located in svn config dir (generally ~/.subversion).
On the opposite, "git svn info/init/dcommit" r
Hi.
On Fri, Jul 18, 2014 at 4:27 PM, Michael J Gruber
wrote:
> Duy Nguyen venit, vidit, dixit 18.07.2014 12:58:
>> This is what this series needs, user's opinions (bad or good).
Actually, if options "-b branch" works with the "--to" (does it?), then user
probably shouldn't need to create detache
Duy Nguyen venit, vidit, dixit 18.07.2014 12:58:
> On Fri, Jul 18, 2014 at 4:50 PM, Michael J Gruber
> wrote:
>> I really like the new --to feature and will convert all my "new workdir"
>> checkouts to that. But that detached checkout is so easy to miss - in fact
>> I noticed it only when I compar
Locked paths are saved in a linked list so that if something wrong
happens, *.lock are removed. This works fine if we keep cwd the same,
which is true 99% of time except:
- update-index and read-tree hold the lock on $GIT_DIR/index really
early, then later on may call setup_work_tree() to move
On Fri, Jul 18, 2014 at 02:08:36PM +0200, Thomas Braun wrote:
> Am 18.07.2014 12:14, schrieb Armbruster Joachim (BEG/EMS1):
> > Hello,
> >
> > We split a monolithic repository into ~50 submodules. The stored data
> > has the same size. In the 1:1 comparison to the monolithic
> > repository, the su
Hi Fabian
Impressive analysis!
> Concerning the bugfix: Obviously, the patch misuses the `squash_onto`
> flag because it assumes that the new base is empty except for the
> sentinel commit. The variable name does not imply anything close to
> that. An additional flag to disable the use of the git
Fabian Ruch writes:
> On 07/08/2014 10:45 PM, Junio C Hamano wrote:
>> Fabian Ruch writes:
>>> Fabian Ruch (19):
>>> rebase -i: Failed reword prints redundant error message
>>> rebase -i: reword complains about empty commit despite --keep-empty
>>> rebase -i: reword executes pre-commit hoo
Am 18.07.2014 12:14, schrieb Armbruster Joachim (BEG/EMS1):
> Hello,
>
> We split a monolithic repository into ~50 submodules. The stored data
> has the same size. In the 1:1 comparison to the monolithic
> repository, the submodule handling is very slow. Under Linux
> everything remains fast, but
Am 18.07.2014 01:03, schrieb Karsten Blees:
Am 17.07.2014 19:05, schrieb René Scharfe:
Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
[...]
"These routines have traditionally been used by programs to save the
name of a working directory for the purpose of returning to it. A much
faster and
On Fri, Jul 18, 2014 at 4:50 PM, Michael J Gruber
wrote:
> I really like the new --to feature and will convert all my "new workdir"
> checkouts to that. But that detached checkout is so easy to miss - in fact
> I noticed it only when I compared "new-workdir" to "checkout --to" for a
> test repo wi
On Fri, Jul 18, 2014 at 6:03 AM, Karsten Blees wrote:
> Am 17.07.2014 19:05, schrieb René Scharfe:
>> Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
> [...]
>> "These routines have traditionally been used by programs to save the
>> name of a working directory for the purpose of returning to it
Hello,
We split a monolithic repository into ~50 submodules. The stored data has the
same size. In the 1:1 comparison to the monolithic repository, the submodule
handling is very slow. Under Linux everything remains fast, but windows is slow.
So, why is git getting slow when it has to deal with
I think my proposal is a fix, and yours is a workaround. Semantically, calling
setup_git_directory changes the config, so it should invalidate the cache. Your
proposal consists in not filling-in the cache before it is invalidated, which
works, but isn't very future-proof: if anybody fills-in the
On Thu, Jul 17, 2014 at 5:37 PM, Stepan Kasal wrote:
> From: Pat Thoyts
>
> On Windows the application command line is provided as unicode and in
> mingw-git we convert that to utf-8. So these tests that require a iso-8859-1
> input are being subverted by the encoding transformations we perform a
On 7/18/2014 3:10 PM, Matthieu Moy wrote:
> - Original Message -
>> Documentation/technical/api-config.txt | 137 +
>> cache.h| 30
>> config.c | 263
>> +
>> 3 files chan
In a setup with more than 1 workdir, it can happen that a user requests
to checkout a branch that is already checked out somewhere else. The
current "hint" about this gives the impression that it is merely warning
about this fact.
Actually, "checkout" changes its behavior in such a situation from
- Original Message -
> Documentation/technical/api-config.txt | 137 +
> cache.h| 30
> config.c | 263
> +
> 3 files changed, 430 insertions(+)
I think the added call to g
Using memset and then manually setting values of the string-list
members is not future proof as the internal representation of
string-list may change any time.
Use `string_list_init()` or STRING_LIST_INIT_* macros instead of
memset.
Signed-off-by: Tanay Abhra
---
builtin/commit.c | 3 +--
merge
Expose the `config_set` C API as a set of simple commands in order to
facilitate testing. Add tests for the `config_set` API as well as for
`git_config_get_*()` family for the usual config files.
Signed-off-by: Matthieu Moy
Signed-off-by: Tanay Abhra
---
.gitignore| 1 +
Makefile
Currently `git_config()` uses a callback mechanism and file rereads for
config values. Due to this approach, it is not uncommon for the config
files to be parsed several times during the run of a git program, with
different callbacks picking out different variables useful to themselves.
Add a `con
The string-list API has STRING_LIST_INIT_* macros to be used
to define variables with initializers, but lacks functions
to initialise an uninitialized piece of memory to be used as
a string-list at the run-time.
Introduce `string_list_init()` function for that.
Signed-off-by: Tanay Abhra
---
Doc
Hi,
[PATCH v10]: Minor fixes according to [12]. Re added string_list initializer
function.
Thanks to Junio and Matthieu for their suggestions.
[PATCH v9]: Applied most of the review comments mentioned in [11]. Mostly
asthetic changes.
test-config now clears the config_set before
Hi Junio,
Junio C Hamano writes:
> Fabian Ruch writes:
>> The command line used to recreate root commits specifies the
>> effectless option `-C`. It is used to reuse commit message and
>> authorship from the named commit but the commit being amended here,
>> which is the sentinel commit, already
Hi Duy:
I tested your patch. It works. :)
(only one case.)
Thank you.
There are 26 hold_locked_index() in these files:
Line 475 of builtin\add.c
Line 4234 of \builtin\apply.c
Line 259 of \builtin\checkout.c
Line 448 of \builtin\checkout.c
Line 139 of \builtin\checkout-index.c
Line 643 of \
71 matches
Mail list logo
