* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Rene Scharfe @ 2006-06-20 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Florian Forster, git, Linus Torvalds
In-Reply-To: <7vac8860z9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> BTW, I think we would probably want to have this patch on top of
> Rene's patch. In all instances, the variable "buf" is of type
> "const char *" and the existing casts do not make sense to me.
>
>
> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
> index 5c8a5f0..39a61b6 100644
Your patch reverts builtin-tar-tree.c to the version which is
currently both in master and next, which I think is a good
change. However, could it be avoided at merge time?
OT: I found the blobs 5c8a5f0 and 39a61b6 by guessing (they are
builtin-tar-tree.c in pu and master, respectively). OK, that
was easy. But is there a way to reversely look up an object
without guessing, i.e. find out which commit(s) introduced a
certain blob?
Thanks,
René
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Jeff Garzik @ 2006-06-20 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pyhdel5.fsf@assigned-by-dhcp.cox.net>
Here's a real world example of the 1.4.0 change breaking a merge:
("netdev-2.6" == local clone of kernel.org/...jgarzik/netdev-2.6.git)
[jgarzik@pretzel netdev-2.6]$ git branch
ALL
e100-sbit
* master
upstream
upstream-linus
[jgarzik@pretzel netdev-2.6]$ git pull /spare/repo/linux-2.6
Generating pack...
Done counting 3427 objects.
Result has 2510 objects.
Deltifying 2510 objects.
100% (2510/2510) done
Unpacking 2510 objects
Total 2510, written 2510 (delta 2024), reused 0 (delta 0)
100% (2510/2510) done
Updating from 427abfa28afedffadfca9dd8b067eb6d36bac53f to
25f42b6af09e34c3f92107b36b5aa6edc2fdba2f
fatal: Untracked working tree file 'drivers/net/myri10ge/Makefile' would
be overwritten by merge.
EXPLANATION:
* drivers/net/myri10ge/Makefile exists in latest Linus kernel tree,
stored locally in /spare/repo/linux-2.6.
* drivers/net/myri10ge/Makefile exists in netdev-2.6#upstream and
netdev-2.6#upstream-linus branches.
* drivers/net/myri10ge/Makefile does not exist in current branch,
netdev-2.6#master.
^ permalink raw reply
* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Junio C Hamano @ 2006-06-20 8:58 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <4497AED4.5060505@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>> BTW, I think we would probably want to have this patch on top of
>> Rene's patch. In all instances, the variable "buf" is of type
>> "const char *" and the existing casts do not make sense to me.
>>
>> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
>> index 5c8a5f0..39a61b6 100644
>
> Your patch reverts builtin-tar-tree.c to the version which is
> currently both in master and next, which I think is a good
> change. However, could it be avoided at merge time?
Sorry for attributing those "casts [that] do not make sense to
me" to you -- it is not your code but part of Florian's patch.
I think applying the patch in question on top of Florian's 11172e
would be the most sensible, since that is currently the tip of ff/c99
topic branch whose early parts have been merged to "next" and
the tip to "pu". When Linus feels as sympathetic as I do, we
can pull the rest of ff/c99 branch to "next" and then eventually
to "master" and the patch will be merged together without
introducing the nonsense casts.
Another possibility is to amend the tip of ff/c99 topic branch,
since it is not merged to "next" yet. I promised not to rewind
"master" nor "next", but never made promises not to rewind "pu",
so it is a fair game. I think it is simpler and cleaner, so
that will be what I will do.
> OT: I found the blobs 5c8a5f0 and 39a61b6 by guessing (they are
> builtin-tar-tree.c in pu and master, respectively). OK, that
> was easy. But is there a way to reversely look up an object
> without guessing, i.e. find out which commit(s) introduced a
> certain blob?
You could do something like this (totally untested).
Going from the above "diff --git" index line you have object
name abbreviations and pathnames as clues. To take advantage of
it, you could use "git rev-list pu -- builtin-tar-tree.c"
instead of unlimited list.
$ git rev-list pu |
git diff-tree -r --stdin --pretty |
perl -e '
my @lines = ();
sub flush_em {
my @found = ();
my @comment = ();
for my $l (@lines) {
if ($l !~ /^:/) {
push @comment, $l;
next;
}
for (@ARGV) {
if ($l =~ / $_/) {
push @found, $l;
last;
}
}
}
if (@found) {
print join("", @comment, @found);
}
@lines = ();
}
while (<STDIN>) {
if (/^commit [0-9a-f]{40}$/) { flush_em(); }
push @lines, $_;
}
flush_em();
' 39a61b6 5c8a5f0
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Junio C Hamano @ 2006-06-20 9:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200606201012.31684.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Doesn't work well with values outside us-ascii, but that might be
> considered web browser bug (misfeature), not a bug in gitweb.
That's sad.
Are you sure about it?
What does start_td({-title=>"blah"}) produce? <td title="blah">?
If so, is http://members.cox.net/junkio/t.html close to what you
are trying to achieve here?
> "<td>$pr->{'descr'}</td>\n" .
> - "<td><i>" . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
> + $cgi->start_td({-title => $pr->{'owner'}}) . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
Where did the opening <i> go? Not that I care about italics,
since I think this should all be done with stylesheet, but I do
care about unbalanced pairs.
BTW, I haven't nailed down the procedure to update the
kernel.org gitweb installations (I suspect the burden is on me
since Kay orphaned gitweb onto me).
I wonder if there is somebody who is willing to run gitweb from
the "next" branch on some public site, so that I can be
reasonably confident before breaking one of the most important
infrastructure of the kernel development? Volunteers?
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Ryan Anderson @ 2006-06-20 9:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Junio C Hamano, git
In-Reply-To: <4497B39E.2050205@garzik.org>
On Tue, Jun 20, 2006 at 04:36:46AM -0400, Jeff Garzik wrote:
> Here's a real world example of the 1.4.0 change breaking a merge:
>
> ("netdev-2.6" == local clone of kernel.org/...jgarzik/netdev-2.6.git)
> [jgarzik@pretzel netdev-2.6]$ git branch
> ALL
> e100-sbit
> * master
> upstream
> upstream-linus
>
> [jgarzik@pretzel netdev-2.6]$ git pull /spare/repo/linux-2.6
> Generating pack...
> Done counting 3427 objects.
> Result has 2510 objects.
> Deltifying 2510 objects.
> 100% (2510/2510) done
> Unpacking 2510 objects
> Total 2510, written 2510 (delta 2024), reused 0 (delta 0)
> 100% (2510/2510) done
> Updating from 427abfa28afedffadfca9dd8b067eb6d36bac53f to
> 25f42b6af09e34c3f92107b36b5aa6edc2fdba2f
> fatal: Untracked working tree file 'drivers/net/myri10ge/Makefile' would
> be overwritten by merge.
>
> EXPLANATION:
>
> * drivers/net/myri10ge/Makefile exists in latest Linus kernel tree,
> stored locally in /spare/repo/linux-2.6.
> * drivers/net/myri10ge/Makefile exists in netdev-2.6#upstream and
> netdev-2.6#upstream-linus branches.
> * drivers/net/myri10ge/Makefile does not exist in current branch,
> netdev-2.6#master.
If that is the case, how did it get into the directory, then?
I suspect the history we're missing is this:
git checkout upstream
...
git checkout -f master
If you have a clean tree, there's not really a reason to use -f. It
actively hurts you by confusing git as to what state your directory is
in. (If you don't have a clean tree, well, using -f will orphan new
files that Git knows about, and overwrite the changes on ones it does,
so it's still rather inconsistent, and probably not at all what you
intend.)
Instead of using "git checkout -f" to abandon any WIP, try something
like this:
git branch throw-away HEAD
git checkout throw-away
git commit -a -m "throw away"
git checkout $1
git branch -D throw-away
i.e:
$ sed -i -e 's/PHONY/YNOHP/g' Makefile
$ git branch throw-away HEAD
$ git checkout throw-away
$ git diff |diffstat
Makefile | 60 ++++++++++++++++++++++++++++++------------------------------
$ git commit -a -m "throw-away"
$ git checkout master
$ git branch -d throw-away
The branch 'throw-away' is not a strict subset of your current HEAD.
If you are sure you want to delete it, run 'git branch -D throw-away'.
$ git branch -D throw-away
Deleted branch throw-away.
$ git diff | diffstat
0 files changed
$ git branch throw-away HEAD
$ cp Makefile Makefile-ryan
$ git add Makefile-ryan
$ git checkout throw-away
$ git diff | diffstat
0 files changed
$ git status
# On branch refs/heads/throw-away
#
# Updated but not checked in:
# (will commit)
#
# new file: Makefile-ryan
#
$ git commit -a -m "throw-away"
$ git checkout master
$ git status
nothing to commit
Note that using plain "checkout" should be noticeably faster, too.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Junio C Hamano @ 2006-06-20 9:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <4497B39E.2050205@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> Here's a real world example of the 1.4.0 change breaking a merge:
>
> ("netdev-2.6" == local clone of kernel.org/...jgarzik/netdev-2.6.git)
> [jgarzik@pretzel netdev-2.6]$ git branch
> ALL
> e100-sbit
> * master
> upstream
> upstream-linus
>
> [jgarzik@pretzel netdev-2.6]$ git pull /spare/repo/linux-2.6
> ...
> Updating from 427abfa28afedffadfca9dd8b067eb6d36bac53f to
> 25f42b6af09e34c3f92107b36b5aa6edc2fdba2f
> fatal: Untracked working tree file 'drivers/net/myri10ge/Makefile'
> would be overwritten by merge.
>
> EXPLANATION:
>
> * drivers/net/myri10ge/Makefile exists in latest Linus kernel tree,
> stored locally in /spare/repo/linux-2.6.
> * drivers/net/myri10ge/Makefile exists in netdev-2.6#upstream and
> netdev-2.6#upstream-linus branches.
> * drivers/net/myri10ge/Makefile does not exist in current branch,
> netdev-2.6#master.
Requesting one more bit of explanation.
When you did this pull, you were on your "master" branch. Whose
HEAD does not have the myri10ge/Makefile in its tree. And you
did not have that path in the index either (otherwise it would
not have said "untracked working tree file"). Did you have that
file in your working tree? And if so how/why?
If you did something like this before ending up in your "master"
branch, I think you would have such a file:
$ git branch ;# you were in upstream-linus branch
ALL
e100-sbit
master
upstream
* upstream-linus
$ git diff ;# and were up-to-date -- no output nor
$ git diff HEAD ;# local changes
$ git checkout -f master ;# but you switched to master with -f
With "checkout -f", your local changes to files that appear in
the "master" branch will be overwritten, but the files that are
supposed to disappear because you are switching out of the
current branch (e.g. myri10ge/Makefile) are left behind.
It probably would make sense to change "checkout -f" so that it
removes such files from your working tree to support this
particular usage. We kept saying "with -f local dirty state
will be gone", but "checkout -f" does not do as thorough job as
"reset --hard". Changing "checkout -f next-branch" to do the
moral equivalent of "reset --hard HEAD && checkout next-branch"
would solve this problem, and I do not think changing it that
way would not have any negative impact.
I suspect this patch would do exactly that...
diff --git a/git-checkout.sh b/git-checkout.sh
index 564117f..193f6c5 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -137,7 +137,7 @@ # what we already had
if [ "$force" ]
then
- git-read-tree --reset $new &&
+ git-read-tree --reset -u $new &&
git-checkout-index -q -f -u -a
else
git-update-index --refresh >/dev/null
^ permalink raw reply related
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Timo Hirvonen @ 2006-06-20 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jnareb, git
In-Reply-To: <7vd5d4chmg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I wonder if there is somebody who is willing to run gitweb from
> the "next" branch on some public site, so that I can be
> reasonably confident before breaking one of the most important
> infrastructure of the kernel development? Volunteers?
I can help.
http://onion.dynserv.net/git/gitweb.cgi
Note: http://onion.dynserv.net/git/ (index.cgi) is an old version.
Global symbol "$path" requires explicit package name at
/var/www/localhost/htdocs/git/gitweb.cgi line 1521.
Execution of /var/www/localhost/htdocs/git/gitweb.cgi aborted due to
compilation errors.
The line is:
$file =~ m#^/# or $file = "$projectroot/$path/$file";
$path seems to be undefined. I don't understand perl very well so I
can't fix it.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Jakub Narebski @ 2006-06-20 9:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5d4chmg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Doesn't work well with values outside us-ascii, but that might be
>> considered web browser bug (misfeature), not a bug in gitweb.
>
> That's sad.
>
> Are you sure about it?
Now I see I was wrong.
> What does start_td({-title=>"blah"}) produce? <td title="blah">?
> If so, is http://members.cox.net/junkio/t.html close to what you
> are trying to achieve here?
Yes, that is what I tried to achieve. Using CGI to set attributes
was to quote characters which cannot be in double quited attribute values,
i.e. change '"' to '"' or '"'. I don't know what start_td did with
\"o character (Perl v5.8.6, CGI::VERSION=3.05).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] checkout -f: do not leave untracked working tree files.
From: Junio C Hamano @ 2006-06-20 9:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git, Ryan Anderson
In-Reply-To: <7vr71kb257.fsf@assigned-by-dhcp.cox.net>
Earlier we did not consider untracked working tree files
"precious", but we have always considered them fair game to
clobber. These days, branch switching by read-tree is more
careful and tries to protect untracked working tree files. This
caused the following workflow to stop working:
git checkout one-branch-with-file-F
git checkout -f another-without-file-F
git pull . one-branch-with-file-F
Because the second checkout leaves F from the previous state as
untracked file in the working tree, the merge would fail, trying
to protect F from being clobbered.
This changes "git checkout -f" to remove working tree files that
are known to git in the switched-from state but do not exist in
the switched-to state, borrowing the same logic from "reset --hard".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I am going to bed without trying this out since it is very
late tonight. Might be in "pu" or "next" tomorrow depending
on my mood. If this works out for Jeff, I can simply drop
the "core.oktoclobber = ask" patch from my topics -- although
I kind of liked that one ;-).
git-checkout.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 564117f..77c2593 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -137,8 +137,7 @@ # what we already had
if [ "$force" ]
then
- git-read-tree --reset $new &&
- git-checkout-index -q -f -u -a
+ git-read-tree --reset -u $new
else
git-update-index --refresh >/dev/null
merge_error=$(git-read-tree -m -u $old $new 2>&1) || (
--
1.4.0.g59268
^ permalink raw reply related
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Jakub Narebski @ 2006-06-20 9:59 UTC (permalink / raw)
To: git
In-Reply-To: <20060620124606.4e3e226c.tihirvon@gmail.com>
Timo Hirvonen wrote:
> http://onion.dynserv.net/git/gitweb.cgi
>
> Global symbol "$path" requires explicit package name at
> /var/www/localhost/htdocs/git/gitweb.cgi line 1521.
> Execution of /var/www/localhost/htdocs/git/gitweb.cgi aborted due to
> compilation errors.
>
> The line is:
>
> $file =~ m#^/# or $file = "$projectroot/$path/$file";
>
> $path seems to be undefined. I don't understand perl very well so I
> can't fix it.
Temporary fix is in:
"[PATCH] Fix: Support for the standard mime.types map in gitweb"
(Message-Id: <11507843541678-git-send-email-jnareb@gmail.com>)
http://permalink.gmane.org/gmane.comp.version-control.git/22172
BTW. I have _my_ version at
http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Timo Hirvonen @ 2006-06-20 10:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e78gun$65s$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> Timo Hirvonen wrote:
>
> > http://onion.dynserv.net/git/gitweb.cgi
> >
> > Global symbol "$path" requires explicit package name at
> > /var/www/localhost/htdocs/git/gitweb.cgi line 1521.
> > Execution of /var/www/localhost/htdocs/git/gitweb.cgi aborted due to
> > compilation errors.
> >
> > The line is:
> >
> > $file =~ m#^/# or $file = "$projectroot/$path/$file";
> >
> > $path seems to be undefined. I don't understand perl very well so I
> > can't fix it.
>
> Temporary fix is in:
>
> "[PATCH] Fix: Support for the standard mime.types map in gitweb"
> (Message-Id: <11507843541678-git-send-email-jnareb@gmail.com>)
> http://permalink.gmane.org/gmane.comp.version-control.git/22172
Seems to work now. I also enabled blame and it works too. But I noticed
that the search is sometimes broken. If you click a "blob" link and
then try to search something gitweb will complain:
403 Forbidden - Unknown commit object.
"h" parameter is blob, not commit. Shouldn't the h parameter be set to
HEAD always when searching? Searching starts at h so the search results
vary:
http://onion.dynserv.net/git/gitweb.cgi?p=cmus.git&a=search&h=HEAD&s=pickaxe%3Atheme
http://onion.dynserv.net/git/gitweb.cgi?p=cmus.git&a=search&h=fd2d983d51858e25cc71b14b59c787e1683ba7c5&s=pickaxe%3Atheme
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Santi Béjar @ 2006-06-20 11:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff Garzik, git, Ryan Anderson
In-Reply-To: <7vfyi0b1gv.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Earlier we did not consider untracked working tree files
> "precious", but we have always considered them fair game to
> clobber. These days, branch switching by read-tree is more
> careful and tries to protect untracked working tree files. This
> caused the following workflow to stop working:
>
> git checkout one-branch-with-file-F
> git checkout -f another-without-file-F
> git pull . one-branch-with-file-F
>
> Because the second checkout leaves F from the previous state as
> untracked file in the working tree, the merge would fail, trying
> to protect F from being clobbered.
>
> This changes "git checkout -f" to remove working tree files that
> are known to git in the switched-from state but do not exist in
> the switched-to state, borrowing the same logic from "reset --hard".
>
I agree with this patch (without testing).
Another thing to take into account is that, for this particular
case/sequence, the untracked file-F is exactly the same as the one from
the pull, so you are not overwritting that file and it could succeed.
Santi
^ permalink raw reply
* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Junio C Hamano @ 2006-06-20 11:18 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <8764iw5bvl.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> Another thing to take into account is that, for this particular
> case/sequence, the untracked file-F is exactly the same as the one from
> the pull, so you are not overwritting that file and it could succeed.
Yes and no. The untracked file is not even known to git when
pull is happening (that is the definition of "untracked"). Yes,
we could see if the contents happen to match and choose to
overwrite, but I think it is often more likely that the contents
do not match that it is not worth it (I have not examined what
it would involve to add that check yet, so it might turn out to
be a cheap check but I doubt it).
^ permalink raw reply
* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Alexander Litvinov @ 2006-06-20 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <7vfyi09isf.fsf@assigned-by-dhcp.cox.net>
Good news. I have a habbit to switch branches using two commands:
git checkout -f second-branch
git clean -d -q
Now this will work with single command. Thanks.
^ permalink raw reply
* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Junio C Hamano @ 2006-06-20 11:51 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Santi Béjar, git
In-Reply-To: <200606201827.50808.lan@academsoft.ru>
Alexander Litvinov <lan@academsoft.ru> writes:
> Good news. I have a habbit to switch branches using two commands:
>
> git checkout -f second-branch
> git clean -d -q
>
> Now this will work with single command. Thanks.
"will" meaning "you suspect" or "you tried and confirmed"?
^ permalink raw reply
* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Alexander Litvinov @ 2006-06-20 12:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveqw82qd.fsf@assigned-by-dhcp.cox.net>
> "will" meaning "you suspect" or "you tried and confirmed"?
:-) I suspect.
Lets test. Your pu branch (5af05efbeaa06005596129fb111a739a87f8a883) really
works. I have cvs repo and use git for daily work. I have head and 2 branches
from cvs and store CVS/* files in git too. Usualy this operation pruduce a
lot of CVS/Tag files:
git checkout -f cvs-v52 (this is one of by cvs's branch)
cvs -q up -dP (nothing have been updated)
git checkout -f master (this is a dev branch from cvs head)
git status
pu branch nuke them when use git checkout -f !
^ permalink raw reply
* upload-pack is unsafe in corrupt repository
From: Junio C Hamano @ 2006-06-20 12:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I was helping Andrew fetching from maintainer trees. One of the
trees were corrupt (i.e. git-fsck-objects unclean) and there was
a rather grave consequences we found out the hard way (and it is
5am but Tuesday is not my git day X-<).
upload-pack forks a pipeline, whose upstream execs rev-list and
downstream execs pack-objects. rev-list correctly notices that
it cannot reach some objects and dies, but pack-objects just
says "Ah, the list of object input just ended -- let's send them
all". This results in git-fetch-pack to be fed an incomplete
pack. However, git-unpack-objects is happy (the pack is not
corrupt, just that it does not contain what the protocol
exchange expected to send) and git-fetch-pack ends up going all
the way through updating the ref.
Eek.
At this moment, I am just reporting this because I am too tired
to code it myself right now, but I think the fix is to make
upload-pack to fork once more, waitpid() for rev-list and
inject/append garbage in the stream pack-objects produces, in
order to cause unpack-objects (or index-pack) that runs on the
the fetching end to notice, when rev-list or pack-objects barf.
Of course a nicer fix is to add the sideband we have been
discussing about, but that relies on protocol extension and
would not solve the problem for older clients.
Side note: in my head, the sideband would work by the "forked
once more" upload-pack process to listen to both stdout and
stderr of pack-objects, and feed them packetized (instead of the
current "go-straight-stream") by perhaps prefixing them with one
byte (is this a payload, or is this a progress-bar/keepalive type
packet). Of course, this would change the way the payload is
transferred, so the initial handshake needs to negotiate if the
sideband should be used just like we do other new features like
thin pack transfers.
^ permalink raw reply
* [PATCH] gitweb: Start search from HEAD
From: Timo Hirvonen @ 2006-06-20 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Starting search from whatever the current "h" parameter points to is
wrong. Sometimes it doesn't give all the expected results or may even
fail if h points to an object which is not a commit.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
This patch is against the "next" branch.
gitweb/gitweb.cgi | 11 +----------
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 78e6dd0..3ad23a3 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -292,14 +292,7 @@ EOF
if (!defined $searchtext) {
$searchtext = "";
}
- my $search_hash;
- if (defined $hash) {
- $search_hash = $hash;
- } else {
- $search_hash = "HEAD";
- }
$cgi->param("a", "search");
- $cgi->param("h", $search_hash);
print $cgi->startform(-method => "get", -action => $my_uri) .
"<div class=\"search\">\n" .
$cgi->hidden(-name => "p") . "\n" .
@@ -2328,9 +2321,7 @@ sub git_search {
if (!defined $searchtext) {
die_error("", "Text field empty.");
}
- if (!defined $hash) {
- $hash = git_read_head($project);
- }
+ $hash = "HEAD";
my %co = git_read_commit($hash);
if (!%co) {
die_error(undef, "Unknown commit object.");
--
1.4.0.gd281
^ permalink raw reply related
* Re: wrong check condition in patch-delta.c?
From: Nicolas Pitre @ 2006-06-20 12:28 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0606192332j5b2ee4b9ycf2c63c7b1820204@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 418 bytes --]
On Tue, 20 Jun 2006, Nguyn Thái Ngc Duy wrote:
> Hi,
> While inspecting patch-delta.c, I encounter this:
> if (cp_off + cp_size < cp_size ||
> cp_off + cp_size > src_size ||
> cp_size > size)
> goto bad;
> "cp_off + cp_size < cp_size" doesn't make sense to me. Is it on purpose?
Yes, it absolutely is.
Nicolas
^ permalink raw reply
* Re: [PATCH] gitweb: Start search from HEAD
From: Junio C Hamano @ 2006-06-20 12:31 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060620152515.23e59396.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Starting search from whatever the current "h" parameter points to is
> wrong. Sometimes it doesn't give all the expected results or may even
> fail if h points to an object which is not a commit.
If h is not a commit, perhaps, but wouldn't you expect it to
find things from "next" branch if "h" points at it?
^ permalink raw reply
* Re: [PATCH] Restore SIGCHLD to SIG_DFL where we care about waitpid().
From: Petr Baudis @ 2006-06-20 12:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vslm04j2r.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Jun 20, 2006 at 05:11:40AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> diff --git a/connect.c b/connect.c
> index 52d709e..db7342e 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -581,6 +581,11 @@ int git_connect(int fd[2], char *url, co
> enum protocol protocol = PROTO_LOCAL;
> int free_path = 0;
>
> + /* Without this we cannot rely on waitpid() to tell
> + * what happened to our children.
> + */
> + signal(SIGCHLD, SIG_DFL);
> +
> host = strstr(url, "://");
> if(host) {
> *host = '\0';
It would be nice if at this point of Git development we could already
think about libification when doing things like this (I'd like to do
Git.pm as my little summer project this year). I'd make it part of the
API that the calling application must not defer SIGCHLD, and conversely
put the handler to all the main()s that reach git_connect().
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] gitweb: Use $hash_base as $search_hash if possible
From: Timo Hirvonen @ 2006-06-20 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64iw80uo.fsf@assigned-by-dhcp.cox.net>
$hash (h parameter) does not always point to a commit. Use $hash_base as
$search_hash when it is defined.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
Junio C Hamano <junkio@cox.net> wrote:
> Timo Hirvonen <tihirvon@gmail.com> writes:
>
> > Starting search from whatever the current "h" parameter points to is
> > wrong. Sometimes it doesn't give all the expected results or may even
> > fail if h points to an object which is not a commit.
>
> If h is not a commit, perhaps, but wouldn't you expect it to
> find things from "next" branch if "h" points at it?
I did not change it to start search from tip of the branch. The
current behavior is somewhat confusing but at least it is consistent
with rest of gitweb. For example clicking shortlog link from commit
view shows the current commit at top of the list, not tip of the
current branch.
gitweb/gitweb.cgi | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 78e6dd0..7318512 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -293,7 +293,9 @@ EOF
$searchtext = "";
}
my $search_hash;
- if (defined $hash) {
+ if (defined $hash_base) {
+ $search_hash = $hash_base;
+ } elsif (defined $hash) {
$search_hash = $hash;
} else {
$search_hash = "HEAD";
--
1.4.0.gd281
^ permalink raw reply related
* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Carl Worth @ 2006-06-20 14:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff Garzik, git, Ryan Anderson
In-Reply-To: <7vfyi0b1gv.fsf_-_@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
On Tue, 20 Jun 2006 02:50:08 -0700, Junio C Hamano wrote:
>
> Earlier we did not consider untracked working tree files
> "precious", but we have always considered them fair game to
> clobber. These days, branch switching by read-tree is more
> careful and tries to protect untracked working tree files. This
> caused the following workflow to stop working:
>
> git checkout one-branch-with-file-F
> git checkout -f another-without-file-F
> git pull . one-branch-with-file-F
Another one that a colleague of mine hit is:
git checkout -b branch-without-file branch-with-file
git rm some-file
# Allow for some external changes on branch-with-file
git pull . branch-with-file
One possibility for fixing this case is to make git-rm delete the file
by default, (that is, act as if the current -f option is
passed). There's no real safety concern unless the file is dirty,
(could require -f again for that case).
> If this works out for Jeff, I can simply drop
> the "core.oktoclobber = ask" patch from my topics -- although
> I kind of liked that one ;-).
Fixing the behavior instead of adding configuration is definitely a
good plan.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: packs and trees
From: Jon Smirl @ 2006-06-20 14:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606192313l16b16132r1523f5e05ae1566a@mail.gmail.com>
On 6/20/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 6/20/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > The plan is to modify rcs2git from parsecvs to create all of the git
> > objects for the tree.
>
> Sounds like a good plan. Have you seen recent discussions about it
> being impossible to repack usefully when you don't have trees (and
> resulting performance problems on ext3).
No, I will look back in the archives. If needed we can do a repack
after each file is added. I would hope that git can handle a repack
when the new stuff is 100% deltas from a single file.
If I can't pack the exploded deltas need about 35GB disk space. That
is an awful lot to feed to pack all at once, but it will have trees,
>
> > cvs2svn seems to do a good job at generating the trees.
>
> No doubt. Gut the last stage, and use all the data in the intermediate
> DBs to run a git import. It's a great plan, and if you can understand
> that Python code... all yours ;-)
How hard would it be to adjust cvsps to use cvs2svn's algorithm for
grouping the changesets? I'd rather do this in a C app but I haven't
figured out the guts of parsecvs or cvsps well enough to change the
algorithms. There is no requirement to use external databases, sorting
everything in RAM is fine.
If you are interested in changing the cvsps grouping algorithm I can
look at moding it to write out the revisions as are they are parsed.
Then you only need to save the git sha1 in memory instead of the
file:rev when sorting.
> > exactly sure how the changeset detection algorithms in the three apps
> > compare, but cvs2svn is not having any trouble building changesets for
> > Mozilla. The other two apps have some issues, cvsps throws away some
> > of the branches and parsecvs can't complete the analysis.
>
> Have you tried a recent parsecvs from Keith's tree? There's been quite
> a bit of activity there too. And Keith's interested in sorting out
> incremental imports too, which you need for a reasonable Moz
> transition plan as well.
Keith's parsecvs run ended up in a loop and mine hit a parsecvs error
and then had memory corruption after about eight hours. That was last
week, I just checked the logs and I don't see any comments about
fixing it.
Even after spending eight hours building the changeset info iit is
still going to take it a couple of days to retrieve the versions one
at a time and write them to git. Reparsing 50MB delta files n^2/2
times is a major bottleneck for all three programs.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Log peer address when git-daemon called from inetd
From: David Woodhouse @ 2006-06-20 14:38 UTC (permalink / raw)
To: git; +Cc: jdl
When we run git-daemon from inetd, even with the --verbose option, it
doesn't log the peer address. That logic was only in the standalone
dæmon code -- move it to the execute() function instead. Tested with
both IPv6 and Legacy IP clients, in both inetd and dæmon mode.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Jon Loeliger <jdl@jdl.com>
diff --git a/daemon.c b/daemon.c
index 2f03f99..7d30302 100644
--- a/daemon.c
+++ b/daemon.c
@@ -264,11 +264,34 @@ static int upload(char *dir)
return -1;
}
-static int execute(void)
+static int execute(struct sockaddr *addr)
{
static char line[1000];
int pktlen, len;
+ if (addr) {
+ char addrbuf[256] = "";
+ int port = -1;
+
+ if (addr->sa_family == AF_INET) {
+ struct sockaddr_in *sin_addr = (void *) addr;
+ inet_ntop(addr->sa_family, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
+ port = sin_addr->sin_port;
+#ifndef NO_IPV6
+ } else if (addr && addr->sa_family == AF_INET6) {
+ struct sockaddr_in6 *sin6_addr = (void *) addr;
+
+ char *buf = addrbuf;
+ *buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
+ inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
+ strcat(buf, "]");
+
+ port = sin6_addr->sin6_port;
+#endif
+ }
+ loginfo("Connection from %s:%d", addrbuf, port);
+ }
+
alarm(init_timeout ? init_timeout : timeout);
pktlen = packet_read_line(0, line, sizeof(line));
alarm(0);
@@ -414,8 +437,6 @@ static void check_max_connections(void)
static void handle(int incoming, struct sockaddr *addr, int addrlen)
{
pid_t pid = fork();
- char addrbuf[256] = "";
- int port = -1;
if (pid) {
unsigned idx;
@@ -436,26 +457,7 @@ static void handle(int incoming, struct
dup2(incoming, 1);
close(incoming);
- if (addr->sa_family == AF_INET) {
- struct sockaddr_in *sin_addr = (void *) addr;
- inet_ntop(AF_INET, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
- port = sin_addr->sin_port;
-
-#ifndef NO_IPV6
- } else if (addr->sa_family == AF_INET6) {
- struct sockaddr_in6 *sin6_addr = (void *) addr;
-
- char *buf = addrbuf;
- *buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
- inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
- strcat(buf, "]");
-
- port = sin6_addr->sin6_port;
-#endif
- }
- loginfo("Connection from %s:%d", addrbuf, port);
-
- exit(execute());
+ exit(execute(addr));
}
static void child_handler(int signo)
@@ -751,8 +753,16 @@ int main(int argc, char **argv)
}
if (inetd_mode) {
+ struct sockaddr_storage ss;
+ struct sockaddr *peer = (struct sockaddr *)&ss;
+ socklen_t slen = sizeof(ss);
+
fclose(stderr); //FIXME: workaround
- return execute();
+
+ if (getpeername(0, peer, &slen))
+ peer = NULL;
+
+ return execute(peer);
}
return serve(port);
--
dwmw2
^ permalink raw reply related
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