On Mon, Dec 30, 2013 at 10:07 PM, Sebastian Schuberth
sschube...@gmail.com wrote:
Since 2dce956 is_git_command() was a bit slow as it does file I/O in the
call to list_commands_in_dir(). Avoid the file I/O by adding an early
check for internal commands.
Signed-off-by: Sebastian Schuberth
On 02.01.2014 09:51, Christian Couder wrote:
diff --git a/builtin/help.c b/builtin/help.c
index b6fc15e..1f0261e 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -284,10 +284,15 @@ static int git_help_config(const char *var, const char
*value, void *cb)
return
This is the second iteration of the patches in
http://www.spinics.net/lists/git/msg222428.html
http://www.spinics.net/lists/git/msg222429.html
which
* adds a commit to use the term builtin instead of internal command,
* also modifies the docs accordingly,
* moves the is_builtin() declaration to
Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
call to list_commands_in_dir(). Avoid the file I/O by adding an early
check for internal commands.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/technical/api-builtin.txt | 4 +-
builtin.h
This avoids list_commands_in_dir() being called when not needed which is
quite slow due to file I/O in order to list matching files in a directory.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
builtin/help.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/technical/api-builtin.txt | 2 +-
git.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/technical/api-builtin.txt
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/technical/api-builtin.txt | 2 +-
Makefile| 1 +
builtin.c | 225 ++
builtin.h | 21 +++
git.c
help
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
See https://github.com/msysgit/git/pull/80.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
sha1_file.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index
On 02.01.2014 18:33, Johannes Schindelin wrote:
-- snip --
On Linux, we can get away with assuming that the directory separator is a
forward slash, but that is wrong in general. For that purpose, the
is_dir_sep() function was introduced a long time ago. By using it in
On Thu, Jan 02, 2014 at 07:11:42PM +0100, Sebastian Schuberth wrote:
On 02.01.2014 18:33, Johannes Schindelin wrote:
-- snip --
On Linux, we can get away with assuming that the directory separator is a
forward slash, but that is wrong in general. For that purpose, the
is_dir_sep()
Thanks for the comments, my replies below. Before, a couple of general
questions:
- I'm also writing some tests, should I commit them together with the
feature patch?
- to determine the attached/detached state I did this:
head_detached=
if test $(rev-parse --abbrev-ref HEAD) = HEAD
then
Jeff King p...@peff.net writes:
... But the test suite, of course, always uses askpass because it
cannot rely on accessing a terminal (we'd have to do some magic with
lib-terminal, I think).
So it doesn't detect the problem in your patch, but I wonder if it is
worth applying the patch below
Sebastian Schuberth sschube...@gmail.com writes:
Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
call to list_commands_in_dir(). Avoid the file I/O by adding an early
check for internal commands.
I think it is a good thing to check with the list of built-in's
first,
Sebastian Schuberth sschube...@gmail.com writes:
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
Documentation/technical/api-builtin.txt | 2 +-
Makefile| 1 +
builtin.c | 225 ++
Johannes Schindelin johannes.schinde...@gmx.de writes:
Hi,
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
See https://github.com/msysgit/git/pull/80.
Thanks Sebastian!
However, since the git.git project is not comfortable with the concept of
pull requests (which is why you submitted
Francesco Pretto cez...@gmail.com writes:
by default git submodule performs its add or update operations on a detached
HEAD. This works well when using an existing full-fledged/indipendent project
as
the submodule, as there's less frequent need to update it or commit back
changes. When the
Bernhard R. Link brl+...@mail.brlink.eu writes:
Allows to disable the git blame optimization of assuming that if there is a
parent of a merge commit that has the exactly same file content, then
only this parent is to be looked at.
I think this is what we usually call --full-history in git log
Hi,
Sebastian Schuberth wrote:
[...]
--- a/Documentation/technical/api-builtin.txt
+++ b/Documentation/technical/api-builtin.txt
@@ -14,7 +14,7 @@ Git:
. Add the external declaration for the function to `builtin.h`.
-. Add the command to `commands[]` table in
On 02.01.2014 19:18, John Keeping wrote:
That said, I see any further explanations on top of the commit message
title is an added bonus, and as just a bonus a link to a pull request
should be fine. You don't need to understand or appreciate the concept
of pull requests in order to follow the
Hi Junio,
On Thu, 2 Jan 2014, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
See https://github.com/msysgit/git/pull/80.
Thanks Sebastian!
However, since the git.git project is not comfortable with the
On Thu, Jan 2, 2014 at 9:31 PM, Jonathan Nieder jrnie...@gmail.com wrote:
would just leave me wondering I never claimed it was built-in; what's
going on? I think it would be simplest to keep it as
$ git whatever
fatal: cannot handle whatever internally
which at least makes
Sebastian Schuberth sschube...@gmail.com writes:
On 02.01.2014 20:55, Junio C Hamano wrote:
Thanks; the conclusion is correct --- you need a good commit
message in the recorded history. That does not have anything to do
with integrating with pulling from subsystem maintainers, which we
Hi,
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
When cloning to a directory C:\foo\bar from Windows' cmd.exe where foo
does not exist yet, Git would throw an error like
fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory
Fix this by not hard-coding a
Eric Sunshine sunsh...@sunshineco.com writes:
On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
[New Topics]
Would $gmane/239575 [1] be of interest
* Junio C Hamano gits...@pobox.com [140102 21:29]:
This optimization, while being faster in the usual case, means that in
the case of cherry-picks the blamed commit depends on which other commits
touched a file.
If for example one commit A modified both files b and c. And there are
Hi Junio,
On Thu, 2 Jan 2014, Junio C Hamano wrote:
If we are going to change the meaning of the function so that it can
now take any random path in platform-specific convention
Note that nothing in the function name or documentation suggests
otherwise.
that may be incompatible with the
Sebastian Schuberth sschube...@gmail.com writes:
When cloning to a directory C:\foo\bar from Windows' cmd.exe where foo
does not exist yet, Git would throw an error like
fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory
Fix this by not hard-coding a platform
On Thu, Jan 2, 2014 at 4:11 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano
Bernhard R. Link brl+...@mail.brlink.eu writes:
When giving git-blame the new option introduced with my patch, only
the order of parents determines which commit is blamed. Without
the option (i.e. the currently only possible behaviour) which commit
is blamed depends what else touches other
Junio C Hamano gits...@pobox.com writes:
This has a bit of conflict with another topic in flight; I think I
resolved it correctly, but please double check. The following is
how it would apply on top of 'pu'.
sha1_file.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff
db5360f3f496 (name-hash: refactor polymorphic index_name_exists();
2013-09-17) split index_name_exists() into index_file_exists() and
index_dir_exists() but retained index_name_exists() as a thin wrapper
to avoid disturbing possible in-flight topics. Since this change
landed in 'master' some time
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
This has a bit of conflict with another topic in flight; I think I
resolved it correctly, but please double check. The following is
how it would apply on top of 'pu'.
sha1_file.c | 9 +
1 file
Jeff King wrote:
On Mon, Dec 30, 2013 at 10:51:25AM -0800, Jonathan Nieder wrote:
These scratch areas for sub-tests should be under the t
trash directory, but because the TEST_OUTPUT_DIRECTORY
setting from the toplevel test leaks
[...]
This is not exactly true. The
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
On Mon, Dec 30, 2013 at 10:51:25AM -0800, Jonathan Nieder wrote:
These scratch areas for sub-tests should be under the t
trash directory, but because the TEST_OUTPUT_DIRECTORY
setting from the toplevel test leaks
2014/1/2 Junio C Hamano gits...@pobox.com:
Francesco Pretto cez...@gmail.com writes:
by default git submodule performs its add or update operations on a
detached
HEAD. This works well when using an existing full-fledged/indipendent
project as
the submodule, as there's less frequent need
Ramkumar Ramachandra artag...@gmail.com writes:
There are situations where two classes of completions possible. For
example
branch.TAB
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ., and the second/ third
Ramkumar Ramachandra artag...@gmail.com writes:
branch.*.*)
local pfx=${cur%.*}. cur_=${cur##*.}
+ if [ $pfx == branch.autosetupmerge. ] ||
+ [ $pfx == branch.autosetuprebase. ]; then
+ return
+ fi
On Dec 31, 2013, at 04:07, Kyle J. McKay wrote:
Since 64a99eb4 git gc refuses to run without the --force option if
another gc process on the same repository is already running.
However, if the repository is shared and user A runs git gc on the
repository and while that gc is still running user
When we have a remote-tracking branch named frotz/nitfol from a
previous fetch, and the upstream now has a branch named frotz. Prior
to this patch fetch would fail to remove frotz/nitfol with a git
fetch --prune from the upstream. git would inform the user to use git
remote prune to fix the
If fetch --prune is run with no new refs to fetch, but it has refs
to prune. Then, the header url is not printed as it would if there were
new refs to fetch.
Output before this patch:
$ git fetch --prune remote-with-no-new-refs
x [deleted] (none) - origin/world
Junio C Hamano gits...@pobox.com writes:
stephen_le...@stephe-leake.org writes:
However, in this case, even running the fetch was a mistake; I would
have prefered that it leave FETCH_HEAD in its previous state.
I think the clearing of leftover FETCH_HEAD is one of the early
things git
Junio C Hamano wrote:
If we are looking at branch.autosetupmerge. followed by something,
who typed that final dot?
I admit that it's a very unlikely case. The user did:
$ branch.autosetupmerTAB
hit backspace to delete the trailing space, inserted a dot, and hit TAB again.
If you are
Junio C Hamano wrote:
__gitcomp_nl $(__git_heads) $pfx $cur_ .
__gitcomp_nl_append $autosetupmerge\nautosetuprebase\n $pfx
$cur_
This is not a bad idea at all. I'm just afraid that we might be
leaving open ends: What happens if the $pfx isn't the same in both
cases? Who
44 matches
Mail list logo
