* Re: [PATCH] parse_date(): fix parsing 03/10/2006
From: Andrew Morton @ 2006-04-05 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, len.brown
In-Reply-To: <7vodzg4l5n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> The comment associated with the date parsing code for three
> numbers separated with slashes or dashes implied we wanted to
> interpret using this order:
>
> yyyy-mm-dd
> yyyy-dd-mm
> mm-dd-yy
> dd-mm-yy
>
> However, the actual code had the last two wrong, and making it
> prefer dd-mm-yy format over mm-dd-yy.
But there was a second problem. Once the parsing had misbehaved, Len
managed to create a commit which was six months in the future:
commit 8313524a0d466f451a62709aaedf988d8257b21c
Author: Bob Moore <robert.moore@intel.com>
Date: Tue Oct 3 00:00:00 2006 -0400
ACPI: ACPICA 20060310
Will your fix prevent that from happening? If not, perhaps some basic
sanity checking might be appropriate.
^ permalink raw reply
* [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-05 6:00 UTC (permalink / raw)
To: git
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.gitignore | 1 +
Documentation/git-clean.txt | 50 +++++++++++++++++++++++++++
Makefile | 2 +
git-clean.sh | 80 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 132 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 75891c3..b5959d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,7 @@ git-checkout
git-checkout-index
git-cherry
git-cherry-pick
+git-clean
git-clone
git-clone-pack
git-commit
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
new file mode 100644
index 0000000..e91b2ed
--- /dev/null
+++ b/Documentation/git-clean.txt
@@ -0,0 +1,50 @@
+git-clean(1)
+============
+
+NAME
+----
+git-clean - Remove untracked files from the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git-clean' [-d | -D] [-n] [-q] [-x]
+
+DESCRIPTION
+-----------
+Removes files unknown to git. This allows to clean the working tree
+from files that are not under version control. If the '-x' option is
+specified, ignored files are also removed, allowing to remove all
+build products.
+
+OPTIONS
+-------
+-d::
+ Remove untracked directories in addition to untracked files.
+
+-n::
+ Don't actually remove anything, just show what would be done.
+
+-q::
+ Be quiet, only report errors, but not the files that are
+ successfully removed.
+
+-x::
+ Don't use the ignore rules. This allows removing all untracked
+ files, including build products. This can be used (possibly in
+ conjunction with gitlink:git-reset[1]) to create a pristine
+ working directory to test a clean build.
+
+-X::
+ Remove only files ignored by git. This may be useful to rebuild
+ everything from scratch, but keep manually created files.
+
+
+Author
+------
+Written by Pavel Roskin <proski@gnu.org>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 145099a..3367b8c 100644
--- a/Makefile
+++ b/Makefile
@@ -114,7 +114,7 @@ ### --- END CONFIGURATION SECTION ---
SCRIPT_SH = \
git-add.sh git-bisect.sh git-branch.sh git-checkout.sh \
- git-cherry.sh git-clone.sh git-commit.sh \
+ git-cherry.sh git-clean.sh git-clone.sh git-commit.sh \
git-count-objects.sh git-diff.sh git-fetch.sh \
git-format-patch.sh git-log.sh git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
diff --git a/git-clean.sh b/git-clean.sh
new file mode 100755
index 0000000..b200868
--- /dev/null
+++ b/git-clean.sh
@@ -0,0 +1,80 @@
+#!/bin/sh
+#
+# Copyright (c) 2005-2006 Pavel Roskin
+#
+
+USAGE="[-d] [-n] [-q] [-x | -X]"
+LONG_USAGE='Clean untracked files from the working directory
+ -d remove directories as well
+ -n don'\''t remove anything, just show what would be done
+ -q be quiet, only report errors
+ -x remove ignored files as well
+ -X remove only ignored files as well'
+SUBDIRECTORY_OK=Yes
+. git-sh-setup
+
+ignored=
+ignoredonly=
+cleandir=
+quiet=
+rmf="rm -f"
+rmrf="rm -rf"
+rm_refuse="echo Not removing"
+echo1="echo"
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ -d)
+ cleandir=1
+ ;;
+ -n)
+ quiet=1
+ rmf="echo Would remove"
+ rmrf="echo Would remove"
+ rm_refuse="echo Would not remove"
+ echo1=":"
+ ;;
+ -q)
+ quiet=1
+ ;;
+ -x)
+ ignored=1
+ ;;
+ -X)
+ ignoredonly=1
+ ;;
+ *)
+ usage
+ esac
+ shift
+done
+
+case "$ignored,$ignoredonly" in
+ 1,1) usage;;
+esac
+
+if [ -z "$ignored" ]; then
+ excl="--exclude-per-directory=.gitignore"
+ if [ -f "$GIT_DIR/info/exclude" ]; then
+ excl_info="--exclude-from=$GIT_DIR/info/exclude"
+ fi
+ if [ "$ignoredonly" ]; then
+ excl="$excl --ignored"
+ fi
+fi
+
+git-ls-files --others --directory $excl ${excl_info:+"$excl_info"} |
+while read -r file; do
+ if [ -d "$file" -a ! -L "$file" ]; then
+ if [ -z "$cleandir" ]; then
+ $rm_refuse "$file"
+ continue
+ fi
+ $echo1 "Removing $file"
+ $rmrf "$file"
+ else
+ $echo1 "Removing $file"
+ $rmf "$file"
+ fi
+done
^ permalink raw reply related
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-05 6:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmj2b3w3.fsf@assigned-by-dhcp.cox.net>
On Mon, 2006-04-03 at 17:06 -0700, Junio C Hamano wrote:
> > diff --git a/git-clean.sh b/git-clean.sh
> >...
> > +for arg in "$@"; do
>
> for arg
> do
> ...
I checked other git shell scripts and copied the "while" construct from
one of them - if it's good for other commands, it's good for git-clean.
> > + if [ "$arg" = "-d" ]; then
>
> case "$arg" in -d)...
>
> > +excl1=
> > +excl2=
> > +if [ -z "$noexclude" ]; then
> > + excl1="--exclude-per-directory=.gitignore"
> > + if [ -f "$GIT_DIR/info/exclude" ]; then
> > + excl2="--exclude-from=$GIT_DIR/info/exclude"
> > + fi
> > +fi
> > +
> > +git-ls-files --others --directory "$excl1" "$excl2" |
> > +while read -r file; do
> > ...
>
> The $noexclude case passes two empty strings to git-ls-files,
> which may happen to be harmless with the current implementation,
> but does not feel quite right.
Good catch. This is needed since $GIT_DIR can contain spaces. I
believe ${excl2:+"$excl2"} would do the trick.
> Maybe better to read ls-files -z to be really pathname safe, I
> dunno.
I think "xargs -0" has its own problems (argument length limitations),
and the other solution is to use perl. While at that, I'd rather
rewrite the whole script in Perl, or maybe in even C.
I think this should eventually happen to all git scripts, but I have no
intention to do it right now unless you really want me to.
> > + $echo1 "Removing $file"
> > + [ "$cleandirhard" ] && chmod -R 700 "$file"
>
> I am not quite sure this chmod -R is a good idea. If we are
> trying really hard would we need to also make sure we can rmdir
> the "$file" by chmod'ing its parent directory? But once we
> start doing that where would we stop?
OK, I was undecided on that. I'm dropping this option.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] parse_date(): fix parsing 03/10/2006
From: Junio C Hamano @ 2006-04-05 6:00 UTC (permalink / raw)
To: git; +Cc: Andrew Morton, Brown, Len
The comment associated with the date parsing code for three
numbers separated with slashes or dashes implied we wanted to
interpret using this order:
yyyy-mm-dd
yyyy-dd-mm
mm-dd-yy
dd-mm-yy
However, the actual code had the last two wrong, and making it
prefer dd-mm-yy format over mm-dd-yy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Spotted, thanks to Len Brown and Andrew Morton.
date.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
f5cd7df6e8322a0b783668b31881ab95a5ce33bd
diff --git a/date.c b/date.c
index 416ea57..18a0710 100644
--- a/date.c
+++ b/date.c
@@ -257,10 +257,10 @@ static int match_multi_number(unsigned l
break;
}
/* mm/dd/yy ? */
- if (is_date(num3, num2, num, tm))
+ if (is_date(num3, num, num2, tm))
break;
/* dd/mm/yy ? */
- if (is_date(num3, num, num2, tm))
+ if (is_date(num3, num2, num, tm))
break;
return 0;
}
--
1.3.0.rc2.g110c
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-04-04 23:06 UTC (permalink / raw)
To: git
I've tagged the tip of "master" as 1.3.0-rc2. It has the
following changes since the last announcement.
- enhancement and a minor fix to built-in xdiff
(Davide Libenzi and Mark Wooding)
- contrib/git-svn updates (Eric Wong)
- documentation updates (J. Bruce Fields)
- build and other assorted fixes and cleanups (Jason Riedy,
Peter Eriksen, Rene Scharfe, Yasushi SHOJI, and Jim Radford)
- Solaris "clone" fix (Linus and Jason Riedy with initial
reproduction help from Peter Eriksen)
- revision traversal latency improvements with paths and
max-age limiting (Linus and me)
- http-fetch updates (Nick Hengeveld)
- updated gitk (Paul Mackerras)
* The 'next' branch, in addition, has these.
- fix cloning of upsteram whose HEAD does not point at master
(me); this is an attempt to fix a real bug, but I haven't had
a chance to test it sufficiently enough to convince myself it
is ready.
- pickaxe enhancements that looks for needles matching regexp
(Petr Baudis)
- combine-diff that uses built-in xdiff (me)
* The 'pu' branch, in addition, has these.
- assorted gitk updates from the list (Johannes Schindelin,
Keith Packard and Mark Wooding); I am waiting for some of
them to trickle back from Paul's canonical gitk tree.
- beginning of new pickaxe (me); I've got busy before getting this
one to do anything interesting. Currently it is just a bit
faster way to do 'rev-list | diff-tree --stdin path' for a
single path.
^ permalink raw reply
* [PATCH] On some platforms, certain headers need to be included before regex.h
From: Johannes Schindelin @ 2006-04-04 23:01 UTC (permalink / raw)
To: git, junkio
Happily, these are already included in cache.h, which is included anyway...
so: change the order of includes.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
diffcore-pickaxe.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
0dcea02390ab0a15e2dbb62b4b876046fe0b4e79
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index d89f314..cfcce31 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -1,11 +1,11 @@
/*
* Copyright (C) 2005 Junio C Hamano
*/
-#include <regex.h>
-
#include "cache.h"
#include "diff.h"
#include "diffcore.h"
+
+#include <regex.h>
static unsigned int contains(struct diff_filespec *one,
const char *needle, unsigned long len,
--
1.3.0.rc2.g7eaca-dirty
^ permalink raw reply related
* [ANNOUNCE] GIT 1.2.5
From: Junio C Hamano @ 2006-04-04 22:38 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.2.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.2.5.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.2.5-1.$arch.rpm (RPM)
This is primarily made to help Solaris folks who were bitten by
pack-objects (hence cloning from a repository hosted on Solaris)
broken by the progress-bar eye-candy. People who follow the
"master" branch, and people who run 1.2.4 on platforms with BSD
signal semantics (which automatically restarts interrupted
read() upon signal) need not worry.
With the "master" branch work nearing 1.3.0, hopefully this will
be the last 1.2.X release.
----------------------------------------------------------------
Changes since v1.2.4 are as follows:
Jason Riedy:
Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.
Junio C Hamano:
read-tree --aggressive: remove deleted entry from the working tree.
tar-tree: file/dirmode fix.
safe_fgets() - even more anal fgets()
Linus Torvalds:
Fix Solaris stdio signal handling stupidities
pack-objects: be incredibly anal about stdio semantics
^ permalink raw reply
* Re: [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 20:25 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List
In-Reply-To: <20060404184935.GG14967@reactrix.com>
[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]
Nick Hengeveld wrote:
> On Tue, Apr 04, 2006 at 07:11:40PM +0200, Radoslaw Szkodzinski wrote:
>
>> I have some problems cloning stgit repository (maybe something's broken there).
>>
>> astralstorm@zen /home/devel $ git clone
>> http://homepage.ntlworld.com/cmarinas/stgit.git stgit
>> error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
>> http://homepage.ntlworld.com/cmarinas/stgit.git/
>> Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
>> while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
>
> That host name resolves to multiple IP addresses, is it possible that
> one of the servers was out of sync? I tried cloning directly from each
> address and couldn't reproduce the problem.
>
Okay, I've nailed it. It's caused by Privoxy.
It seems that Privoxy sends its 404 page with 200 OK reply.
Clearly a broken response.
Does anyone have any better proxy supporting real SOCKS 4a/5 upstream proxy?
(for Tor)
Delegate doesn't count - it has broken HTTP code, 1.0 only and slow too.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Jakub Narebski @ 2006-04-04 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd596ua0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I was re-reading the hydra stuff and realized I've seen the "a
> cap that bundles independent tracks together" pattern somewhere
> else in the history of git.
>
> It is very similar to how "bind commit" would have worked.
[...]
> A "bind commit" proposal was made to support subprojects living
> in their own subdirectories. The picture to describe the commit
> ancestry chain would be almost the same as the above picture,
> except that it did not uncap and recap, but would have built its
> own ancestry chain.
One of versions of "hydra commit" proposals, in the mail which is yet to
appear on Gmane git mailing list archive, and Gmane NNTP interface to git
mailing list, was to define commit dependency (to which chain commit would
get) in the terms of affecting files in the same directory. Simple
generalization to subtree (directory and its subdirectories) gives "bind
commit for subprojects".
> It had two different kinds of commit relationships: parenthood
> and directory structure binding.
Great minds think alike :-P -- we (Sam and I) were talking on #git about
adding "depends-on" field to commit.
In the email to write I would propose that instead of adding "depends-on"
field (or "bind") one can at least in prototype stage make parallel
development, commiting simultaneously to the tree where history is history,
and to the tree where history is dependence, or bind. I hope I will make
myself clearer in upcoming message; see Sam post beginning this thread - we
want to make both pictures (on the left and on the right) simultaneously.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 19:54 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List
In-Reply-To: <20060404184935.GG14967@reactrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 1689 bytes --]
Nick Hengeveld wrote:
> On Tue, Apr 04, 2006 at 07:11:40PM +0200, Radoslaw Szkodzinski wrote:
>
>> I have some problems cloning stgit repository (maybe something's broken there).
>>
>> astralstorm@zen /home/devel $ git clone
>> http://homepage.ntlworld.com/cmarinas/stgit.git stgit
>> error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
>> http://homepage.ntlworld.com/cmarinas/stgit.git/
>> Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
>> while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
>
> That host name resolves to multiple IP addresses, is it possible that
> one of the servers was out of sync? I tried cloning directly from each
> address and couldn't reproduce the problem.
>
Anyhow, git-http-fetch shouldn't segfault.
It's not my server, I don't know the exact configuration.
Also the repository is not mine.
It is reproducible here 100% of the time.
Here, it resolves like that:
astralstorm@zen $ resolveip homepage.ntlworld.com
IP address of homepage.ntlworld.com is 62.253.162.12
IP address of homepage.ntlworld.com is 62.253.162.178
IP address of homepage.ntlworld.com is 62.253.162.10
IP address of homepage.ntlworld.com is 62.253.162.11
I have an strace for you, bzipped and attached.
It is an output of the command:
strace -e 'trace=!poll,gettimeofday,select' -o fetch-strace.log git-http-fetch
-v -a -w heads/master heads/master http://homepage.ntlworld.com/cmarinas/stgit.git/
I hope it is enough to hunt the bug. If you need more info, please just ask.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #1.2: fetch-strace.log.bz2 --]
[-- Type: application/octet-stream, Size: 15607 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Junio C Hamano @ 2006-04-04 19:00 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4431B60E.3030008@vilain.net>
I was re-reading the hydra stuff and realized I've seen the "a
cap that bundles independent tracks together" pattern somewhere
else in the history of git.
It is very similar to how "bind commit" would have worked.
With hydra, you keep independently mergeable tracks and bundle
their tips together:
---o--+
---o--+--*
---o--+
and advancement of each individual track is bundled together by
uncapping and recapping:
---o--o--+
---o--o--+--*
---o-----+
So a hydra cap would record:
- the result "tree" of the (trivial) merge of the bundled tips;
- the commit object name of the tips.
A "bind commit" proposal was made to support subprojects living
in their own subdirectories. The picture to describe the commit
ancestry chain would be almost the same as the above picture,
except that it did not uncap and recap, but would have built its
own ancestry chain.
It had two different kinds of commit relationships: parenthood
and directory structure binding. The component subprojects
lived in their own subdirectories (so if you are maintaining an
embedded Linux along with matching toolchain, you would have linux/
subdirectory that has the kernel hierarchy, gcc/, libc/, ...),
and commit objects had "bind commit-sha1 subdirectory-name"
lines to express how the components are bundled together. A
commit object would have looked like this:
tree fc9957b0052df6a8248420395bc9febd66194252
parent 052df6a8248420395bc9febd66194252fc9957b0
bind f6a8248420395bc9febd66194252fc9957b0052d linux/
bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/
author A U Thor <author@example.com> 1144111304 -0700
...
The "parent" line is the commit ancestry as usual, and each
"bind" line names a commit object of component project and where
in the directory hierarchy the tree for that commit object would
be checked out. The "tree" line records the result of grafting
the subprojects together. So, for example, ls-tree -d fc9957
linux in the above example would have shown the tree object
f6a824^{tree}.
The structure forbid you from binding two separate projects at
the same directory in order to enforce clean separation of
subprojects, but if you allow multiple commits to be bound at
the root level, that could be used as a hydra cap.
I've done changes to support this at the core level; I think I
still have the code around somewhere (and the net never forgets
;-), so if you are interested you might want to take a look.
The trickest part was to tell rev-list --objects to work
sensibly so that an ancestry chain that contains this kind of
commits can be fetched and pushed. The code unfortunately was
done before recent rev-list renovation so merging it to the
current codebase needs some understanding of how rev-list is
supposed to work, though.
^ permalink raw reply
* Re: [RFH] Solaris cloning woes...
From: Jason Riedy @ 2006-04-04 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Peter Eriksen
In-Reply-To: <7vu099916v.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- Once this is confirmed to fix the problem on Solaris boxes, I'd
- like to include and do an 1.2.5, just in case OpenSolaris folks
- would want to play with it, and also put them in the "master"
- branch.
I haven't run into the problem since, but I almost never saw
it in the first place. Have you been able to trigger it
reliably? Maybe I'm "lucky" that my Sun's so slow...
Jason
^ permalink raw reply
* Re: [BUG] git-http-fetch segfault
From: Nick Hengeveld @ 2006-04-04 18:49 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: Git Mailing List
In-Reply-To: <4432A8CC.5020200@o2.pl>
On Tue, Apr 04, 2006 at 07:11:40PM +0200, Radoslaw Szkodzinski wrote:
> I have some problems cloning stgit repository (maybe something's broken there).
>
> astralstorm@zen /home/devel $ git clone
> http://homepage.ntlworld.com/cmarinas/stgit.git stgit
> error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
> http://homepage.ntlworld.com/cmarinas/stgit.git/
> Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
> while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
That host name resolves to multiple IP addresses, is it possible that
one of the servers was out of sync? I tried cloning directly from each
address and couldn't reproduce the problem.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Solaris needs strings.h when using index().
From: H. Peter Anvin @ 2006-04-04 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Eriksen, git
In-Reply-To: <7vwte56w7n.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Peter Eriksen" <s022018@student.dtu.dk> writes:
>
>> From: Peter Eriksen <s022018@student.dtu.dk>
>> Date: Tue Apr 4 14:33:14 2006 +0200
>> Subject: [PATCH] Solaris needs strings.h when using index().
>>
>> Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
>
> I think somebody else noticed this the other day but I'm
> undecided if it is easier to replace use of index with strchr,
> since we include <string.h> and use strchr() everywhere.
>
strchr() is definitely more portable. The further away you get from BSD
heritage, the less likely it is that you're going to see bzero, index,
et al whereas anything even remotely modern has memset, strchr, etc.
-hpa
^ permalink raw reply
* Re: Solaris cloning woes partly diagnosed
From: H. Peter Anvin @ 2006-04-04 18:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0604021118210.3050@g5.osdl.org>
Linus Torvalds wrote:
>
> One thing to do might be to make the itimer use a much higher frequency,
> to trigger the problem more easily.
>
> We do, for example, expect that regular file writing not do that. At least
> "write_sha1_from_fd()" will just do a "write()" without testing the error
> return, which is bad (it would silently create a truncated object if the
> /tmp filesystem filled up). If somebody has their filesystem over NFS
> mounted interruptible, partial writes could also happen.
>
There seems to be a whole bunch of places where we use naked write()s
where xwrite or fwrite would be a lot more appropriate. The ssh-* files
seem to be particularly offensive in that way.
There are also a number of places which call xwrite with the apparent
belief that returning short is an error (e.g. blame.c). This as far as
I know the more common definition of xwrite(), but is *not* the one used
in git -- the one in git only guarantees that at least one character is
written.
-hpa
^ permalink raw reply
* Re: [PATCH] Solaris needs strings.h when using index().
From: Junio C Hamano @ 2006-04-04 18:18 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060404123603.GA14071@bohr.gbar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> From: Peter Eriksen <s022018@student.dtu.dk>
> Date: Tue Apr 4 14:33:14 2006 +0200
> Subject: [PATCH] Solaris needs strings.h when using index().
>
> Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
I think somebody else noticed this the other day but I'm
undecided if it is easier to replace use of index with strchr,
since we include <string.h> and use strchr() everywhere.
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 18:01 UTC (permalink / raw)
To: Daniel Drake; +Cc: Junio C Hamano, git
In-Reply-To: <4431694C.4000007@gentoo.org>
On Mon, Apr 03, 2006 at 07:28:28PM +0100, Daniel Drake wrote:
> Ah, should have known. I am behind a (lame) transparent proxy on port 80.
>
> I opened that file in my web browser and it showed the old heads. After
> a force-refresh (ctrl+F5, which sends some additionally http headers to
> refresh the page from the real server), the old heads disappeared, and
> git now clones successfully.
>
> git-http-fetch should probably send those extra headers too. I'll try to
> find some time to look at this next week.
git-http-fetch uses the "Pragma: no-cache" header when requesting
objects that shouldn't be cached. Is this the additional header you're
referring to?
This patch adds the header to git-ls-remote for the info/refs request.
git-ls-remote: send no-cache header when fetching info/refs
Proxies should not cache this file as it can cause a client to end up with
a stale version, as reported here:
http://marc.theaimsgroup.com/?l=git&m=114407944125389
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
git-ls-remote.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
da9b6fa01f1a8bd6ab5f6d4346584f3f032584aa
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index 2c9a588..b6882a9 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -53,7 +53,7 @@ http://* | https://* )
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
- curl -nsf $curl_extra_args "$peek_repo/info/refs" ||
+ curl -nsf $curl_extra_args --header "Pragma: no-cache" "$peek_repo/info/refs" ||
echo "failed slurping"
;;
--
1.3.0.rc1.g9aef-dirty
^ permalink raw reply related
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-04 17:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060404152737.GN27689@pasky.or.cz>
On Tue, Apr 04, 2006 at 05:27:37PM +0200, Petr Baudis wrote:
> Because people do not know they have to set up their post-update hook.
> When they are already going at lengths to find out how to set up DAV for
> git fetch, they would discover the post-update hook way as well.
There are other reasons that a client can end up with a stale copy of
the server info files - in this case the problem was an intermediate
proxy out of the control of the repo admin.
While we should be able to fix that particular problem, it seems safer
to go straight to the source if possible.
> So, it really seems rather redundant to me.
If I've already enabled DAV for pushing to a repo, I'd find it nice to
be able to use it for fetches as well.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [BUG] git-http-fetch segfault
From: Radoslaw Szkodzinski @ 2006-04-04 17:11 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 3379 bytes --]
I have some problems cloning stgit repository (maybe something's broken there).
The repository seems to be using symlink HEAD.
Possibly the problem is because of a non-existent tag commit.
Yes, it has that broken HTTP error message bug.
Git version:
astralstorm@zen /home/devel/git $ git log -n 1 | head -n 1
commit fc9957b0052df6a8248420395bc9febd66194252
Session log (slightly linewrapped):
astralstorm@zen /home/devel $ git clone
http://homepage.ntlworld.com/cmarinas/stgit.git stgit
got 52f3900c0c7dec8581fa907495a09c900a3d39d7
walk 52f3900c0c7dec8581fa907495a09c900a3d39d7
got c82395b46d238948882045e76e7770319a4f40e8
got aa78d4ed34d262b6f811e7e47415c8c4ac6d80a2
walk c82395b46d238948882045e76e7770319a4f40e8
got 098c1d3e9fe5c39b859ccff6c7d36d2c193d1b62
got 4ebca0e1cabe90ecdcd29aab6fa16521d4999fb5
got 8d2bebd9d1824f1b7af5cfe6fbd11f9cbfde6d74
got 184ded8e08cb92a14b79c79f9919469ba352ab70
got d60c31a97a544b53039088d14fe9114583c0efc3
got e5affe07bf8b39e2aa0309299dbc9532e05940b5
got c2514fd418472dc173a5fef09c82ccf666c9555f
got 3c900ce9dae0959a9e4479b55b8a71d1b92d170d
got 7888f29f97452f8db39f4a9e857b7f1d2c913765
got 4359033a665b7943f2a7579e8329a715fd2fdc57
got def843c5d5fd4dee9a54504512b4308cb3a84018
got 0c3ad3951bb8cf368c70b13240665495e19a98a9
got 32977d8fae38a542b15dd9c5e39d64076a35227b
got 8847a11b3bbf5406f37a360e5466f0e392c56383
got 07704b8331d6d78a132c731874f66749dfa0f85c
got 5b8d95f20b8989fde6b0731c55b3f985ed01630a
got 6a8557477abde3f1368304e6fb8d890e2982267e
got de7bd13bae9eec619ae4baf46e65475602d52979
got 5899c38225df2244c7b09015f5b754d9735415d5
got ebd09f908d165c7aa3a135ddc8bbd5a05787df93
walk 8847a11b3bbf5406f37a360e5466f0e392c56383
got 6480a2a7f279002c3daf5a56ece16636cd5df26f
got 568bc169d53ee40ef5dc7481e7cab8078141fa9e
Getting alternates list for http://homepage.ntlworld.com/cmarinas/stgit.git/
got 4b03e3a6440883cf8ef6092426b3d932b8b0c73a
got ee90cfb41de9e3a589fc688ba1350e9c8b846c20
got c394572a81d9b3322a7a7cdccec0c1846d445dcc
got 66e9f41044631264c2740f61ddafbc4bd01ec71a
got c603ff88fcd21f1e4b806413d195c90f29ea547f
got a0569457816c345e8c7fa92135fd664dd67ea97c
got 5749b3bd8476df9e2808a3723e23d7acd4e4c71d
got f4d749004ac695720ab883c338fdc3df5da394bb
got e7f3481a23600c969a3cdf9bf793e8239546c1d1
got 1317788c088c3f621f83ceae657e0d1f6f34af54
got 7881993b68ead8678545516fa8e04f8919569b8e
got 44cd19e162f9ff976df475bccecd63a42e04a244
Getting pack list for http://homepage.ntlworld.com/cmarinas/stgit.git/
got 694ea0c23cc88422d923104b04832df48865dae6
got 938ce9bb5812cac4d0902ae6f87a276d51a58cd9
got 9534f1c94a19e5521bbb7a5664d587400eb55905
got fc9c5a73a29673f06b683a85134531ad6d9520ea
got f80bef4918840e4290f03f291d8b4dbb98b12d80
error: Unable to find adad46f365219e9bcc1a212826ca65eaac09729c under
http://homepage.ntlworld.com/cmarinas/stgit.git/
Cannot obtain needed blob adad46f365219e9bcc1a212826ca65eaac09729c
while processing commit 8847a11b3bbf5406f37a360e5466f0e392c56383.
Waiting for
http://homepage.ntlworld.com/cmarinas/stgit.git/objects/d5/68cd60c5759cfd84d4148f3c3d5bf9f5b85d41
/usr/bin/git-clone: line 29: 13000 Naruszenie ochrony pamięci git-http-fetch
-v -a -w "$tname" "$name" "$1/"
(Naruszenie ochrony pamięci = Segmentation fault)
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* [PATCH] Set HTTP user agent to git/GIT_VERSION
From: Nick Hengeveld @ 2006-04-04 17:11 UTC (permalink / raw)
To: git
Useful for diagnostics/troubleshooting to know which client versions are
hitting your server.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
Makefile | 3 +++
http.c | 2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
468d4d4ac3cbdb0757a7cc1c207ca379ce3a5d56
diff --git a/Makefile b/Makefile
index 19ce42c..c7d5ecf 100644
--- a/Makefile
+++ b/Makefile
@@ -510,6 +510,9 @@ git$X git.spec \
exec_cmd.o: exec_cmd.c
$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+http.o: http.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_USER_AGENT='"git/$(GIT_VERSION)"' $<
+
ifdef NO_EXPAT
http-fetch.o: http-fetch.c
$(CC) -o $*.o -c $(ALL_CFLAGS) -DNO_EXPAT $<
diff --git a/http.c b/http.c
index 9604e33..0cb42a8 100644
--- a/http.c
+++ b/http.c
@@ -195,6 +195,8 @@ #endif
if (getenv("GIT_CURL_VERBOSE"))
curl_easy_setopt(result, CURLOPT_VERBOSE, 1);
+ curl_easy_setopt(result, CURLOPT_USERAGENT, GIT_USER_AGENT);
+
return result;
}
--
1.3.0.rc1.g9aef-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-04 15:52 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, git
In-Reply-To: <20060404105818.GA17326@mars.ravnborg.org>
On Tue, 2006-04-04 at 12:58 +0200, Sam Ravnborg wrote:
> On Mon, Apr 03, 2006 at 05:06:36PM -0700, Junio C Hamano wrote:
> >
> > I am not opposed to the command in the sense that I do not want
> > to forbid people from doing what they want to do, but on the
> > other hand I do not see why people (apparently many people) want
> > to have something like this. Are their "make clean" broken?
Normally it is not, but if it is, they want to know it. If git-clean
remove something after "make clean" then maybe the later is incomplete.
To put it another way, if I make changes and share them with others, I
want to make sure that my changes will work for them. If the mechanism
for sharing my changes is make-based, I rely on make to check them. In
projects using Automake it's called "make distcheck". If I'm sharing my
changes as a git patch, I want a git-based verification that the project
still builds from scratch.
Also, the files cleaned by "make clean" are normally build products.
Things that you _really_ don't want to be in the source tree at the
release time are other files, such as backup files with changes that you
decided to back out, sources that you may not share, firmware that cost
your company $50000 and so on. "make clean" won't remove them.
> No reason to waste time on make clean.
> git ls-files -o | xargs rm
> Does the same job nicely.
This would remove ignored files. It's not always what I want.
> Other typical usecases for me:
> Remove temporaries that I created while trying out stuff.
> Often I have a bunch of files named 'x', 'xx', 'fisk' etc.
> around for no use. An easy way to remove these without breaking
> my 'allmodconfig' build is nice. It anyway > 1 hour to build and
> I like to get rid of the untracked stuff in an easy way.
>
> So use cases goes like this:
> - Remove everything not tracked by git (including .gitignore files)
> - Remove everything except tracked by git or ignored
> - Remove ignored files (replacement of make clean) (seldom)
I'll think about the later.
> Above should work both from top-level dir and in subdirectories.
>
> That is my minimal expectations to git clean.
> What Pavel came up with cover everything except the make clean
> replacement part.
Exactly. The "make clean" replacement is actually the one I didn't
implement.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] read-cache.c: Slight parameter name improvement.
From: Peter Eriksen @ 2006-04-04 15:42 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Tue Apr 4 17:40:02 2006 +0200
Subject: [PATCH] read-cache.c: Slight parameter name improvement.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
read-cache.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
dde622db1412a556b216eceff4a9a677b41568c3
diff --git a/read-cache.c b/read-cache.c
index f97f92d..2e8fdc5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -257,7 +257,7 @@ int cache_name_compare(const char *name1
return 0;
}
-int cache_name_pos(const char *name, int namelen)
+int cache_name_pos(const char *name, int flags)
{
int first, last;
@@ -266,7 +266,7 @@ int cache_name_pos(const char *name, int
while (last > first) {
int next = (last + first) >> 1;
struct cache_entry *ce = active_cache[next];
- int cmp = cache_name_compare(name, namelen, ce->name, ntohs(ce->ce_flags));
+ int cmp = cache_name_compare(name, flags, ce->name, ntohs(ce->ce_flags));
if (!cmp)
return next;
if (cmp < 0) {
--
1.3.0.rc1.gfc99-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-04 15:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Martin Waitz, git
In-Reply-To: <81b0412b0604040217s3b8863d3w1b79400c42ca2b90@mail.gmail.com>
On Tue, 2006-04-04 at 11:17 +0200, Alex Riesen wrote:
> On 4/4/06, Martin Waitz <tali@admingilde.org> wrote:
> > What is the use case of cleaning up all untracked files without also
> > cleaning ignored files?
>
> Thinks of git's .gitignore: it has config.mak in it. Are you sure you want
> "clean" your build customizations?
In may case, I normally want to remove copies of the sources. For
example, I take foo.c, make a clean copy of it, then I change and test
it. If if doesn't work and I want to try another approach, I copy it to
foo.c-bad or foo.c-approach1. I also make diffs between files to see
what exactly I changed. I may also create files for output, valgrind
logs and so on.
At some point, I'm satisfied with foo.c, so I commit it. Then I want to
remove copies, diffs and other stuff. Yet I don't want to rebuild
everything.
It's very rare that I add a new file, and I always remember to add it to
the version control. But I'll consider adding an option to only remove
ignored files.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Petr Baudis @ 2006-04-04 15:27 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20060404121056.GB14967@reactrix.com>
Dear diary, on Tue, Apr 04, 2006 at 02:10:57PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> On Tue, Apr 04, 2006 at 12:00:35PM +0200, Petr Baudis wrote:
>
> > Well, what is the actual advantage of DAV compared to
> > git-update-server-info? Why would I prefer enabling DAV?
>
> In theory, things should work the same either way. It seems that in
> practice though, the server info files continue to surface as a source
> of fetch problems.
Because people do not know they have to set up their post-update hook.
When they are already going at lengths to find out how to set up DAV for
git fetch, they would discover the post-update hook way as well.
So, it really seems rather redundant to me.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [PATCH] Solaris needs strings.h when using index().
From: Peter Eriksen @ 2006-04-04 12:36 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Tue Apr 4 14:33:14 2006 +0200
Subject: [PATCH] Solaris needs strings.h when using index().
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
832067e6e16ae6c1ac3bd043ddeb56daa993e682
diff --git a/blame.c b/blame.c
index 396defc..1a08434 100644
--- a/blame.c
+++ b/blame.c
@@ -6,6 +6,7 @@ #include <assert.h>
#include <time.h>
#include <sys/time.h>
#include <math.h>
+#include <strings.h>
#include "cache.h"
#include "refs.h"
--
1.3.0.rc1.gfc99-dirty
^ 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