On Jul 17, 2014, at 19:22, Jonathan Nieder wrote:
Thanks for these details. I'll file a bug and mull it over some more.
RFC 6762 makes it clear that what the package is currently doing is
wrong. Given that Debian's libc knows nothing about mdns on its own,
I think I'll need to parse
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
Hi Junio,
Junio C Hamano writes:
Fabian Ruch baf...@gmail.com 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,
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
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
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 matthieu@imag.fr
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
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
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 tanay...@gmail.com
---
- 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
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
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 changed, 430
On Thu, Jul 17, 2014 at 5:37 PM, Stepan Kasal ka...@ucw.cz wrote:
From: Pat Thoyts pattho...@users.sourceforge.net
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
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
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
On Fri, Jul 18, 2014 at 6:03 AM, Karsten Blees karsten.bl...@gmail.com 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
On Fri, Jul 18, 2014 at 4:50 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
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
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
Fabian Ruch baf...@gmail.com writes:
On 07/08/2014 10:45 PM, Junio C Hamano wrote:
Fabian Ruch baf...@gmail.com 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
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
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 submodule
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
Duy Nguyen venit, vidit, dixit 18.07.2014 12:58:
On Fri, Jul 18, 2014 at 4:50 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
Hi.
On Fri, Jul 18, 2014 at 4:27 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
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 read
Am 18.07.2014 12:49, schrieb Duy Nguyen:
On Fri, Jul 18, 2014 at 6:03 AM, Karsten Blees karsten.bl...@gmail.com
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
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 l@web.de
---
transport.c | 28
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 l@web.de
---
remote-testsvn.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/remote-testsvn.c
Signed-off-by: Rene Scharfe l@web.de
---
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
Karsten Blees karsten.bl...@gmail.com 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
Fabian Ruch baf...@gmail.com 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
Tanay Abhra tanay...@gmail.com 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
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 -i:
Tanay Abhra tanay...@gmail.com 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
Michael J Gruber g...@drmicha.warpmail.net 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,
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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 comparison to
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
(alias R=$GIT_COMMON_DIR/repos/id)
- 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
Karsten Blees karsten.bl...@gmail.com writes:
Am 17.07.2014 17:37, schrieb Stepan Kasal:
From: Johannes Schindelin johannes.schinde...@gmx.de
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
René Scharfe wrote:
Signed-off-by: Rene Scharfe l@web.de
---
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:
$
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
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 updating
René Scharfe l@web.de 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 l@web.de
---
The change below looks so trivial and I cannot offhand see why it
would break
Am 18.07.2014 20:42, schrieb Jonathan Nieder:
René Scharfe wrote:
Signed-off-by: Rene Scharfe l@web.de
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Before:
$ size git-fast-import
textdata bss dec hex filename
8041386768
Julián Landerreche mani...@gmail.com 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)
Am 18.07.2014 21:10, schrieb Junio C Hamano:
René Scharfe l@web.de 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 l@web.de
---
The change below looks so
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 also a
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:
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
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. Is there
Julián Landerreche mani...@gmail.com 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
René Scharfe l@web.de 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
Am 18.07.2014 23:18, schrieb Junio C Hamano:
René Scharfe l@web.de 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
Junio C Hamano gits...@pobox.com writes:
Tanay Abhra tanay...@gmail.com 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
On vr, 2014-07-18 at 10:36 -0700, Junio C Hamano wrote:
Michael J Gruber g...@drmicha.warpmail.net 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
Dennis Kaarsemaker den...@kaarsemaker.net 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)
Ronnie Sahlberg sahlb...@google.com writes:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
Ronnie Sahlberg sahlb...@google.com writes:
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
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
Ronnie Sahlberg sahlb...@google.com 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
Ronnie Sahlberg sahlb...@google.com 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
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
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
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
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 eliminates the RFC
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 name,
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
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 tanay...@gmail.com
---
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
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
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 matthieu@imag.fr
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
70 matches
Mail list logo
