* [FOR DEBUGGING] Stop installing BUILT_INS
From: Steffen Prohaska @ 2008-07-29 5:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <1217308647-23673-1-git-send-email-prohaska@zib.de>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b2bc0ef..e416ec7 100644
--- a/Makefile
+++ b/Makefile
@@ -1366,7 +1366,7 @@ endif
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
- { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+ { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" ;) } && \
$(RM) "$$execdir/git$X" && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Steffen Prohaska @ 2008-07-29 5:17 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <BF5B7CBE-ACA8-4D81-8FC0-8A7901205854@zib.de>
We prefer running the dashless form, so we should use it in MinGW's
start_command(), too.
This solves a fundamental problem we have with the computation of system
directories based on relative paths in combination with the new
gitexecpath 'libexec/git-core'. The problem is that the program 'git'
is hardlinked to directories with different depth. It is either used as
'bin/git' (1 directory) or as 'libexec/git-core/git-*' (2 directories).
Thus, using the same relative path in system_path() yields different
results when starting from the two locations. I recognized the problem
because /etc/gitconfig is no longer read.
This commit fixes the problem by always calling 'bin/git' for builtin
commands. The computation in system_path() thus always starts from
'bin' and yields predictable results. This is however only part of a
full solution to the problem outlined above. Remaining problems are:
- Other code paths might run the dashed forms directly.
- We have non-builtins that are implemented in C, e.g. fast-import.c.
These non-builtins will still compute wrong paths.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
---
run-command.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/run-command.c b/run-command.c
index 6e29fdf..a3b28a6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -119,9 +119,8 @@ int start_command(struct child_process *cmd)
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
- const char *sargv0 = cmd->argv[0];
+ const char **sargv = cmd->argv;
char **env = environ;
- struct strbuf git_cmd;
if (cmd->no_stdin) {
s0 = dup(0);
@@ -165,9 +164,7 @@ int start_command(struct child_process *cmd)
}
if (cmd->git_cmd) {
- strbuf_init(&git_cmd, 0);
- strbuf_addf(&git_cmd, "git-%s", cmd->argv[0]);
- cmd->argv[0] = git_cmd.buf;
+ cmd->argv = prepare_git_cmd(cmd->argv);
}
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env);
@@ -175,9 +172,9 @@ int start_command(struct child_process *cmd)
if (cmd->env)
free_environ(env);
if (cmd->git_cmd)
- strbuf_release(&git_cmd);
+ free(cmd->argv);
- cmd->argv[0] = sargv0;
+ cmd->argv = sargv;
if (s0 >= 0)
dup2(s0, 0), close(s0);
if (s1 >= 0)
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-29 5:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <7vabg2wovf.fsf@gitster.siamese.dyndns.org>
Le lundi 28 juillet 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > +static struct commit *get_commit_reference(const char *arg)
> > +{
> > + unsigned char revkey[20];
> > + if (get_sha1(arg, revkey))
> > + die("Not a valid object name %s", arg);
> > + return lookup_commit_reference(revkey);
> > +}
>
> This returns a NULL when you feed a tree to the command, and...
>
> > int cmd_merge_base(int argc, const char **argv, const char *prefix)
> > {
> > + struct commit **rev;
> > int show_all = 0;
> > + int rev_nr = 0;
> >
> > git_config(git_default_config, NULL);
> >
> > @@ -38,15 +48,18 @@ int cmd_merge_base(int argc, const char **argv,
> > const char *prefix) usage(merge_base_usage);
> > argc--; argv++;
> > }
> > + if (argc < 3)
> > usage(merge_base_usage);
> > +
> > + rev = xmalloc((argc - 1) * sizeof(*rev));
> > +
> > + do {
> > + struct commit *r = get_commit_reference(argv[1]);
> > + if (!r)
> > + return 1;
>
> ... the command silently exits with 1.
In "master" there is:
rev1 = lookup_commit_reference(rev1key);
rev2 = lookup_commit_reference(rev2key);
if (!rev1 || !rev2)
return 1;
return show_merge_base(rev1, rev2, show_all);
so I think you found a bug in the current code.
I will post a patch to fix it soon.
It will "die" (with an error ùmessage) in case "lookup_commit_reference"
returns NULL. I hope it's ok.
Thanks,
Christian.
^ permalink raw reply
* [FOR DEBUGGING] Stop installing BUILT_INS
From: Steffen Prohaska @ 2008-07-29 5:19 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <1217308784-25408-1-git-send-email-prohaska@zib.de>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b2bc0ef..e416ec7 100644
--- a/Makefile
+++ b/Makefile
@@ -1366,7 +1366,7 @@ endif
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
- { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+ { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" ;) } && \
$(RM) "$$execdir/git$X" && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Steffen Prohaska @ 2008-07-29 5:19 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <766FEC61-619E-4A13-A21B-0734D83074C5@zib.de>
We prefer running the dashless form, so we should use it in MinGW's
start_command(), too.
This solves a fundamental problem we have with the computation of system
directories based on relative paths in combination with the new
gitexecpath 'libexec/git-core'. The problem is that the program 'git'
is hardlinked to directories with different depth. It is either used as
'bin/git' (1 directory) or as 'libexec/git-core/git-*' (2 directories).
Thus, using the same relative path in system_path() yields different
results when starting from the two locations. I recognized the problem
because /etc/gitconfig is no longer read.
This commit fixes the problem by always calling 'bin/git' for builtin
commands. The computation in system_path() thus always starts from
'bin' and yields predictable results. This is however only part of a
full solution to the problem outlined above. Remaining problems are:
- Other code paths might run the dashed forms directly.
- We have non-builtins that are implemented in C, e.g. fast-import.c.
These non-builtins will still compute wrong paths.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
---
run-command.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
My previous mail was in the wrong thread. Apologies. This one
will be correctly threaded.
Steffen
diff --git a/run-command.c b/run-command.c
index 6e29fdf..a3b28a6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -119,9 +119,8 @@ int start_command(struct child_process *cmd)
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
- const char *sargv0 = cmd->argv[0];
+ const char **sargv = cmd->argv;
char **env = environ;
- struct strbuf git_cmd;
if (cmd->no_stdin) {
s0 = dup(0);
@@ -165,9 +164,7 @@ int start_command(struct child_process *cmd)
}
if (cmd->git_cmd) {
- strbuf_init(&git_cmd, 0);
- strbuf_addf(&git_cmd, "git-%s", cmd->argv[0]);
- cmd->argv[0] = git_cmd.buf;
+ cmd->argv = prepare_git_cmd(cmd->argv);
}
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env);
@@ -175,9 +172,9 @@ int start_command(struct child_process *cmd)
if (cmd->env)
free_environ(env);
if (cmd->git_cmd)
- strbuf_release(&git_cmd);
+ free(cmd->argv);
- cmd->argv[0] = sargv0;
+ cmd->argv = sargv;
if (s0 >= 0)
dup2(s0, 0), close(s0);
if (s1 >= 0)
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-29 5:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, SZEDER Gábor, git
In-Reply-To: <7vod4ho6uq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> On Mon, Jul 28, 2008 at 12:19:19PM -0700, Junio C Hamano wrote:
>>> We need to refresh the entry to pick up potential ctime changes.
>>>
>>> read-cache.c | 7 ++++++-
>>> builtin-ls-files.c | 21 +++++++++++++++------
>>> 2 files changed, 21 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/read-cache.c b/read-cache.c
>>> index 1cae361..834096f 100644
>>
>> Oops, silly me. Sorry for being slower than you at fixing this. ;-)
>
> I did think about ctime issues when I applied the patch.
Actually I changed my mind.
I think it is wrong for something as low-level as rename_index_entry_at()
to unconditionally look at the working tree and try refreshing the entry.
The next caller of this function may not even require a working tree.
I think Dscho is correct; expecting the saved cacheinfo to stay fresh
across rename does not make much sense. What we care about with "git mv"
is that we keep what the user staged, i.e. kind of blob and the contents.
It cannot be guaranteed if the index entry is stat clean or not, as
st_ctime may or may not be updated across rename(2) according to POSIX.
So let's do this instead.
-- >8 --
t7001: fix "git mv" test
The test assumed that we can keep the cached stat information fresh across
rename(2); many filesystems however update st_ctime (and POSIX allows them
to do so), so that assumption does not hold. We can explicitly refresh
the index for the purpose of the test, as the only thing we are interested
in is the staged contents and the mode bits are preserved across "mv".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t7001-mv.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b0fa407..910a28c 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -185,6 +185,7 @@ test_expect_success 'git mv should overwrite symlink to a file' '
! test -e moved &&
test -f symlink &&
test "$(cat symlink)" = 1 &&
+ git update-index --refresh &&
git diff-files --quiet
'
@@ -202,6 +203,7 @@ test_expect_success 'git mv should overwrite file with a symlink' '
git mv -f symlink moved &&
! test -e symlink &&
test -h moved &&
+ git update-index --refresh &&
git diff-files --quiet
'
^ permalink raw reply related
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Shawn O. Pearce @ 2008-07-29 5:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1217308647-23673-1-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> We prefer running the dashless form, so we should use it in MinGW's
> start_command(), too.
...
> - We have non-builtins that are implemented in C, e.g. fast-import.c.
> These non-builtins will still compute wrong paths.
This feels wrong to me. fast-import probably won't be adversly
impacted by not being able to read /etc/gitconfig, unless the user
has set something like core.deltaBaseCacheLimit and is doing an
incremental import. But other non-builtins may be impacted.
It feels like we're fixing this in the wrong place. If the issue
is we don't find our installation directory correctly, we should
find our installation directory correctly, not work around it by
calling builtins through the git wrapper.
Though I can see where it may be a good idea to at some point
in the future (git 1.7?) stop creating the redundant builtin
links under libexec/git-core.
--
Shawn.
^ permalink raw reply
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Junio C Hamano @ 2008-07-29 5:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Steffen Prohaska, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217277453.488e2e0db0f41@webmail.nextra.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
> ...
>> The patch below might fix the problem by always calling 'bin/git'
>> for builtin commands. The computation in system_path() would
>> always start from 'bin' and thus yields predictable results. I
>> am not sure however if it fully solves the problem because other
>> code paths might run the dashed forms directly.
>
> This paragraph should go into the commit message.
> ...
> Your patches make a lot of sense.
I was almost going to suggest doing this everywhere not just on Windows,
but execv_git_cmd() on the POSIX side already runs "git" wrapper, so this
patch makes them in line, finally.
>> -- 8< --
>> We prefer running the dashless form, so we should use it in
>> MinGW's start_command(), too.
>>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>
> Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
>
> -- Hannes
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Jeff King @ 2008-07-29 5:31 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807281241180.6791@localhost.localdomain>
On Tue, Jul 29, 2008 at 04:59:01AM +0200, Roman Zippel wrote:
> Right now you're giving me the choice between a crappy incomplete history
> or a crappy history full of useless information. That's it? As long as
> your challenge involves being compared to crappy history, I'm not
> interested. If the solution should involve a switch "--correct-history"
> or I have to wait for the result, I don't care, because it's the correct
> history I want. As long as you're trying to sell me crappy history I'm not
> buying it.
>
> Can we please get past this and look at what is required to produce the
> correct history?
You seem to be indicating here (and elsewhere in the thread) that there
exists some history graph for which neither "git log" nor "git log
--full-history" produces the output you want, but that there is some
better output (even if it might take more time to compute).
Perhaps I am just slow, but I haven't been able to figure out what that
history is, or what the "correct" output should be. Can you try to state
more clearly what it is you are looking for?
-Peff
^ permalink raw reply
* Re: Hackontest ideas?
From: Shawn O. Pearce @ 2008-07-29 5:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Petr Baudis, git
In-Reply-To: <20080729001016.GT32057@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:
> >
> > (What feature in Git or a Git-related tool would you implement, given 24
> > hours staight and unlimited pizza supply?)
>
> Restartable git-clone? :-)
>
> It was a GSoC idea this year, but in the end nobody started working on
> it.
>
> (I was about to work on it, but finally my 'builtin-merge' application
> was accepted.)
Yea, we eventually decided it was probably too small for a
GSoC project. Given how quickly you put together your git-merge
project, I'm actually happy we got you working on git-merge and
not restartable clone, as I think you may have finished restartable
clone in 24 hours and then said "now what mr. mentor?" ;-)
Pasky, et.al.:
How about smart fetch/push over HTTP? E.g. a CGI (or extension to
gitweb) that does native pack transport over HTTP rather than dumb
object traversal with GET and WebDAV LOCK/PUT. Note that the push
side doesn't need to support tell-me-more extension, making it a
fairly trivial GET, POST (or PUT) sequence.
--
Shawn.
^ permalink raw reply
* [PATCH] merge-base: die with an error message if not passed a commit ref
From: Christian Couder @ 2008-07-29 5:42 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin; +Cc: Miklos Vajna, Jakub Narebski
Before this patch "git merge-base" just exited with error code 1
and without an error message in case it was passed a ref to an
object that is not a commit (for example a tree).
This patch makes it "die" in this case with an error message.
While at it, this patch also refactors the code to get the
commit reference from an argument into a new
"get_commit_reference" function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-merge-base.c | 26 +++++++++++++++++---------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 1cb2925..3382b13 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -22,10 +22,23 @@ static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_al
static const char merge_base_usage[] =
"git merge-base [--all] <commit-id> <commit-id>";
+static struct commit *get_commit_reference(const char *arg)
+{
+ unsigned char revkey[20];
+ struct commit *r;
+
+ if (get_sha1(arg, revkey))
+ die("Not a valid object name %s", arg);
+ r = lookup_commit_reference(revkey);
+ if (!r)
+ die("Not a valid commit name %s", arg);
+
+ return r;
+}
+
int cmd_merge_base(int argc, const char **argv, const char *prefix)
{
struct commit *rev1, *rev2;
- unsigned char rev1key[20], rev2key[20];
int show_all = 0;
git_config(git_default_config, NULL);
@@ -40,13 +53,8 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
}
if (argc != 3)
usage(merge_base_usage);
- if (get_sha1(argv[1], rev1key))
- die("Not a valid object name %s", argv[1]);
- if (get_sha1(argv[2], rev2key))
- die("Not a valid object name %s", argv[2]);
- rev1 = lookup_commit_reference(rev1key);
- rev2 = lookup_commit_reference(rev2key);
- if (!rev1 || !rev2)
- return 1;
+ rev1 = get_commit_reference(argv[1]);
+ rev2 = get_commit_reference(argv[2]);
+
return show_merge_base(rev1, rev2, show_all);
}
--
1.6.0.rc0.42.g186458.dirty
^ permalink raw reply related
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Junio C Hamano @ 2008-07-29 5:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <20080729052459.GC11947@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> This feels wrong to me. fast-import probably won't be adversly
> impacted by not being able to read /etc/gitconfig, unless the user
> has set something like core.deltaBaseCacheLimit and is doing an
> incremental import. But other non-builtins may be impacted.
>
> It feels like we're fixing this in the wrong place. If the issue
> is we don't find our installation directory correctly, we should
> find our installation directory correctly, not work around it by
> calling builtins through the git wrapper.
>
> Though I can see where it may be a good idea to at some point
> in the future (git 1.7?) stop creating the redundant builtin
> links under libexec/git-core.
I agree; that is why I already applied Steffen's original patch with quite
a different justification from the updated one:
commit b048b9a803f48d88595877271b53bf9ec400e4ba
Author: Steffen Prohaska <prohaska@zib.de>
Date: Mon Jul 28 07:50:28 2008 +0200
run-command (Windows): Run dashless "git <cmd>"
We prefer running the dashless form, and POSIX side already does so; we
should use it in MinGW's start_command(), too.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] merge-base: die with an error message if not passed a commit ref
From: Junio C Hamano @ 2008-07-29 5:45 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <20080729074253.b4617027.chriscool@tuxfamily.org>
Thanks; queued for 1.6.0.
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-29 5:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080728160138.GA12777@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
>
> Setup/background: distributed kernel testing cluster, [...]
>
> Problem: i noticed that git-fetch is a tad slow:
>
> titan:~/tip> time git-fetch
> real 0m2.372s
>
> There are hundreds of branches, so i thought fetching a single branch
> alone would improve things:
>
> titan:~/tip> time git-fetch origin master
> real 0m0.942s
>
> But that's still slow - so i use a (lame) ad-hoc script instead:
>
> titan:~/tip> time tip-fetch
> real 0m0.246s
OK, yes, when there are _many_ branches like that limiting fetch
to a narrow focus of only the branch(es) you must have can make it
go much faster. Part of the problem is we loop over the branches
many times, and those are O(N) loops (N=number of branches). We
could do better, but we don't.
One reason why your tip-fetch runs so much better is because we don't
have to enumerate the hundreds of advertised branches offered up by
the remote peer to find the one you want to fetch. Your tip-fetch
is reading only that one ref file (.git/refs/heads/master) and
that's pretty much it.
In contrast git-upload-pack on the server side must open and read
_all_ ref files under .git/refs/ and send them to the client, who
then has to loop over them at least twice before it can decide if
a match exists. That's a lot more data to shove down over SSH.
Granted its only 42 bytes + refname per ref, but its still more.
Those O(N) loops I referred to earlier can explain why for hundreds
of branches it gets ugly. That turns into an O(N^2) matching
algorithm. Not pretty. A simple hash would solve a lot of that,
changing the first time from 0m2.372s to much closer to the scond
time of 0m0.942s.
Neither of which can compete with your tip-fetch.
Have you tried using git-pack-refs to pack the branches on the
remote repository?
If you update all of the branches, run `git pack-refs --all --prune`,
then allow the testing clients to start fetching it may go much
quicker. The pack-refs moves all of the individual ref files into
the single .git/packed-refs file, reducing the number of files we
need to open and read to service a single fetch client.
I wonder if git-pack-refs + fetching only a single branch will get
you closer to the tip-fetch time.
Also, I wonder if you really need to fetch over SSH. Doing a
fetch over git:// is much quicker, as there is no SSH session
setup overheads.
--
Shawn.
^ permalink raw reply
* Re: git submodules
From: Benjamin Collins @ 2008-07-29 5:51 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Pierre Habouzit, Nigel Magnay, Git ML
In-Reply-To: <32541b130807281440v64f3cb9ci50cf6d16be4f2f82@mail.gmail.com>
On Mon, Jul 28, 2008 at 4:40 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> Most importantly in my case, my submodules (libraries shared between
> apps) have a very different branching structure than my supermodules.
> It wouldn't be particularly meaningful to force them to use the same
> branch names.
>
> Further, if you don't have a separate .git directory for each
> submodule, you can't *switch* branches on the submodule independently
> of the supermodule in any obvious way. This is also useful; I might
> want to test updating to the latest master of my submodule, see if it
> still works with my supermodule, and if so, commit the new gitlink in
> the supermodule. This is a very common workflow for me.
I second this sentiment. I happen to very much *like* the fact that
the coupling between submodules and their super-projects is minimal.
The flexibility this allows is very useful. Of course, it brings to
mind the comment Stroustrup once made about C++ blowing off your whole
leg.
> On the other hand, your thought about combining the "git log" messages
> is quite interesting. That *is* something I'd benefit from, along
> with being able to git-bisect across submodules. If I'm in the
> supermodule, I want to see *all* the commits that might have changed
> in my application, not just the ones in the supermodule itself. I
> suspect this isn't simple at all to implement, however, as you'd have
> to look inside the file tree of a given commit in order to find
> whether any submodule links have changed in that commit. It's
> unfortunate that submodules involve a commit->tree->commit link
> structure.
Let my contrariness begin...
I can see how someone might find such a feature in "git log" useful,
but I don't think I would. I have 3 submodules in my project right
now, and I don't always want to see the changes. Most of the time, I
don't care, actually. When I do care, I can search the output of "git
log" for commits that touch the path where my submodule lives (through
Gitk, usually), and I can open another Gitk for details.
As for "git bisect": I haven't done this and I'm too busy to try to
contrive something for the purposes of this email, but wouldn't it
basically already do what you want? Seems that you'd just run "git
submodule update" after each step of the bisect.
>
> > One irritating problem with submodules, is
> > that when someone else commited, and that you git submodule update,
> > you're on a detached head. Absolutely horrible.
>
> I think that roughly everyone agrees with the above statement by now.
> It would also be trivial to fix it, if only we knew what "fix" means.
> So far, I haven't seen any good suggestions for what branch name to
> use automatically in a submodule, and believe me, I've been looking
> for one :)
I disagree with this completely. I think the detached head is
actually fantastic because it tells you all the right things:
a) the branch your submodule is on is ultimately irrelevant
b) it reminds you that this is not your project. It's part of your
project managed in a special way by Git, but your project is in ..
c) if you want to do work in this part of your project that comes from
somewhere else, you need to be thoughtful about how you manage its
branches.
I try to keep all my submodules on (no branch) as much as possible.
In a way, I feel like that kind of relieves me of the chore of keeping
mapping superproject branches to submodule branches in my head.
I pretty much support submodules as they are, with the exception of
wanting "git submodule update" to be executed automatically at times.
^ permalink raw reply
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Steffen Prohaska @ 2008-07-29 5:51 UTC (permalink / raw)
To: Shawn O. Pearce, Johannes Sixt
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin
In-Reply-To: <20080729052459.GC11947@spearce.org>
On Jul 29, 2008, at 7:24 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> We prefer running the dashless form, so we should use it in MinGW's
>> start_command(), too.
> ...
>> - We have non-builtins that are implemented in C, e.g. fast-import.c.
>> These non-builtins will still compute wrong paths.
>
> This feels wrong to me. fast-import probably won't be adversly
> impacted by not being able to read /etc/gitconfig, unless the user
> has set something like core.deltaBaseCacheLimit and is doing an
> incremental import. But other non-builtins may be impacted.
>
> It feels like we're fixing this in the wrong place. If the issue
> is we don't find our installation directory correctly, we should
> find our installation directory correctly, not work around it by
> calling builtins through the git wrapper.
For builtins it is not a work around but a real solution. The
solution however needs to be tested without builtins installed
in libexec/git-core. Note that Unix runs builtins using the
git wrapper too (see execv_git_cmd), so the patch makes the MinGW
port behaving more like the Unix version.
My patch however does not solve the problem for non-builtins, so I agree
that we are not fixing the real problem.
Maybe we could do the following:
- Add a switch RELOCATABLE_PREFIX to the Makefile.
- If RELOCATABLE_PREFIX is defined, system paths will not be
interpreted as is, but a prefix will be computed at runtime. For
example, if git is installed in /some/patch/bin/git, then
system_path("/etc") will return "/some/path/etc".
- As Dscho proposed, system_path() needs to be intelligent enough
to find the prefix for executables located either in bindir or in
gitexecdir.
Adding a switch to the Makefile would make the relocation magic
explicit, instead of relying on relative paths. This has also the
advantage that we can just use the default paths for gitexecdir,
template_dir, ... , instead of overriding them in MINGW section of the
Makefile. We only would set RELOCATABLE_PREFIX there. Actually some
more work is needed because prefix is used for defining system paths and
also for defining the installation directory. Maybe we could add
installprefix to explicitly distinguish between the two purposes.
Steffen
^ permalink raw reply
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Steffen Prohaska @ 2008-07-29 5:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <7v4p69meka.fsf@gitster.siamese.dyndns.org>
On Jul 29, 2008, at 7:42 AM, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> This feels wrong to me. fast-import probably won't be adversly
>> impacted by not being able to read /etc/gitconfig, unless the user
>> has set something like core.deltaBaseCacheLimit and is doing an
>> incremental import. But other non-builtins may be impacted.
>>
>> It feels like we're fixing this in the wrong place. If the issue
>> is we don't find our installation directory correctly, we should
>> find our installation directory correctly, not work around it by
>> calling builtins through the git wrapper.
>>
>> Though I can see where it may be a good idea to at some point
>> in the future (git 1.7?) stop creating the redundant builtin
>> links under libexec/git-core.
>
> I agree; that is why I already applied Steffen's original patch with
> quite
> a different justification from the updated one:
>
> commit b048b9a803f48d88595877271b53bf9ec400e4ba
> Author: Steffen Prohaska <prohaska@zib.de>
> Date: Mon Jul 28 07:50:28 2008 +0200
>
> run-command (Windows): Run dashless "git <cmd>"
>
> We prefer running the dashless form, and POSIX side already does
> so; we
> should use it in MinGW's start_command(), too.
Thanks for reading my mind ;-) This was the alternative justification
I had in mind after reading my patch again.
Steffen
^ permalink raw reply
* Re: git submodules
From: Shawn O. Pearce @ 2008-07-29 6:04 UTC (permalink / raw)
To: Benjamin Collins; +Cc: Avery Pennarun, Pierre Habouzit, Nigel Magnay, Git ML
In-Reply-To: <b3889dff0807282251t7096a8c9wf477cf4495749d34@mail.gmail.com>
Benjamin Collins <aggieben@gmail.com> wrote:
> On Mon, Jul 28, 2008 at 4:40 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> >
> > > One irritating problem with submodules, is
> > > that when someone else commited, and that you git submodule update,
> > > you're on a detached head. Absolutely horrible.
> >
> > I think that roughly everyone agrees with the above statement by now.
> > It would also be trivial to fix it, if only we knew what "fix" means.
> > So far, I haven't seen any good suggestions for what branch name to
> > use automatically in a submodule, and believe me, I've been looking
> > for one :)
>
> I disagree with this completely. I think the detached head is
> actually fantastic [...]
Ditto with Benjamin. Detached head is a fantastic idea.
> [...] because it tells you all the right things:
> a) the branch your submodule is on is ultimately irrelevant
> b) it reminds you that this is not your project. It's part of your
> project managed in a special way by Git, but your project is in ..
> c) if you want to do work in this part of your project that comes from
> somewhere else, you need to be thoughtful about how you manage its
> branches.
>
> I try to keep all my submodules on (no branch) as much as possible.
> In a way, I feel like that kind of relieves me of the chore of keeping
> mapping superproject branches to submodule branches in my head.
At my former day-job we wrote our own "git submodule" in our
build system before gitlink was available in the core, let alone
git-submodule was a Porcelain command.
Many developers who were new to Git found having a sea of 11 Git
repositories+working directories in a single build area difficult to
manage. They quickly found the detached HEAD feature in a submodule
to be a really handy way to know if they made changes there or not.
Most of our developers also modified __git_ps1() in their bash
completion to use `git name-rev HEAD` to try and pick up a remote
branch name when on a detached HEAD. This slowed down their bash
prompts a little bit, but they found that "origin/foo" hint very
valuable to let them know they should start a new branch before
making changes.
So I'm just echoing what Benjamin said above, only we did it
independently, and came to the same conclusion.
--
Shawn.
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-28 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsj6tsm3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > t2103-update-index-ignore-missing.sh still broken on Windows because
> > of stat.st_size being 0 for directories there.
>
> I recall we did not reach a useful conclusion of that discussion.
Why isn't the proposed patch useful? (and would it be possible to make
the answer out of plain, small and short words?)
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Alex Riesen @ 2008-07-28 21:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Brown, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
git
In-Reply-To: <alpine.LFD.1.10.0807280906530.3486@nehalem.linux-foundation.org>
Linus Torvalds, Mon, Jul 28, 2008 18:09:32 +0200:
> It really is just Beagle that is (was? I can dream) a piece of
> unbelievable crap.
>
> Anybody who uses extended attributes as part of a indexing scheme is just
> insane. Modifying the file you are indexing is not just fundamentally
> wrong to begin with, but it will then also be incredibly inefficient to
> read those entries one at a time.
>
> And no other sane model would ever touch 'ctime'.
Beagle is not alone. Google Desktop Search was mentioned before.
> Oh, well. Making ctime configurable is not wrong per se. But if it's
> Beagle that triggers this, the fix is sadly in the wrong place.
Never said it was a fix. Same as CRLF conversion is not a feature.
^ permalink raw reply
* [PATCH] Improve the placement of core.trustctime in the documentation
From: Alex Riesen @ 2008-07-28 21:47 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Johannes Sixt, git
In-Reply-To: <20080728162043.GG32184@machine.or.cz>
Accidentally, it split a _chapter_ about a file data corrup...
conversion for a weird, but common operating system.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Petr Baudis, Mon, Jul 28, 2008 18:20:43 +0200:
> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 1a13abc..552c134 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -149,6 +149,13 @@ core.safecrlf::
> > `core.autocrlf`, git will reject the file. The variable can
> > be set to "warn", in which case git will only warn about an
> > irreversible conversion but continue the operation.
> > +
> > +core.trustctime::
> > + If false, the ctime differences between the index and the
> > + working copy are ignored; useful when the inode change time
> > + is regularly modified by something outside Git (file system
> > + crawlers and some backup systems).
> > + See linkgit:git-update-index[1]. True by default.
> > +
> > CRLF conversion bears a slight chance of corrupting data.
> > autocrlf=true will convert CRLF to LF during commit and LF to
>
> Somehow, this particular position of the new hunk does not feel like the
> best choice. ;-)
>
It's alphabetical. Why? Oh, shit... Screw alphabetical
Documentation/config.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 552c134..61c3760 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -117,6 +117,13 @@ core.fileMode::
the working copy are ignored; useful on broken filesystems like FAT.
See linkgit:git-update-index[1]. True by default.
+core.trustctime::
+ If false, the ctime differences between the index and the
+ working copy are ignored; useful when the inode change time
+ is regularly modified by something outside Git (file system
+ crawlers and some backup systems).
+ See linkgit:git-update-index[1]. True by default.
+
core.quotepath::
The commands that output paths (e.g. 'ls-files',
'diff'), when not given the `-z` option, will quote
@@ -149,13 +156,6 @@ core.safecrlf::
`core.autocrlf`, git will reject the file. The variable can
be set to "warn", in which case git will only warn about an
irreversible conversion but continue the operation.
-
-core.trustctime::
- If false, the ctime differences between the index and the
- working copy are ignored; useful when the inode change time
- is regularly modified by something outside Git (file system
- crawlers and some backup systems).
- See linkgit:git-update-index[1]. True by default.
+
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
--
1.6.0.rc0.76.g581e
^ permalink raw reply related
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 6:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080728213727.GA3721@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>> > t2103-update-index-ignore-missing.sh still broken on Windows because
>> > of stat.st_size being 0 for directories there.
>>
>> I recall we did not reach a useful conclusion of that discussion.
>
> Why isn't the proposed patch useful? (and would it be possible to make
> the answer out of plain, small and short words?)
Can you answer out of plain, small and short words why the proposed patch
is correct without unwanted side effects, not just "this seems to solve
the particular issue for me but I don't know if it has unintended side
effects"?
^ permalink raw reply
* Re: [PATCH] Improve the placement of core.trustctime in the documentation
From: Junio C Hamano @ 2008-07-29 6:23 UTC (permalink / raw)
To: Alex Riesen
Cc: Petr Baudis, Johannes Schindelin, Linus Torvalds, Johannes Sixt,
git
In-Reply-To: <20080728214716.GB3721@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Accidentally, it split a _chapter_ about a file data corrup...
> conversion for a weird, but common operating system.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Petr Baudis, Mon, Jul 28, 2008 18:20:43 +0200:
>> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
>> > diff --git a/Documentation/config.txt b/Documentation/config.txt
>> > index 1a13abc..552c134 100644
>> > --- a/Documentation/config.txt
>> > +++ b/Documentation/config.txt
>> > @@ -149,6 +149,13 @@ core.safecrlf::
>> > `core.autocrlf`, git will reject the file. The variable can
>> > be set to "warn", in which case git will only warn about an
>> > irreversible conversion but continue the operation.
>> > +
>> > +core.trustctime::
>> > + If false, the ctime differences between the index and the
>> > + working copy are ignored; useful when the inode change time
>> > + is regularly modified by something outside Git (file system
>> > + crawlers and some backup systems).
>> > + See linkgit:git-update-index[1]. True by default.
>> > +
>> > CRLF conversion bears a slight chance of corrupting data.
>> > autocrlf=true will convert CRLF to LF during commit and LF to
>>
>> Somehow, this particular position of the new hunk does not feel like the
>> best choice. ;-)
>>
>
> It's alphabetical. Why? Oh, shit... Screw alphabetical
Yeah, I think it makes sense to put this after core.filemode.
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-29 6:35 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Johannes Schindelin, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080729050845.GE26997@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Your reason was "it keeps your crap in the history". And while I
> generally am in favor of getting rid of crap and keeping a clean
> history, I think it is very much dependent on the individual project's
> preferences. IOW, that history might not contain "crap" but rather
> now-obsolete changes that are of historical interest.
>
> But I do agree that -Xtheirs is crap. ;)
Yes, that is why I did not merge 'master' with "theirs" merge into it to
subsume it. I reverted -Xtheirs from 'next' (due to "never-rewind during
the cycle" rule) and intend to rebuild 'next' without it when 1.6.0 ships.
However, that does not keep me from holding onto its tip privately (and I
do, as the machinery to pass -Xoption through git-merge to backends would
be useful later).
IOW, "now-obsolete changes that are of historical interest" does not
necessarily justify a "subsuming" merge using "-s ours" or "-s theirs".
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 23:12 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nigel Magnay, Git ML
In-Reply-To: <32541b130807281532v3eed94ebv8037247618e9bd55@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5156 bytes --]
On Mon, Jul 28, 2008 at 10:32:54PM +0000, Avery Pennarun wrote:
> On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> > > It's unfortunate that submodules involve a commit->tree->commit link
> > > structure.
> >
> > Actually it's not a big problem, you just have to "dereference" twice
> > instead of one, and be prepared to the fact that the second dereference
> > may fail (because you miss some objects). I instead believe that
> > gitlinks are a good idea.
>
> It's actually complicated to generate the log, however. To be 100%
> accurate in creating a combined log of the supermodule and submodule,
> you'd have to check *for each supermodule commit* whether there were
> any changes in gitlinks. And gitlinks might move around between
> revisions, so you can't just look up a particular path in each
> revision; you have to traverse the entire tree. And you can't just
> look at the start and end supermodule commits to see if the gitlinks
> changed; they might have changed and then changed back, which is quite
> relevant to log messages.
I'm pretty clueless about how git-log works, but I fail to see how this
is harder than following file moves e.g. Of course it's more expensive
than git log, but it shouldn't really be more expensive than
`git log -M -C -C` already is.
> > Well, using the same [branch] as the supermodule is probably the less confusing
> > way. Of course, not being in the "same" branch as the supermodule would
> > clearly be a case of your tree being "dirty", and it would prevent a
> > "git checkout" to work in the very same way that git checkout doesn't
> > work if you have locally modified files.
> >
> > If your submodule branching layout uses the same names as the
> > supermodule branches then yes, it's going to hurt, but I believe it to
> > be unlikely (else you would become insane just trying to remember what
> > you are doing ;p).
>
> I think this is much more common than you think. An easy example is
> that I'm developing a new version of my application in the
> supermodule's "master", but it relies on a released version of my
> submodule, definitely not the experimental "master" version. Using
> your logic, the local branch of the submodule would be called master,
> but wouldn't correspond at all to the remote submodule's master.
Probably indeed, otoh the "remote" (assume it's origin) master state is
stored in "origin/master", not "master".
> I believe such a situation would be even worse than no branch at all.
> It could lead to people pushing/pulling all sorts of bad things from
> the wrong places. At least right now, people become confused and ask
> for help instead of becoming confused and making a mess.
Indeed. But that's only a name issue, I'm sure we can come up with
something decent. What I (we ?) want is actually a way to make
git-checkout/git-reset work so that when you switch branches (reset
--hard to a previous state) you remain on branch, because human brains
usually don't remember those silly detached HEADs commits sha1 well ;)
The problem is, `the branch I'm on in my submodule when the supermodule
is on $foo` is a quite local information. But that's really what we
would like to remember so that when you git checkout somewhere and git
checkout master back, submodules switches branch accordingly.
Saying that, I realize that we probably _really_ want to name submodule
branches the same as the supermodule ones, but should manage to find UIs
that don't confuse users wrt the fact that it may be disconnected from
the remote branch nameing.
I reckon that for my use, I would not have those problems, because we
have this kind of layout:
lib-foo/ <-- submodule to share the foo library.
lib-bar/ <-- submodule to share the bar library.
app-frotz/ <-- the frotz product
In another repository we have app-quux and the same submodules, and so
on.
We always try that our `master`s (where devel happens unlike git.git ;p)
use the most recent `master` versions from the submodules. And the
stable branches (IOW the software that we sold and released and for
which we provide support), have branches named $product/$version. We
have $product/$version branches in those submodules as well. If we have
a bug that needs a patch in say, lib-foo, then we push the patch into a
topic branch, that we merge in all the $product/$version that need it,
and into master as well. For such a setup that I believe to be sane,
then well, corresponding names fit the job perfectly.
Of course if one of your submodule is git.git where the not too unstable
code lives in `next` and not `master` and another one is one of my
project at work, where not too unstable code lives in `master` then
indeed you're somehow screwed because indeed the whole `master` concept
would be quite confusing. But honestly, I don't think it's less
confusing with the current way submodules work either.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox