* Re: [PATCH] Fix rev-list when showing objects involving submodules
From: Johannes Schindelin @ 2007-11-12 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sam Vilain, git, gitster
In-Reply-To: <alpine.LFD.0.9999.0711121231570.3062@woody.linux-foundation.org>
Hi,
On Mon, 12 Nov 2007, Linus Torvalds wrote:
> On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> >
> > You mean something like
> >
> > else if (S_ISREG(entry.mod) || S_ISLNK(entry.mod))
> >
> > Hmm? Sure, I have no preference there.
>
> Maybe more along the line of something like this?
>
> In general, I suspect we should try to start moving away from using the
> "S_ISLNK()" like things for internal git state. It was a mistake to just
> assume the numbers all were same across all systems in the first place.
>
> So this just converts to the "object_type", and then uses a case
> statement.
Sure. Just add the test from my patch, and we're fixed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix a strchrnul() related build error
From: Johannes Schindelin @ 2007-11-12 21:27 UTC (permalink / raw)
To: Emil Medve; +Cc: gitster, ae, git
In-Reply-To: <1194901282-2468-1-git-send-email-Emilian.Medve@Freescale.com>
Hi,
didn't Johannes Sixt provide a (slightly nicer) patch earlier today?
Ciao,
Dscho
^ permalink raw reply
* Re: git diff woes
From: Junio C Hamano @ 2007-11-12 21:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <47382C84.50408@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> In the check_ntpd.c program, there is no bug. I found the git diff output
> surprising, so I reported it.
This is what I get from "GNU diff -pu" which makes me surpried
that anybody finds "git diff" hunk header surprising. Notice
that hunk at line 84.
--- read-cache.c 2007-11-12 12:08:00.000000000 -0800
+++ read-cache.c+ 2007-11-12 12:07:54.000000000 -0800
@@ -60,7 +60,7 @@ static int ce_compare_data(struct cache_
return match;
}
-static int ce_compare_link(struct cache_entry *ce, size_t expected_size)
+static int ce_compare_lonk(struct cache_entry *ce, size_t expected_size)
{
int match = -1;
char *target;
@@ -84,7 +84,7 @@ static int ce_compare_link(struct cache_
match = memcmp(buffer, target, size);
free(buffer);
free(target);
- return match;
+ return match + 0;
}
static int ce_compare_gitlink(struct cache_entry *ce)
^ permalink raw reply
* Re: git push mirror mode V4 (replacement stack)
From: Junio C Hamano @ 2007-11-12 21:35 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git, Johannes Schindelin
In-Reply-To: <20071112110016.GG301@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> On Fri, Nov 09, 2007 at 11:30:41PM +0000, Andy Whitcroft wrote:
>> Following this mail is a complete replacement git push mirror mode
>> stack (V4). It folds down all the various patches into a logical
>> sequence (thanks Dscho). This stack passes the entire test suite,
>> and I have been using the same code for real work here.
>
> Ok, I have spotted one oddity with this feature. The symbolic refs are
> getting converted to real refs in the mirror. Generally speaking this
> is the <remote>/HEAD refs but I guess it may be possible to have others.
Currently there is no way to remotely create a symref.
It should be easy to make DAV based http push create a symref
file.
The native "send-pack" protocol does not support such feature,
so this needs a protocol extension, which hopefully would be
not too involved.
Also, to be symmetric, we would need a protocol extension on the
"fetch-pack" protocol side to allow fetchers to find out which
one is a symref pointing out what other ref. The lack of the
information is why git-clone has to guess.
^ permalink raw reply
* [PATCH] Add a test checking if send-pack updated local tracking branches correctly
From: Alex Riesen @ 2007-11-12 21:38 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5404-tracking-branches.sh | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
create mode 100755 t/t5404-tracking-branches.sh
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
new file mode 100755
index 0000000..20718d4
--- /dev/null
+++ b/t/t5404-tracking-branches.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+test_description='tracking branch update checks for git push'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo 1 >file &&
+ git add file &&
+ git commit -m 1 &&
+ git branch b1 &&
+ git branch b2 &&
+ git clone . aa &&
+ git checkout b1 &&
+ echo b1 >>file &&
+ git commit -a -m b1 &&
+ git checkout b2 &&
+ echo b2 >>file &&
+ git commit -a -m b2
+'
+
+test_expect_success 'check tracking branches updated correctly after push' '
+ cd aa &&
+ b1=$(git rev-parse origin/b1) &&
+ b2=$(git rev-parse origin/b2) &&
+ git checkout -b b1 origin/b1 &&
+ echo aa-b1 >>file &&
+ git commit -a -m aa-b1 &&
+ git checkout -b b2 origin/b2 &&
+ echo aa-b2 >>file &&
+ git commit -a -m aa-b2 &&
+ git checkout master &&
+ echo aa-master >>file &&
+ git commit -a -m aa-master &&
+ git push &&
+ test "$(git rev-parse origin/b1)" = "$b1" &&
+ test "$(git rev-parse origin/b2)" = "$b2"
+'
+
+test_done
--
1.5.3.5.648.g1e92c
^ permalink raw reply related
* [PATCH] Update the tracking references only if they were succesfully updated on remote
From: Alex Riesen @ 2007-11-12 21:39 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <20071112213823.GB2918@steel.home>
It fixes the bug where local tracing branches were filled with zeroed SHA-1
if the remote branch was not updated because, for instance, it was not
an ancestor of the local (i.e. had other changes).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Jeff, I think your change (334f4831e5a77) was either not complete or
got broken some time later.
send-pack.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index b74fd45..d56d980 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -349,7 +349,8 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
if (!dry_run && remote && ret == 0) {
for (ref = remote_refs; ref; ref = ref->next)
- update_tracking_ref(remote, ref);
+ if (!is_null_sha1(ref->new_sha1))
+ update_tracking_ref(remote, ref);
}
if (!new_refs && ret == 0)
--
1.5.3.5.648.g1e92c
^ permalink raw reply related
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Junio C Hamano @ 2007-11-12 21:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <vpqoddzpc88.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
>>> >
>>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>> >>
>>> >> > So you need to populate the repository before starting _anyway_.
>>> >>
>>> >> Last time I checked, the thread was talking about bare repository.
>>
>> Look at the subject. "Cloning empty repositories."
>
> Look at the content. "cloning a empty bare repository".
But both of Johannes's points apply equally well to an empty
bare repository and to an empty non bare repository. IOW,
bareness does not matter to the suggestion Johannes gave.
But you are acting as if the bareness of the target repository
makes his point irrelevant. I am a bit confused.
About his point 1, I'd just stop at saying that "it is not so
hard" does not mean "we do not have to make it even easier".
His second point is also a real issue. If you allowed cloning
an empty repo (either bare or non-bare), then you and Bill can
both clone from it, come up with an initial commit each. Bill
pushes his initial commit first. Your later attempt to push
will hopefully fail with "non fast forward", if you know better
than forcing such a push, but then what? You need to fetch, and
merge (or rebase) your change on top of Bill's initial commit,
and at that point the history you are trying to merge does not
have any common ancestor with his history.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Junio C Hamano @ 2007-11-12 21:59 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Nicolas Pitre, Matthieu Moy, Jan Wielemaker,
git
In-Reply-To: <4738A6BD.50704@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Johannes Schindelin wrote:
>
>> But since you're one of the people knowing git _internals_ pretty
>> well, here's another reason just for you why this cannot be done:
>> There is no way to find out where the HEAD points to.
>
> $ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD
> refs/heads/master
Johannes is talking about the lack of native protocol support to
transfer symref information. That's the reason git-clone dances
around finding where HEAD really points at. It simply does not
know -- all it gets about a symref is what SHA-1 the ref points
at.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Nicolas Pitre @ 2007-11-12 22:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <7v4pfr2kmh.fsf@gitster.siamese.dyndns.org>
On Mon, 12 Nov 2007, Junio C Hamano wrote:
> His second point is also a real issue. If you allowed cloning
> an empty repo (either bare or non-bare), then you and Bill can
> both clone from it, come up with an initial commit each. Bill
> pushes his initial commit first. Your later attempt to push
> will hopefully fail with "non fast forward", if you know better
> than forcing such a push, but then what? You need to fetch, and
> merge (or rebase) your change on top of Bill's initial commit,
> and at that point the history you are trying to merge does not
> have any common ancestor with his history.
While that could well be true, I don't see this condition happening
solely in the context (hence because) of an empty clone.
Nicolas
^ permalink raw reply
* [PATCH] Beautify the output of send-pack a bit
From: Alex Riesen @ 2007-11-12 22:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Cluster the errors regarding ancestry violation and output them
in one batch, together with a hint to pull before pushing.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Catching trend...
send-pack.c | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index d56d980..e6da567 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -215,6 +215,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
int ask_for_status_report = 0;
int allow_deleting_refs = 0;
int expect_status_report = 0;
+ struct ref *failed_refs = NULL, **failed_tail = &failed_refs;
/* No funny business with the matcher */
remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, REF_NORMAL);
@@ -243,25 +244,27 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
* Finally, tell the other end!
*/
new_refs = 0;
- for (ref = remote_refs; ref; ref = ref->next) {
+ ref = remote_refs;
+ remote_refs = NULL;
+ remote_tail = &remote_refs;
+ for (; ref; ref = ref->next) {
char old_hex[60], *new_hex;
int will_delete_ref;
if (!ref->peer_ref)
- continue;
-
+ goto remote_ok;
will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
if (will_delete_ref && !allow_deleting_refs) {
error("remote does not support deleting refs");
ret = -2;
- continue;
+ goto remote_ok;
}
if (!will_delete_ref &&
!hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
if (verbose)
fprintf(stderr, "'%s': up-to-date\n", ref->name);
- continue;
+ goto remote_ok;
}
/* This part determines what can overwrite what.
@@ -297,13 +300,9 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
* commits at the remote end and likely
* we were not up to date to begin with.
*/
- error("remote '%s' is not an ancestor of\n"
- " local '%s'.\n"
- " Maybe you are not up-to-date and "
- "need to pull first?",
- ref->name,
- ref->peer_ref->name);
ret = -2;
+ *failed_tail = ref;
+ failed_tail = &ref->next;
continue;
}
}
@@ -335,6 +334,18 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
fprintf(stderr, "\n from %s\n to %s\n",
old_hex, new_hex);
}
+ remote_ok:
+ *remote_tail = ref;
+ remote_tail = &ref->next;
+ }
+ *remote_tail = NULL;
+ *failed_tail = NULL;
+
+ if (failed_refs) {
+ for (ref = failed_refs; ref; ref = ref->next)
+ error("remote '%s' is not an ancestor of local '%s'",
+ ref->name, ref->peer_ref->name);
+ fprintf(stderr, "Maybe you are not up-to-date and need to pull first?\n");
}
packet_flush(out);
--
1.5.3.5.648.g1e92c
^ permalink raw reply related
* RE: [PATCH] Fix a strchrnul() related build error
From: Medve Emilian @ 2007-11-12 22:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, ae, git
In-Reply-To: <Pine.LNX.4.64.0711122126370.4362@racer.site>
Hi Dscho,
> didn't Johannes Sixt provide a (slightly nicer) patch earlier today?
That is nicer and should go into the tree.
Cheers,
Emil.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-12 22:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Matthieu Moy, Bill Lear, Jan Wielemaker, git
In-Reply-To: <alpine.LFD.0.9999.0711121702030.21255@xanadu.home>
Hi,
On Mon, 12 Nov 2007, Nicolas Pitre wrote:
> On Mon, 12 Nov 2007, Junio C Hamano wrote:
>
> > His second point is also a real issue. If you allowed cloning
> > an empty repo (either bare or non-bare), then you and Bill can
> > both clone from it, come up with an initial commit each. Bill
> > pushes his initial commit first. Your later attempt to push
> > will hopefully fail with "non fast forward", if you know better
> > than forcing such a push, but then what? You need to fetch, and
> > merge (or rebase) your change on top of Bill's initial commit,
> > and at that point the history you are trying to merge does not
> > have any common ancestor with his history.
>
> While that could well be true, I don't see this condition happening
> solely in the context (hence because) of an empty clone.
Hehe. That is a very delicate play with predicates.
If Alice and Bob clone from an empty repository, and both work on it,
there is _no way_ that they can have a common ancestor[*]. Hence, an
empty clone _would_ be a cause of that condition.
The only way to _not_ have this condition would be at least one side
starting with a non-empty clone. Or with an _effectively_ non-empty
clone.
Ciao,
Dscho
[*] Oh yes, theoretically they could commit the same commit with the same
author info and author timestamp, but to be a common ancestor, they would
also have to use the same _committer_information, which means that Alice
== Bob, as far as Git is concerned. Do I have to go on?
^ permalink raw reply
* Re: wishlist: git info
From: Alex Riesen @ 2007-11-12 22:21 UTC (permalink / raw)
To: Thomas Neumann; +Cc: git
In-Reply-To: <fhad5q$iia$1@ger.gmane.org>
Thomas Neumann, Mon, Nov 12, 2007 21:30:56 +0100:
> while git is pleasant to use in everyday work, there is one svn feature
> which is miss dearly, namely "svn info". svn info can give information
> about specific file objects, but I think its main feature is to use it
> without any path and thus just describe the current project.
> I use this a lot to quickly find out to which remote repository the
> current directory belongs (yes, some work projects tend to look very
> similar...) and what is the current state of the directory.
>
> As a crude approximation, "git info" should print something like:
> cat .git/config | grep url
> git show | head -3
you're better of just running "gitk --all" at this point. It'll show
remote branches (with the names of remote repos prepended) and their
relations to the local repo.
> Probably not the most intelligent way to compute it, but you get the
> idea. git info should give a brief overview over the current working
> directory.
Like what? None of the commands you suggested even touch it.
Would
git remote -r -v && git log --max-count=1 --pretty=format:'%h %s'
do what you think is what you need?
May I suggest you to consider just running "git fetch -v"?
^ permalink raw reply
* Re: git config error message
From: Alex Riesen @ 2007-11-12 22:23 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711120735p653c643eveb44627bf4532b1a@mail.gmail.com>
Jon Smirl, Mon, Nov 12, 2007 16:35:07 +0100:
> I'm not in a git repo, this error message is misleading.
>
> jonsmirl@terra:~/foo$ git config remote.origin.url
> http://git.digispeaker.com/projects/digispeaker-kernel.git
> could not lock config file
>
Cygwin or any crashes in this repo lately?
If cygwin, than we probably have a file handle leak in config code.
^ permalink raw reply
* Re: git config error message
From: Johannes Schindelin @ 2007-11-12 22:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071112222317.GF2918@steel.home>
Hi,
On Mon, 12 Nov 2007, Alex Riesen wrote:
> Jon Smirl, Mon, Nov 12, 2007 16:35:07 +0100:
> > I'm not in a git repo, this error message is misleading.
> >
> > jonsmirl@terra:~/foo$ git config remote.origin.url
> > http://git.digispeaker.com/projects/digispeaker-kernel.git
> > could not lock config file
> >
>
> Cygwin or any crashes in this repo lately?
> If cygwin, than we probably have a file handle leak in config code.
He said that he's not in a git repo. Thus, .git/config does not exist,
and is not lockable, since not even .git/ exists.
Ciao,
Dscho
^ permalink raw reply
* Re: git config error message
From: Alex Riesen @ 2007-11-12 22:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711122224190.4362@racer.site>
Johannes Schindelin, Mon, Nov 12, 2007 23:24:54 +0100:
> Hi,
>
> On Mon, 12 Nov 2007, Alex Riesen wrote:
>
> > Jon Smirl, Mon, Nov 12, 2007 16:35:07 +0100:
> > > I'm not in a git repo, this error message is misleading.
> > >
> > > jonsmirl@terra:~/foo$ git config remote.origin.url
> > > http://git.digispeaker.com/projects/digispeaker-kernel.git
> > > could not lock config file
> > >
> >
> > Cygwin or any crashes in this repo lately?
> > If cygwin, than we probably have a file handle leak in config code.
>
> He said that he's not in a git repo. Thus, .git/config does not exist,
> and is not lockable, since not even .git/ exists.
>
Oh.
^ permalink raw reply
* Re: Installing without rebuilding
From: Brian Gernhardt @ 2007-11-12 22:33 UTC (permalink / raw)
To: Git Mailing List, Benoit Sigoure
In-Reply-To: <8B92E213-17DB-4E83-B045-01CE0E7D26CB@silverinsanity.com>
On Nov 11, 2007, at 11:49 AM, Brian Gernhardt wrote:
> Git has a very clever Makefile. Sometimes its a little overly clever.
I found a way around the Makefile cleverness. It's ugly, but it
requires no changes to the existing Makefile. I'm posting it in case
anyone finds this thread trying to do what I'm doing. My nieve
suggestion fails, BTW, because git-gui's Makefile does the same
cleverness.
----- 8< -----
# Install ignoring version changes, etc.
ignore="-o GIT-VERSION-FILE -o GIT-CFLAGS -o GIT-GUI-VARS"
install="$ignore prefix=/usr/local/stow/git"
gitgui="$install gitexecdir=/usr/local/bin"
sudo make $install NO_TCLTK=Yes install install-doc
sudo make $gitgui -C git-gui install
----- 8< -----
Why do I have to go through so many hoops just to install what I've
already compiled?
~~ Brian
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Junio C Hamano @ 2007-11-12 22:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Yin Ping, git
In-Reply-To: <Pine.LNX.4.64.0711120950370.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 12 Nov 2007, Johannes Sixt wrote:
>
>> Junio C Hamano schrieb:
>>
>> > I am not saying that it is wrong to use submodule to track such groups
>> > of source trees whose versions are very closely tied together. At
>> > least not yet.
>>
>> In KDE, the supermodule will actually just be a container that binds the
>> submodules together. The essential development will happen in the
>> submodules, and the supermodule will receive a commit quite frequently.
>> In this case, there will often be only a few or a few dozen commits
>> listed, and I anticipate that the integrator who is going to make the
>> commit (to the supermodule) will probably like the summary. So I'm all
>> for it.
>
> I like it, too. And we can make the number of shown commits configurable,
> just like for the merge summary.
Very good point. In the case J6t uses for his illustration
above, changing the submodule bound to the superproject is more
or less like merging.
> But I'd rather see the code in wt-status.c than in
> git-submodule.sh.
I do not have a strong preference either way, but submodule-loving
people may want to say "git submodule shortlog <path>" or whatever
from the command line.
Making a standalone function that takes two commits from the
subproject and produces the output, and calling that function
from both git-submodule (to implement the above "shortlog"
subcommand) and from wt-status.c (to show what Yin wants to add,
only when "status.submodule" is set), would be a reasonable
implementation.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Jakub Narebski @ 2007-11-12 22:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vzlxj15xe.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>> Johannes Schindelin wrote:
>>
>>> But since you're one of the people knowing git _internals_ pretty
>>> well, here's another reason just for you why this cannot be done:
>>> There is no way to find out where the HEAD points to.
>>
>> $ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD
>> refs/heads/master
>
> Johannes is talking about the lack of native protocol support to
> transfer symref information. That's the reason git-clone dances
> around finding where HEAD really points at. It simply does not
> know -- all it gets about a symref is what SHA-1 the ref points
> at.
Do I remember correctly that there was some talk about extending git
protocol to avoid this compicated dance, and transfer symbolic refs
directly?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Call refresh_cache() when updating the user index for --only commits.
From: Junio C Hamano @ 2007-11-12 23:01 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <1194900502-8987-1-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> We're guaranteeing the user that the index will be stat-clean after
> git commit. Thus, we need to call refresh_cache() for the user index too,
> in the 'git commit <paths>' case.
>
> Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> ---
> builtin-commit.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 5011b8b..35205ef 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -109,6 +109,7 @@ static char *prepare_index(const char **files, const char *prefix)
>
> /* update the user index file */
> add_files_to_cache(verbose, prefix, files);
> + refresh_cache(REFRESH_QUIET);
> if (write_cache(fd, active_cache, active_nr) || close(fd))
> die("unable to write new_index file");
>
Ah. This is the real index file that is left for the user after
a partial commit "git-commit <path>" returns.
The other refresh_cache() after this one does not matter if we
did not have hook scripts, but it is not very easy to cheaply
detect if we are not going to run any hooks so let's leave it
there.
Thanks.
^ permalink raw reply
* Re: git config error message
From: Jakub Narebski @ 2007-11-12 23:09 UTC (permalink / raw)
To: git
In-Reply-To: <20071112222629.GG2918@steel.home>
Alex Riesen wrote:
> Johannes Schindelin, Mon, Nov 12, 2007 23:24:54 +0100:
>> Hi,
>> On Mon, 12 Nov 2007, Alex Riesen wrote:
>>> Jon Smirl, Mon, Nov 12, 2007 16:35:07 +0100:
>>>
>>>> I'm not in a git repo, this error message is misleading.
>>>>
>>>> jonsmirl@terra:~/foo$ git config remote.origin.url
>>>> http://git.digispeaker.com/projects/digispeaker-kernel.git
>>>> could not lock config file
>>>>
>>>
>>> Cygwin or any crashes in this repo lately?
>>> If cygwin, than we probably have a file handle leak in config code.
>>
>> He said that he's not in a git repo. Thus, .git/config does not exist,
>> and is not lockable, since not even .git/ exists.
>>
>
> Oh.
And neither does per-user config file (I triet to reproduce this error, and
forgot about ~/.gitconfig file).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: wishlist: git info
From: Thomas Neumann @ 2007-11-12 22:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071112222106.GE2918@steel.home>
> you're better of just running "gitk --all" at this point. It'll show
> remote branches (with the names of remote repos prepended) and their
> relations to the local repo.
hm, this is not what I am after. I do not want to inspect the history, I
want to see where this repository "belongs" to. Gitk shows me the name
(which is reasonable, of course), but not the URL. And it is a GUI
application, which is not so perfect.
>> Probably not the most intelligent way to compute it, but you get the
>> idea. git info should give a brief overview over the current working
>> directory.
>
> Like what? None of the commands you suggested even touch it.
probably "current working directory" was not the best way to phrase it.
I mean state of the repository, which in my case is a clone of a central
repository.
My commands show (ignoring formatting): 1. the remote repositories with
URL 2. the current head commit hash 3. the date of the head commit.
Which gives a pretty decent idea about the state of the repository.
> Would
>
> git remote -r -v && git log --max-count=1 --pretty=format:'%h %s'
>
> do what you think is what you need?
perhaps, the first command gives me an error (git 1.5.2.5). This here is
nearly ok
git remote && git log --max-count=1 --pretty=format:'%H %cD'
except the missing URL from git remote (but perhaps your options include
it with a newer git version, will test).
> May I suggest you to consider just running "git fetch -v"?
this is has side effects, and is quite slow. Your command sequence above
is more handy (and faster).
So I can emulate git info with an alias, and this is good enough for mew
now, thanks for the hints. Perhaps a somewhat more elaborate version of
git info might be useful for others, too, but this is not urgent.
Thomas
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS
From: Alex Riesen @ 2007-11-12 23:31 UTC (permalink / raw)
To: Bill Lear; +Cc: git, nfs, linux-kernel
In-Reply-To: <18232.29603.856766.275854@lisa.zopyra.com>
Bill Lear, Mon, Nov 12, 2007 16:39:15 +0100:
> On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes:
> >Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100:
> >> I've brought this up before, but I don't recall a resolution to it.
> >>
> >> We have an NFS-mounted filesystem, and git pull is choking on it.
> >>
> >> % uname -a
> >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
It is a really old kernel... Maybe you could try with some of the
recent ones?
> >> % git --version
> >> git version 1.5.3.5
> >>
> >> % git pull
> >> remote: Generating pack...
> >> remote: Done counting 998 objects.
> >> remote: Result has 836 objects.
> >> remote: Deltifying 836 objects.
> >> remote: 100% (836/836) done
> >> Indexing 836 objects...
> >> remote: Total 836 (delta 526), reused 688 (delta 380)
> >> 100% (836/836) done
> >> Resolving 526 deltas...
> >> fatal: cannot pread pack file: No such file or directory
> >
> >Could you please strace it? With strace -ff?
> >
> >> fatal: index-pack died with error code 128
> >> fatal: Fetch failure: git://source/repo
> >>
> >> I looked through the archives of this list and did not see a final
> >> resolution, other than a suspected bug in the OS NFS code.
> >
> >Strace, just to be on the safe side
>
> Ok, I've done the strace -ff. It has generated 176 strace.out.<pid>
> files. I have placed a tarball of these files on my home server:
>
> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
>
> The file strace.out.25526 has, at the very end:
>
Yes, this is the file.
I extend the part you quoted. The file is opened here:
open(".git/objects/pack_awOTNW", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
write(3, "PACK\0\0\0\2\0\0\3r", 12) = 12
... lots of data. Counted writes: 488538...
write(3, "v\351\247V\325\362\327/\240\265\211\211\322,\261\210\301"..., 4096) = 4096
write(3, "\202\202g\232Bf\211Bf\261Bb\36X\22\4\364\365\25\22\223"..., 1114) = 1114
write(3, "M", 1) = 1
> write(2, "Resolving 551 deltas.\n", 22) = 22
> pread64(3, "", 242, 541) = 0
That's the problem. Hmm... May I kindly suggest moving the topic to
linux-nfs (cc-ed along with lk)?
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS
From: Alex Riesen @ 2007-11-12 23:33 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18232.29603.856766.275854@lisa.zopyra.com>
This is the almost same message I cced to lk and nfs, but with
Git-interasting parts added.
Bill Lear, Mon, Nov 12, 2007 16:39:15 +0100:
> On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes:
> >Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100:
> >> I've brought this up before, but I don't recall a resolution to it.
> >>
> >> We have an NFS-mounted filesystem, and git pull is choking on it.
> >>
> >> % uname -a
> >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
It is a really old kernel... Maybe you could try with some of the
recent ones?
> >> % git --version
> >> git version 1.5.3.5
> >>
> >> % git pull
> >> remote: Generating pack...
> >> remote: Done counting 998 objects.
> >> remote: Result has 836 objects.
> >> remote: Deltifying 836 objects.
> >> remote: 100% (836/836) done
> >> Indexing 836 objects...
> >> remote: Total 836 (delta 526), reused 688 (delta 380)
> >> 100% (836/836) done
> >> Resolving 526 deltas...
> >> fatal: cannot pread pack file: No such file or directory
> >
> >Could you please strace it? With strace -ff?
> >
> >> fatal: index-pack died with error code 128
> >> fatal: Fetch failure: git://source/repo
> >>
> >> I looked through the archives of this list and did not see a final
> >> resolution, other than a suspected bug in the OS NFS code.
> >
> >Strace, just to be on the safe side
>
> Ok, I've done the strace -ff. It has generated 176 strace.out.<pid>
> files. I have placed a tarball of these files on my home server:
>
> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
>
> The file strace.out.25526 has, at the very end:
>
Yes, this is the file.
I extend the part you quoted. The file is opened here:
open(".git/objects/pack_awOTNW", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
write(3, "PACK\0\0\0\2\0\0\3r", 12) = 12
... lots of data. Counted writes: 488538...
write(3, "v\351\247V\325\362\327/\240\265\211\211\322,\261\210\301"..., 4096) = 4096
write(3, "\202\202g\232Bf\211Bf\261Bb\36X\22\4\364\365\25\22\223"..., 1114) = 1114
write(3, "M", 1) = 1
> write(2, "Resolving 551 deltas.\n", 22) = 22
> pread64(3, "", 242, 541) = 0
That's the problem.
"Git-interesting parts"
> write(2, "fatal: ", 7) = 7
> write(2, "cannot pread pack file: Success", 31) = 31
This is strange. The current git should not produce anything like
this (and does not, here). The code in question is:
do {
ssize_t n = pread(pack_fd, data + rdy, len - rdy, from + rdy);
if (n <= 0)
die("cannot pread pack file: %s", strerror(errno));
rdy += n;
} while (rdy < len);
Either your strace or that kernel seem to have clobbered errno, too.
> fstat64(0, 0xffff907c) = 0
> open("/etc/mtab", O_RDONLY) = 4
> fstat64(0x4, 0xffff6810) = 0
Interesing. What in git index-pack can read mtab and what for?
Is it vanilla Git or have you instrumented it somehow?
> [ Process PID=25347 runs in 32 bit mode. ]
> umovestr: Input/output error
> umovestr: Input/output error
Is it your strace?
Do you have anything unusual in syslog?
BTW, you could try defining NO_PREAD in config.mak, and see if it
works the problem around for you.
^ permalink raw reply
* Re: wishlist: git info
From: Alex Riesen @ 2007-11-12 23:41 UTC (permalink / raw)
To: Thomas Neumann; +Cc: git
In-Reply-To: <4738D8AA.1030604@users.sourceforge.net>
Thomas Neumann, Mon, Nov 12, 2007 23:50:18 +0100:
> >> Probably not the most intelligent way to compute it, but you get the
> >> idea. git info should give a brief overview over the current working
> >> directory.
> >
> > Like what? None of the commands you suggested even touch it.
> probably "current working directory" was not the best way to phrase it.
> I mean state of the repository, which in my case is a clone of a central
> repository.
> My commands show (ignoring formatting): 1. the remote repositories with
> URL 2. the current head commit hash 3. the date of the head commit.
Don't you want to know where the remote repo is at?
> Which gives a pretty decent idea about the state of the repository.
...which in Git-lingo would be misunderstood as the output of
git-status :)
> > Would
> >
> > git remote -r -v && git log --max-count=1 --pretty=format:'%h %s'
> >
> > do what you think is what you need?
> perhaps, the first command gives me an error (git 1.5.2.5). This here is
> nearly ok
Ach, make it "git remote -v". It does exactly showing of the url.
Dunno what I wanted the "-r" for. Probably left from thinking of
"git branch -r" (which shows remote branches).
> git remote && git log --max-count=1 --pretty=format:'%H %cD'
>
> except the missing URL from git remote (but perhaps your options include
> it with a newer git version, will test).
It is there since 1.5.3-rc1
^ 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