* Re: Kernel nightly snapshots..
From: Linus Torvalds @ 2005-05-05 15:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <1115305813.16187.143.camel@hades.cambridge.redhat.com>
On Thu, 5 May 2005, David Woodhouse wrote:
>
> OK, I've changed my 'origin' to an rsync URL referring to the same
> place, to make sure I get tags correctly in future. 2.6.12-rc3-git1 is
> in the process of being built; if the attached script works and
> continues working when invoked from cron, we might even see nightly
> snapshots again as requested...
RELNAME=`cg-tag-ls | grep -v 'git' | tail -n1 | cut -f1 | sed s/^v//`
this seems to assume that cg-tag-ls outputs things in the right order,
which I'm not at all sure it does.
It looks like cg-tag-ls just does
cd .git/refs/tags
for tag in *; do
...
which means that the ordering will depend on the shell ordering or
globbing.
Bash does globbing alphabetically sorted (and documents that), and it's
quite possible that all other shells do too. Even so, that doesn't
actually mean that it would be sorted by release, since v2.6.2 will sort
_after_ v2.6.12.
So this _should_ work for a while, but will eventually (before a -rc10
happens or we get to v2.6.100 ;^) need something better. That something
better probably being to ignore any tags that don't point to commits, and
then sorting by the date of the commit object.
Linus
^ permalink raw reply
* [PATCH] cogito: allow filenames with spaces in cg-commit
From: Jan Veldeman @ 2005-05-05 15:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Fixes the filename handling in cg-commit.
To allow spaces in the filenames, the filenames are kept in an array.
(The trick with zero bytes is harder to do when storing the filenames in
a variable).
"${commitfiles[@]}" is used where the filenames are needed as separate
arguments, this expands into "file 1" "file 2" ...
"${commitfiles[*]}" is used when a check is made for the existence of the
parameter, this expands into "file1 file 2 ..."
The eval changedfiles=($(... | sed ...)) is used to place the result of
git-diff-cache into the array. (I couldn't find a cleaner solution to do
this)
Signed-off-by: Jan Veldeman <Jan.Veldeman@advalvas.be>
Index: cogito/cg-commit
===================================================================
--- cogito.orig/cg-commit 2005-05-05 17:13:44.000000000 +0200
+++ cogito/cg-commit 2005-05-05 17:34:37.000000000 +0200
@@ -22,8 +22,8 @@
fi
if [ "$1" ]; then
- commitfiles="$@"
- customfiles=$commitfiles
+ commitfiles=("$@")
+ customfiles="${commitfiles[*]}"
[ "$ignorecache" ] && die "-C and listing files to commit does not make sense"
[ -s .git/merging ] && die "cannot commit individual files when merging"
@@ -37,8 +37,9 @@
# be committed along automagically as well.
if [ ! "$ignorecache" ]; then
- changedfiles=$(git-diff-cache $(tree-id) | cut -f 4-)
- commitfiles="$addedfiles $remfiles $changedfiles"
+ eval changedfiles=($(git-diff-cache $(tree-id) | cut -f 4- | \
+ sed -e 's/^/"/' -e 's/$/"/'))
+ commitfiles=($addedfiles $remfiles "${changedfiles[@]}")
fi
merging=
@@ -46,11 +47,11 @@
fi
if [ ! "$ignorecache" ]; then
- if [ ! "$commitfiles" ]; then
+ if [ ! "${commitfiles[*]}" ]; then
echo 'Nothing to commit.' >&2
exit 2
fi
- for file in $commitfiles; do
+ for file in "${commitfiles[@]}"; do
# Prepend a letter describing whether it's addition,
# removal or update. Or call git status on those files.
echo $file;
@@ -76,13 +77,13 @@
if [ ! "$ignorecache" ]; then
if [ "$customfiles" ]; then
- echo $commitfiles | xargs git-update-cache --add --remove \
+ git-update-cache --add --remove "${commitfiles[@]}" \
|| die "update-cache failed"
export GIT_INDEX_FILE=$(mktemp -t gitci.XXXXXX)
git-read-tree $(tree-id)
fi
# TODO: Do the proper separation of adds, removes, and changes.
- echo $commitfiles | xargs git-update-cache --add --remove \
+ git-update-cache --add --remove "${commitfiles[@]}" \
|| die "update-cache failed"
fi
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: David Woodhouse @ 2005-05-05 15:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <1115305813.16187.143.camel@hades.cambridge.redhat.com>
On Thu, 2005-05-05 at 16:10 +0100, David Woodhouse wrote:
> 2.6.12-rc3-git1 is in the process of being built; if the attached
> script works and continues working when invoked from cron, we might
> even see nightly snapshots again as requested...
Eep. That'll be a whole lot more useful if I do
cg-diff -r $RELTREE:$CURTREE
instead of
cg-diff -r $CURTREE:$RELTREE
... but it should be OK now. This is the md5sum of the correct one:
21a0ee13c539e8b016682c1542bb9167 patch-2.6.12-rc3-git1.gz
--
dwmw2
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: David Woodhouse @ 2005-05-05 15:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505050742180.2328@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
On Thu, 2005-05-05 at 07:44 -0700, Linus Torvalds wrote:
> If you fetch the _whole_ object database (with rsync), you should get
> them.
OK, I've changed my 'origin' to an rsync URL referring to the same
place, to make sure I get tags correctly in future. 2.6.12-rc3-git1 is
in the process of being built; if the attached script works and
continues working when invoked from cron, we might even see nightly
snapshots again as requested...
--
dwmw2
[-- Attachment #2: git-snapshot.sh --]
[-- Type: application/x-shellscript, Size: 1724 bytes --]
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: Linus Torvalds @ 2005-05-05 14:44 UTC (permalink / raw)
To: David Woodhouse; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <1115303933.16187.135.camel@hades.cambridge.redhat.com>
On Thu, 5 May 2005, David Woodhouse wrote:
>
> hera /home/dwmw2/git/snapshot-2.6 $ cg-init /pub/scm/linux/kernel/git/torvalds/linux-2.6.git &> ../asd
> hera /home/dwmw2/git/snapshot-2.6 $ cg-tag-ls
> v2.6.11 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
> v2.6.11-tree 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
> v2.6.12-rc2 9e734775f7c22d2f89943ad6c745571f1930105f
> v2.6.12-rc3 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
> hera /home/dwmw2/git/snapshot-2.6 $ git-cat-file -t 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
> .git/objects/03/97236d43e48e821cce5bbe6a80a1a56bb7cc3a: No such file or directory
Looks like cg uses git-http-pull instead of rsync, and doesn't download
anything but the required objects.
In which case you probably don't have the v2.6.11 tree either, in fact,
since it's not required to get a working copy of HEAD.
If you fetch the _whole_ object database (with rsync), you should get
them.
Linus
^ permalink raw reply
* Re: dangling trees
From: Linus Torvalds @ 2005-05-05 14:41 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050505141224.A8323@flint.arm.linux.org.uk>
On Thu, 5 May 2005, Russell King wrote:
>
> In todays 2.6 git repo, I see the following:
>
> $ fsck-cache
> expect dangling commits - potential heads - due to lack of head information
> dangling commit 897f5ab2cd733a77a2279268262919caa8154b9d
> dangling tree c39ae07f393806ccf406ef966e9a15afc43cc36a
>
> The dangling commit is the current head - that's fine. However,
> what's this dangling tree?
That's the 2.6.11 tree, which I added to have a previous real release to
diff against.
> It appears to have come in from Linus' tree on kernel.org this morning.
Yes. You can make (my) fsck shut up with something like
refs=.git/refs/*/*
git-fsck-cache $refs
but that assumes that cogito has been updated to the newer fsck that
understands to follow tags (not just parse them, but also add the "tag
refers to object xxx" info to its internal tree of trust). I don't think
that has happened yet.
In the meantime, just ignore it.
Linus
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: David Woodhouse @ 2005-05-05 14:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <42797F9F.9030002@zytor.com>
On Wed, 2005-05-04 at 19:06 -0700, H. Peter Anvin wrote:
> It used to be Jeff Garzik, but David Woodhouse volunteered to take
> this over a few days ago, so yesterday I chowned those directories to
> him.
I still have a problem with tags....
hera /home/dwmw2/git/snapshot-2.6 $ cg-init /pub/scm/linux/kernel/git/torvalds/linux-2.6.git &> ../asd
hera /home/dwmw2/git/snapshot-2.6 $ cg-tag-ls
v2.6.11 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
v2.6.11-tree 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
v2.6.12-rc2 9e734775f7c22d2f89943ad6c745571f1930105f
v2.6.12-rc3 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
hera /home/dwmw2/git/snapshot-2.6 $ git-cat-file -t 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
.git/objects/03/97236d43e48e821cce5bbe6a80a1a56bb7cc3a: No such file or directory
fatal: git-cat-file 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a: bad file
--
dwmw2
^ permalink raw reply
* Re: dangling trees
From: bert hubert @ 2005-05-05 13:22 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050505141224.A8323@flint.arm.linux.org.uk>
On Thu, May 05, 2005 at 02:12:25PM +0100, Russell King wrote:
> $ fsck-cache
> expect dangling commits - potential heads - due to lack of head information
See the message on 'nightly kernel builds' - you are seeing 2.6.11 probably.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* Re: dangling trees
From: Lennert Buytenhek @ 2005-05-05 13:22 UTC (permalink / raw)
To: Russell King; +Cc: git, Linus Torvalds
In-Reply-To: <20050505141710.B8323@flint.arm.linux.org.uk>
On Thu, May 05, 2005 at 02:17:10PM +0100, Russell King wrote:
> > dangling tree c39ae07f393806ccf406ef966e9a15afc43cc36a
> >
> > The dangling commit is the current head - that's fine. However,
> > what's this dangling tree?
> >
> > It appears to have come in from Linus' tree on kernel.org this morning.
> >
> > (above from cogito 0.8)
>
> As an additional note, the ID does not correspond with any tags or
> heads:
>
> .git/refs/heads/master:897f5ab2cd733a77a2279268262919caa8154b9d
> .git/refs/heads/origin:897f5ab2cd733a77a2279268262919caa8154b9d
> .git/refs/tags/v2.6.11:5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
Those are tag objects.
$ git-cat-file tag 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c | head -3
object c39ae07f393806ccf406ef966e9a15afc43cc36a
type tree
tag v2.6.11-tree
--L
^ permalink raw reply
* Re: dangling trees
From: Russell King @ 2005-05-05 13:17 UTC (permalink / raw)
To: git, Linus Torvalds
In-Reply-To: <20050505141224.A8323@flint.arm.linux.org.uk>
On Thu, May 05, 2005 at 02:12:25PM +0100, Russell King wrote:
> In todays 2.6 git repo, I see the following:
>
> $ fsck-cache
> expect dangling commits - potential heads - due to lack of head information
> dangling commit 897f5ab2cd733a77a2279268262919caa8154b9d
> dangling tree c39ae07f393806ccf406ef966e9a15afc43cc36a
>
> The dangling commit is the current head - that's fine. However,
> what's this dangling tree?
>
> It appears to have come in from Linus' tree on kernel.org this morning.
>
> (above from cogito 0.8)
As an additional note, the ID does not correspond with any tags or
heads:
.git/refs/heads/master:897f5ab2cd733a77a2279268262919caa8154b9d
.git/refs/heads/origin:897f5ab2cd733a77a2279268262919caa8154b9d
.git/refs/tags/v2.6.11:5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
.git/refs/tags/v2.6.11-tree:5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
.git/refs/tags/v2.6.12-rc2:9e734775f7c22d2f89943ad6c745571f1930105f
.git/refs/tags/v2.6.12-rc3:0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
--
Russell King
^ permalink raw reply
* dangling trees
From: Russell King @ 2005-05-05 13:12 UTC (permalink / raw)
To: git, Linus Torvalds
In todays 2.6 git repo, I see the following:
$ fsck-cache
expect dangling commits - potential heads - due to lack of head information
dangling commit 897f5ab2cd733a77a2279268262919caa8154b9d
dangling tree c39ae07f393806ccf406ef966e9a15afc43cc36a
The dangling commit is the current head - that's fine. However,
what's this dangling tree?
It appears to have come in from Linus' tree on kernel.org this morning.
(above from cogito 0.8)
--
Russell King
^ permalink raw reply
* Re: read-only git repositories
From: Sean @ 2005-05-05 12:39 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0505050231300.15451@qynat.qvtvafvgr.pbz>
On Thu, May 5, 2005 5:51 am, David Lang said:
> there are probably other uses and it seems like a fairly small
> modification to add a hook to use if the object isn't found initially
> that I thought I'd mention it to the group.
>
David,
Great idea! This seems like an option that naturally falls out of the git
design. You're right that there are lots of uses for it too; another
would be to keep all local changes in an isolated object store for backup
etc.
Sean
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Kay Sievers @ 2005-05-05 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vy8aul8rs.fsf@assigned-by-dhcp.cox.net>
Allow to store and track symlink in the repository. A symlink is stored
the same way as a regular file, only with the appropriate mode bits set.
The symlink target is therefore stored in a blob object.
This will hopefully make our udev repository fully functional. :)
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
On Wed, May 04, 2005 at 07:13:43PM -0700, Junio C Hamano wrote:
> >>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
> I did not know if you are going to take CE_ type suggestion so
> I left it as it was.
>
> There are more. "grep 'S_I[SF]' *.[ch] */*.[ch]" would tell us
> most if not all. We probably would want to have CE_ISLNK() and
> friends, parallel to S_ISLNK() and friends if we go this route.
Hmm, how about this?
Thanks,
Kay
--- a/cache.h
+++ b/cache.h
@@ -87,7 +87,14 @@ struct cache_entry {
#define ce_stage(ce) ((CE_STAGEMASK & ntohs((ce)->ce_flags)) >> CE_STAGESHIFT)
#define ce_permissions(mode) (((mode) & 0100) ? 0755 : 0644)
-#define create_ce_mode(mode) htonl(S_IFREG | ce_permissions(mode))
+static inline unsigned int create_ce_mode(unsigned int mode)
+{
+ if (S_ISREG(mode))
+ return htonl(S_IFREG | ce_permissions(mode));
+ if (S_ISLNK(mode))
+ return htonl(S_IFLNK);
+ return htonl(mode);
+}
#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8) & ~7)
@@ -124,6 +131,7 @@ extern int index_fd(unsigned char *sha1,
#define MODE_CHANGED 0x0008
#define INODE_CHANGED 0x0010
#define DATA_CHANGED 0x0020
+#define TYPE_CHANGED 0x0040
/* Return a statically allocated filename matching the sha1 signature */
extern char *sha1_file_name(const unsigned char *sha1);
--- a/check-files.c
+++ b/check-files.c
@@ -28,8 +28,8 @@ static void check_file(const char *path)
die("preparing to update existing file '%s' not in cache", path);
ce = active_cache[pos];
- if (fstat(fd, &st) < 0)
- die("fstat(%s): %s", path, strerror(errno));
+ if (lstat(path, &st) < 0)
+ die("lstat(%s): %s", path, strerror(errno));
changed = cache_match_stat(ce, &st);
if (changed)
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -72,23 +72,41 @@ static int write_entry(struct cache_entr
unsigned long size;
long wrote;
char type[20];
+ char target[1024];
new = read_sha1_file(ce->sha1, type, &size);
if (!new || strcmp(type, "blob")) {
return error("checkout-cache: unable to read sha1 file of %s (%s)",
path, sha1_to_hex(ce->sha1));
}
- fd = create_file(path, ntohl(ce->ce_mode));
- if (fd < 0) {
+ switch (ntohl(ce->ce_mode) & S_IFMT) {
+ case S_IFREG:
+ fd = create_file(path, ntohl(ce->ce_mode));
+ if (fd < 0) {
+ free(new);
+ return error("checkout-cache: unable to create file %s (%s)",
+ path, strerror(errno));
+ }
+ wrote = write(fd, new, size);
+ close(fd);
+ free(new);
+ if (wrote != size)
+ return error("checkout-cache: unable to write file %s", path);
+ break;
+ case S_IFLNK:
+ memcpy(target, new, size);
+ target[size] = '\0';
+ if (symlink(target, path)) {
+ free(new);
+ return error("checkout-cache: unable to create symlink %s (%s)",
+ path, strerror(errno));
+ }
+ free(new);
+ break;
+ default:
free(new);
- return error("checkout-cache: unable to create %s (%s)",
- path, strerror(errno));
+ return error("checkout-cache: unknown file mode for %s", path);
}
- wrote = write(fd, new, size);
- close(fd);
- free(new);
- if (wrote != size)
- return error("checkout-cache: unable to write %s", path);
return 0;
}
@@ -101,7 +119,7 @@ static int checkout_entry(struct cache_e
memcpy(path, base_dir, len);
strcpy(path + len, ce->name);
- if (!stat(path, &st)) {
+ if (!lstat(path, &st)) {
unsigned changed = cache_match_stat(ce, &st);
if (!changed)
return 0;
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -24,7 +24,7 @@ static int get_stat_data(struct cache_en
static unsigned char no_sha1[20];
int changed;
struct stat st;
- if (stat(ce->name, &st) < 0)
+ if (lstat(ce->name, &st) < 0)
return -1;
changed = cache_match_stat(ce, &st);
if (changed) {
--- a/ls-files.c
+++ b/ls-files.c
@@ -199,7 +199,7 @@ static void show_files(void)
struct stat st;
if (excluded(ce->name) != show_ignored)
continue;
- if (!stat(ce->name, &st))
+ if (!lstat(ce->name, &st))
continue;
printf("%s%c", ce->name, line_terminator);
}
--- a/read-cache.c
+++ b/read-cache.c
@@ -13,6 +13,16 @@ int cache_match_stat(struct cache_entry
{
unsigned int changed = 0;
+ switch (ntohl(ce->ce_mode) & S_IFMT) {
+ case S_IFREG:
+ changed |= !S_ISREG(st->st_mode) ? TYPE_CHANGED : 0;
+ break;
+ case S_IFLNK:
+ changed |= !S_ISLNK(st->st_mode) ? TYPE_CHANGED : 0;
+ break;
+ default:
+ die("internal error: ce_mode is %o", ntohl(ce->ce_mode));
+ }
if (ce->ce_mtime.sec != htonl(st->st_mtime))
changed |= MTIME_CHANGED;
if (ce->ce_ctime.sec != htonl(st->st_ctime))
--- a/update-cache.c
+++ b/update-cache.c
@@ -57,19 +57,16 @@ static int add_file_to_cache(char *path)
struct cache_entry *ce;
struct stat st;
int fd;
+ unsigned int len;
+ char target[1024];
- fd = open(path, O_RDONLY);
- if (fd < 0) {
+ if (lstat(path, &st) < 0) {
if (errno == ENOENT || errno == ENOTDIR) {
if (allow_remove)
return remove_file_from_cache(path);
}
return -1;
}
- if (fstat(fd, &st) < 0) {
- close(fd);
- return -1;
- }
namelen = strlen(path);
size = cache_entry_size(namelen);
ce = xmalloc(size);
@@ -78,10 +75,24 @@ static int add_file_to_cache(char *path)
fill_stat_cache_info(ce, &st);
ce->ce_mode = create_ce_mode(st.st_mode);
ce->ce_flags = htons(namelen);
-
- if (index_fd(ce->sha1, fd, &st) < 0)
+ switch (st.st_mode & S_IFMT) {
+ case S_IFREG:
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ return -1;
+ if (index_fd(ce->sha1, fd, &st) < 0)
+ return -1;
+ break;
+ case S_IFLNK:
+ len = readlink(path, target, sizeof(target));
+ if (len == -1 || len+1 > sizeof(target))
+ return -1;
+ if (write_sha1_file(target, len, "blob", ce->sha1))
+ return -1;
+ break;
+ default:
return -1;
-
+ }
return add_cache_entry(ce, allow_add);
}
@@ -137,7 +148,7 @@ static struct cache_entry *refresh_entry
struct cache_entry *updated;
int changed, size;
- if (stat(ce->name, &st) < 0)
+ if (lstat(ce->name, &st) < 0)
return ERR_PTR(-errno);
changed = cache_match_stat(ce, &st);
@@ -145,10 +156,10 @@ static struct cache_entry *refresh_entry
return ce;
/*
- * If the mode has changed, there's no point in trying
+ * If the mode or type has changed, there's no point in trying
* to refresh the entry - it's not going to match
*/
- if (changed & MODE_CHANGED)
+ if (changed & (MODE_CHANGED | TYPE_CHANGED))
return ERR_PTR(-EINVAL);
if (compare_data(ce, st.st_size))
^ permalink raw reply
* [PATCH] Fix git rpush.
From: Anton Altaparmakov @ 2005-05-05 12:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Hi Linus,
Following up from my previouos patch to rpull, please also apply the below
patch which fixes rpush.c to call git-rpull rather than rpull which no
longer exists after the Big Rename(TM)... Thanks.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
---
--- git.git/rpush.c.old 2005-05-05 13:28:37.000000000 +0100
+++ git.git/rpush.c 2005-05-05 13:28:57.000000000 +0100
@@ -61,7 +61,7 @@ int main(int argc, char **argv)
}
commit_id = argv[arg];
url = argv[arg + 1];
- if (setup_connection(&fd_in, &fd_out, "rpull", url, arg, argv + 1))
+ if (setup_connection(&fd_in, &fd_out, "git-rpull", url, arg, argv + 1))
return 1;
service(fd_in, fd_out);
^ permalink raw reply
* [PATCH] Fix git rpull.
From: Anton Altaparmakov @ 2005-05-05 11:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Hi Linus,
Please apply the below patch which fixes rpull.c to call git-rpush rather
than rpush which no longer exists after the Big Rename(TM)... Thanks.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
---
--- git.git/rpull.c.old 2005-05-05 12:00:07.000000000 +0100
+++ git.git/rpull.c 2005-05-05 12:00:13.000000000 +0100
@@ -43,7 +43,7 @@ int main(int argc, char **argv)
commit_id = argv[arg];
url = argv[arg + 1];
- if (setup_connection(&fd_in, &fd_out, "rpush", url, arg, argv + 1))
+ if (setup_connection(&fd_in, &fd_out, "git-rpush", url, arg, argv + 1))
return 1;
if (pull(commit_id))
^ permalink raw reply
* read-only git repositories
From: David Lang @ 2005-05-05 9:51 UTC (permalink / raw)
To: git
In-Reply-To: <200505050709.43307.alan@chandlerfamily.org.uk>
given that git already treats everything in the object storage as being
fixed it occured to me that there may be value in makeing it so that git
can make use of more then one pool of storage.
possible uses of this would be to have a bunch of data on read-only media
(say the 3G+ kernel history on a DVD), having a pruned local object store
with automated fetching from elsewhere if the object isn't found locally,
or marking the object store that you plan on sharing with the world as
read-only (with your changed object going into a secondary store) so that
you don't pollute it accidently (this could also cut down on the storage
requirements)
there are probably other uses and it seems like a fairly small
modification to add a hook to use if the object isn't found initially that
I thought I'd mention it to the group.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* [PATCH] have commit-id dereference git tags
From: Alexander Beyn @ 2005-05-05 7:48 UTC (permalink / raw)
To: git
With this patch, if commit-id is passed a git tag, it will check to see
if the tag points to a commit. If it does, commit-id will return that
commit's id.
I'm not sure if this is the proper place to handle git tags, but it does
make things like "cg-diff -r v2.6.12-rc2:v2.6.12-rc3" work in the Linus
kernel tree. I've not noticed any problems this introduces, but I didn't
do a thorough check.
Signed-Off-By: Alexander Beyn <malex-git@fatelectrons.org>
Index: commit-id
===================================================================
--- 6a20fd05c468097d5a5a47cd37b41581c963cf63/commit-id (mode:100755 sha1:daf0ea1e35f1bee22eb4c4771495b2212d15f4e7)
+++ 66fded2e9d931ecc8b03aa282a7eb9559955c172/commit-id (mode:100755 sha1:978c3ffeb072422436af7af1ad4a8de0e91c9632)
@@ -32,7 +32,15 @@
exit 1
fi
-if [ "$(git-cat-file -t "$id")" != "commit" ]; then
+type="$(git-cat-file -t "$id")"
+
+if [ "$type" = "tag" ]; then
+ id=$(git-cat-file tag "$id" | egrep -m 1 "^object $SHA1")
+ id="${id#object }"
+ type="$(git-cat-file -t "$id")"
+fi
+
+if [ "$type" != "commit" ]; then
echo "Invalid id: $id" >&2
exit 1
fi
^ permalink raw reply
* Re: commit-id fails after cg-init
From: Alexey Nezhdanov @ 2005-05-05 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <4278E6D4.6060807@dwheeler.com>
Wensday, 04 May 2005 19:14 David A. Wheeler wrote:
> Joel Becker said:
> > Well, cg-init in this case creates no objects. I'd say,
> >instead, it should create an empty tree object (representing a project
> >with no files) and commit that. That would be your initial commit, and
> >would put something valid in heads/master.
>
> That would actually make sense; commits would go all the way
> back to the "empty tree" as the ultimate initial tree.
>
> There's an interesting side-effect of this; I _think_ it's
> fine but it might be worth thinking through. If all
> new projects start with an empty tree, that creates a
> "common root" that all projects can appeal to.
> That means that in theory a merge between any two project root
> trees can eventually find a common ancestor: the empty tree.
> I _think_ that's okay... is it?
>
> That also means that empty directories will end up with the
> "empty tree" as well. Is there a risk of multiple empty directories
> causing problems later? As far as I can tell, there aren't
> any problems with that, and does seem logically sound.
I think this problem can be easily solved with:
1) Restricting to auto-select empty commit as the merge base
2) Make an exception from rule (1) for first real commit
By (1) we will restrict accidental bad merges that can happen due to crasy
operator - he will need to explicitly select empty commit as merge base.
By (2) we will allow to pull and merge projects that is just started
envolving.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Alan Chandler @ 2005-05-05 6:09 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.21.0505041854040.30848-100000@iabervon.org>
On Thursday 05 May 2005 00:03, Daniel Barkalow wrote:
> (on the other hand, it might make sense for git to handle files starting
> with '.', and only skip .git).
definitely only as an option. I envisage checking out (maybe anonymously)
from svn or other repositories and then using git locally to manage my own
development. It would be preferable for the .git repository not to be
"polluted" with the svn prisine trees etc
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Plumbing pull request
From: Junio C Hamano @ 2005-05-05 6:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Linus, please pull from
http://members.cox.net/junkio/git-jc.git
which will update the following files:
diff-cache.c | 23 ++++++-
diff.c | 58 ++++++++++++++------
git-apply-patch-script | 141 +++++++++++++++++++++++++++++++++++--------------
update-cache.c | 42 +++++++++++++-
4 files changed, 202 insertions(+), 62 deletions(-)
via the following commits:
----------------------------------------------------------------
Prepare git-apply-patch-script for symbolic links.
This patch prepares the git-apply-patch-script for the upcoming change
to store the symbolic links in the cache, being worked on by Kay
Sievers.
It currently is very anal about symbolic link changes. It refuses to
change between a regular file and a symbolic link, and only allows
symbolic link changes if the patch is based on the same original.
----------------------------------------------------------------
Prepare diff side for upcoming symlink work.
This patch prepares the external diff interface engine for the
change to store the symbolic links in the cache, being worked on
by Kay Sievers.
The main thing it does is when comparing with the work tree, it
prepares the counterpart to the blob being compared by doing a
readlink followed by sending that result to a temporary file to
be diffed.
----------------------------------------------------------------
diff-cache shows differences for unmerged paths without --cache.
While manually resolving a merge conflict, being able to run
diff-cache without --cache option between files in the work tree
and either of the ancestor trees is helpful to verify the hand
merge result. However, diff-cache refuses to handle unmerged
paths, even when run without --cache option.
This changes the behaviour so that the above use case will
report the differences between the compared tree and the magic
0{40} SHA1 (i.e. "look at the work tree"). When there is no
corresponding file in the work tree, or when the command is run
with "--cache" option, it continues to report "unmerged".
----------------------------------------------------------------
Do not write out new index if nothing has changed.
The git-update-cache command, especially with --refresh, may not change
anything. In such a case, writing 1.6MB of the same thing is a waste.
----------------------------------------------------------------
Make git-prune-script executable again.
I do not know why the executable bit was lost since the change went in as
GIT pull, not via e-mail patch, but here is a fix.
----------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] add the ability to create and retrieve delta objects
From: Nicolas Pitre @ 2005-05-05 3:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Mason, C. Scott Ananian, Alon Ziv, git
In-Reply-To: <Pine.LNX.4.58.0505041501220.2328@ppc970.osdl.org>
On Wed, 4 May 2005, Linus Torvalds wrote:
> I'll happily take the patch and just not use the delta packing myself (at
> least until I trust it). But before I take the patch I want to make sure
> that people agree on it, and that it's been tested well enough that it
> won't cause people to corrupt their repositories.
To that effect I'm adding knowledge of delta objects to fsck-cache, to
verify lists of deltas are all reachable and that they all expand to the
expected data. This way it would be a good test to completely deltafy a
whole repository, run fsck-cache to ensure everything is fine, and
undeltafy it all to see if things are still sane.
> For example, I do _not_ want to be in the situation SVN is in, where if
> you corrupt your SVN database, you're totally screwed. There's a real
> advantage to not having fancy data structures or complicated consistency
> rules.
With deltas it is still a bit more risky by design since many objects
end up depending on a single one. You loose that top object and it's
all the delta chain that's gone. But having the choice to use them or
not is what makes the whole system flexible and suited to anyone's
balance between robustness vs disk space. Converting back and forth is
certainly not a problem with the git model.
And if you deltafy things such that the objects in your head tree are
always top of delta chain then you're not badly affected if some
intermediate delta objects are corrupted since they are part of old
trees only.
Nicolas
^ permalink raw reply
* Re: [PATCH] add the ability to create and retrieve delta objects
From: Nicolas Pitre @ 2005-05-05 3:10 UTC (permalink / raw)
To: Chris Mason; +Cc: Geert Bosch, Linus Torvalds, Alon Ziv, git
In-Reply-To: <200505041834.19053.mason@suse.com>
On Wed, 4 May 2005, Chris Mason wrote:
> On Wednesday 04 May 2005 17:47, Geert Bosch wrote:
> > From your tests it would seem that the zdelta version is the only one
> > to provide a uniform improvement over plain git. As it also seems the
> > simplest approach, I wonder why the consensus is that using xdiff
> > would be better?
>
> zdelta seems to be a research project. It does compress better than the xdiff
> lib, but the speed improvements against xdiff(1) are probably because the
> resulting tree is smaller. I favor the xdiff code because it's so much
> smaller, and seems easier for us to maintain.
Yep. And compression can be improved without changing de decompressor
since the decompressor is only a replay of what the compressor found to
be redundent. That redundency searching can probably be improved wrt to
the current code. And FRankly considering about 300 lines of code to
create a delta and 60 lines to expand it is hard to beat maintenance
wise.
> For performance, there's still quite a bit of tuning that can be done in terms
> of when and how we delta.
Indeed.
Nicolas
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Junio C Hamano @ 2005-05-05 2:13 UTC (permalink / raw)
To: Kay Sievers; +Cc: Linus Torvalds, git
In-Reply-To: <20050505012051.GA26201@vrfy.org>
>>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
>> * It continues to assume that S_IFREG, S_IFDIR and S_IFLNK have
>> the same bit pattern everywhere....
>> * read-cache.c:cache_match_stat() ...
KS> Both included and updated.
The second one, yes, but the first one is "not really". If you
are going to do this:
KS> +#define CE_IFREG 0100000
KS> +#define CE_IFDIR 0040000
KS> ...
KS> +#define CE_IFMASK 0770000
then you need to touch these things:
KS> + mode = ntohl(ce->ce_mode);
KS> + if (S_ISLNK(mode)) {
Here mode encodes type in CE_ format, so S_ISLNK() is bad.
KS> @@ -165,7 +165,7 @@ static void prepare_temp_file(const char
KS> }
KS> strcpy(temp->hex, sha1_to_hex(null_sha1));
KS> sprintf(temp->mode, "%06o",
KS> - S_IFREG |ce_permissions(st.st_mode));
KS> + S_IFREG | ce_permissions(st.st_mode));
KS> }
Likewise here, although this is my bad. I did not know if you
are going to take CE_ type suggestion so I left it as it was.
There are more. "grep 'S_I[SF]' *.[ch] */*.[ch]" would tell us
most if not all. We probably would want to have CE_ISLNK() and
friends, parallel to S_ISLNK() and friends if we go this route.
Does POSIX or something have nice to say that we do not have to
worry about this? Or are the stat type bits really different on
different Unixen? I used to do porting for living across a
dozen or so different Unixen long time ago and I should know the
answer to this kind of thing by heart, but I do not anymore X-<.
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: H. Peter Anvin @ 2005-05-05 2:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, David Woodhouse
In-Reply-To: <Pine.LNX.4.58.0505041639130.2328@ppc970.osdl.org>
It used to be Jeff Garzik, but David Woodhouse volunteered to take this
over a few days ago, so yesterday I chowned those directories to him.
-hpa
Linus Torvalds wrote:
> I forget who it is that used to do the nightly snapshots for the BK
> kernels, but I _think_ it was David Woodhouse (every time I've blamed it
> on somebody, I've blamed the wrong person, so I'm probably off on this one
> too, but maybe I finally got it right).
>
> I was wondering how to get that re-started.. It should be technically
> pretty easy, except I realized that my tree doesn't even have plain 2.6.11
> in it. But I just fixed that in the tree, since I need such a baseline
> myself for my next release..
>
> Anyway, I just pushed out a kernel tree that contains a tag of a _tree_
> that points to the tree at the point of 2.6.11. I also had to teach
> fsck-cache about the fact that you can give it any kind of object to start
> your references at, and to make fsck-cache happy, you need to
>
> git-fsck-cache --unreachable HEAD v2.6.11
>
> to tell it that the kernel tree now has an unconnected tree (described by
> the tag "v2.6.11-tree", and I made the appropriate entry for it in
> .git/refs/tags).
>
> I also updated git-prune-script to not remove these kinds of things.
>
> With this, it should be trivial to create snapshots with
>
> git-diff-tree -p v2.6.11 HEAD
>
> or similar.
>
> Linus
^ permalink raw reply
* [PATCH] shut up gcc4's signed pointer warnings
From: Kay Sievers @ 2005-05-05 1:30 UTC (permalink / raw)
To: git
Suppress these stupid warnings if gcc supports it:
ls-tree.c: In function ‘list_recursive’:
ls-tree.c:34: warning: pointer targets in passing argument 1 of ‘strlen’ differ in signedness
ls-tree.c:34: warning: pointer targets in passing argument 1 of ‘__builtin_strcmp’ differ in signedness
ls-tree.c:34: warning: pointer targets in passing argument 1 of ‘strlen’ differ in signedness
ls-tree.c:34: warning: pointer targets in passing argument 1 of ‘__builtin_strcmp’ differ in signedness
ls-tree.c:34: warning: pointer targets in passing argument 1 of ‘__builtin_strcmp’ differ in signedness
ls-tree.c:34: warning: pointer targets in passing argument 1 of ‘__builtin_strcmp’ differ in signedness
ls-tree.c:66: warning: pointer targets in passing argument 2 of ‘list_recursive’ differ in signedness
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
--- a/Makefile
+++ b/Makefile
@@ -7,7 +7,11 @@
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
+
+cc-supports = ${shell if $(CC) ${1} -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; fi;}
+
CFLAGS=-g -O2 -Wall
+CFLAGS+= $(call cc-supports,-Wno-pointer-sign)
CC=gcc
AR=ar
^ 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