* 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
* 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
* [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
* 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] 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
* [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
* 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
* 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
* 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: 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
* 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: 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: 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: 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: 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: 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: 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
* [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: 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
* Re: Kernel nightly snapshots..
From: Linus Torvalds @ 2005-05-05 16:40 UTC (permalink / raw)
To: David Woodhouse; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <1115307033.16187.146.camel@hades.cambridge.redhat.com>
On Thu, 5 May 2005, David Woodhouse wrote:
>
> 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
Btw, if you want to, you could simplify and optimize things heavily by
doign some very specific git internal mucking around, and using the new
"-m" flag I added to "git-diff-cache".
The "-m" flag says that a file that isn't checked out will always match
the cache, which means that you can create your magic diffs that modify
the Makefile with something like this:
export SNAP_TAG_DIRECTORY=/pub/linux/kernel/v2.6/snapshots/tags
export BASE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6
export SHA1_FILE_DIRECTORY=$BASE_DIRECTORY/objects
RELNAME=`ls $BASE_DIRECTORY/refs/tags | tail -1`
RELCOMM=`cat $BASE_DIRECTORY/refs/tags/$RELNAME`
CURCOMM=`cat $BASE_DIRECTORY/HEAD`
SNAPNAME=`ls $SNAP_TAG_DIRECTORY | grep -- "$RELNAME-git" | tail -1`
if [ "$SNAPNAME" ]; then
SNAPCOMM=`cat $SNAP_TAG_DIRECTORY/$SNAPNAME`
[ "$SNAPCOMM" == "$CURCOMM" ] && exit 0
OLDGITNUM=`echo $SNAPNAME | sed s/^.*-git//`
NEWGITNUM=`expr $OLDGITNUM + 1`
CURNAME="$RELNAME-git$NEWGITNUM"
else
CURNAME="$RELNAME-git1"
fi
EXTRAVERSION=-`echo $CURNAME | cut -f2- -d-`
rm -rf tmp-empty-tree
mkdir -p tmp-empty-tree/.git
( cd tmp-empty-tree
git-read-tree $CURCOMM
git-checkout-cache Makefile
perl -pi -e "s/EXTRAVERSION =.*/EXTRAVERSION = $EXTRAVERSION/" Makefile
git-diff-cache -m -p $RELCOMM ) | gzip -9 > patch-$CURNAME.gz
echo CURCOMM > $SNAP_TAG_DIRECTORY/$CURNAME
but it's entirely untested, and only written in my mail editor, so..
Anyway, here's explaining what it does:
- it creates a new "tmp-empty-tree" thing, and points the object database
to _my_ tree (which is unwritable for you, but you don't care, you just
want to read it)
- it picks up my last tag as the release, and your last git tag from your
private snapshot tag directory as the last git thing. Then it takes my
current HEAD as the new thing to diff.
- we read that current tree into this empty tree, but we don't check any
of it out except for the Makefile. So the "tmp-empty-tree" should
literally just have the files "Makefile" and ".git/index" in it.
- we edit the Makefile, and then we do "git-diff-cache -m -p" between the
result and the old base.
This _should_ work. Modulo bugs. And it should be reasonably efficient. It
just needs my current git tree as of five minutes ago..
Linus
^ permalink raw reply
* Re: Mercurial v0.4d
From: Jeff Garzik @ 2005-05-05 19:04 UTC (permalink / raw)
To: Matt Mackall; +Cc: linux-kernel, git, Linus Torvalds
In-Reply-To: <20050504181802.GS22038@waste.org>
Matt Mackall wrote:
> The web protocol is painfully slow, mostly because it makes an http
> round trip per file revision to pull. I'm about to start working on a
> replacement that minimizes round trips.
Can you make it do HTTP 1.1 pipelining?
Jeff
^ permalink raw reply
* [PATCH] git: Mention the '-p' option in the usage help string if git-diff-tree.
From: Thomas Glanzmann @ 2005-05-05 19:51 UTC (permalink / raw)
To: Linus Torvalds, GIT
Mention the '-p' option in the usage help string of git-diff-tree.
Signed-Off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -250,7 +250,7 @@ static int diff_tree_sha1(const unsigned
return retval;
}
-static char *diff_tree_usage = "diff-tree [-r] [-z] <tree sha1> <tree sha1>";
+static char *diff_tree_usage = "diff-tree [-p] [-r] [-z] <tree sha1> <tree sha1>";
int main(int argc, char **argv)
{
^ permalink raw reply
* Re: Mercurial v0.4d
From: Matt Mackall @ 2005-05-05 20:36 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, git, Linus Torvalds
In-Reply-To: <427A6E3F.5090904@pobox.com>
On Thu, May 05, 2005 at 03:04:31PM -0400, Jeff Garzik wrote:
> Matt Mackall wrote:
> >The web protocol is painfully slow, mostly because it makes an http
> >round trip per file revision to pull. I'm about to start working on a
> >replacement that minimizes round trips.
>
> Can you make it do HTTP 1.1 pipelining?
Yes, a zsync-like protocol ought to be doable. But you'll still
potentially be doing 16k requests to pull something the size of the
kernel, which isn't very friendly to a web server. So I'm working on a
stand-alone or possibly CGI-based replacement.
My goal is to do something like this:
client server
I last saw change N from you
W, X, Y, and Z are newer here
Send me X, Y, and Z relative to N
Here you go, deltas from N to X to
Y to Z, sorted by file
So not only can we be efficient in number of round trips and data
transferred, we can reduce seeks by applying all per-file changes together.
We can also usually avoid decompress/recompress and patch/diff because
both ends will end up storing the same delta.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] have commit-id dereference git tags
From: Matt Porter @ 2005-05-05 21:14 UTC (permalink / raw)
To: Alexander Beyn; +Cc: git
In-Reply-To: <20050505074823.GA9075@fatelectrons.org>
On Thu, May 05, 2005 at 12:48:23AM -0700, Alexander Beyn wrote:
> 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.
I like this feature and it works on the Linus tree for me as well.
However, it fails on the cogito tree as follows:
mporter@beef:~/src/cogito$ cg-diff -r git-pasky-0.7:cogito-0.8
.git/objects/c8/3b95297c2a6336c2007548f909769e0862b509: No such file or directory
fatal: git-cat-file c83b95297c2a6336c2007548f909769e0862b509: bad file
Invalid id: c83b95297c2a6336c2007548f909769e0862b509
usage: git-cat-file [-t | tagname] <sha1>
usage: git-cat-file [-t | tagname] <sha1>
Invalid id:
I haven't looked any further at it yet though.
-Matt
^ permalink raw reply
* list all dirty files in working directory
From: Thomas Glanzmann @ 2005-05-05 21:21 UTC (permalink / raw)
To: GIT
Hello,
is there another way than call 'checkout-cache -a' and parse the output?
Maybe a command which lists one dirty file per line?
Thomas
^ 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