* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 10:42 UTC (permalink / raw)
To: Sean; +Cc: David Woodhouse, git
In-Reply-To: <3203.10.10.10.24.1115893120.squirrel@linux1>
On Thu, 2005-05-12 at 06:18 -0400, Sean wrote:
> Does BK use a repo ID ?
Yes.
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 10:39 UTC (permalink / raw)
To: David Woodhouse; +Cc: tglx, git
In-Reply-To: <1115892451.16187.561.camel@hades.cambridge.redhat.com>
On Thu, May 12, 2005 6:07 am, David Woodhouse said:
> On Wed, 2005-05-11 at 20:58 -0400, Sean wrote:
>> > Try to find out the history of kernel.org/.../dwmw2/audit-2.6 in
>> > correct order, using the available tools.
>> >
>> > Come back to me when you are done.
>>
>> Ask me any question that matters and i'll answer it with available
>> tools.
>
> The above question matters, so please answer it if you can. I'll make it
> clearer for you though...
>
> By 'correct order' Thomas means the order in which my old BK-export
> script used to generate the "changesets since last release" web page;
> the order in which the changes actually got merged into Linus'
> repository.
>
> If I looked at the page yesterday, and then I look at it again today, I
> want all the commits I hadn't seen already to be at the _top_.
> Regardless of the date on which they were _originally_ committed to some
> private tree elsewhere.
>
> There were a lot of complaints until I worked out how to get that
> ordering out of BitKeeper.
>
Actually, here is one very simple idea, just use the times from the object
files themselves. Now as you descend the hierarchy you can simply stat
the object file to get the "local commit time". Just simply stop
descending down each branch when you find a commit with a time stamp that
is outside the range you're interested in.
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 10:18 UTC (permalink / raw)
To: David Woodhouse; +Cc: tglx, git
In-Reply-To: <1115892451.16187.561.camel@hades.cambridge.redhat.com>
On Thu, May 12, 2005 6:07 am, David Woodhouse said:
> On Wed, 2005-05-11 at 20:58 -0400, Sean wrote:
>> > Try to find out the history of kernel.org/.../dwmw2/audit-2.6 in
>> > correct order, using the available tools.
>> >
>> > Come back to me when you are done.
>>
>> Ask me any question that matters and i'll answer it with available
>> tools.
>
> The above question matters, so please answer it if you can. I'll make it
> clearer for you though...
>
> By 'correct order' Thomas means the order in which my old BK-export
> script used to generate the "changesets since last release" web page;
> the order in which the changes actually got merged into Linus'
> repository.
>
> If I looked at the page yesterday, and then I look at it again today, I
> want all the commits I hadn't seen already to be at the _top_.
> Regardless of the date on which they were _originally_ committed to some
> private tree elsewhere.
>
> There were a lot of complaints until I worked out how to get that
> ordering out of BitKeeper.
>
Does BK use a repo ID ? If not, can you not apply the same process to
git? Seems the fast forward heads might complicate things slightly....
Sean
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: David Woodhouse @ 2005-05-12 10:07 UTC (permalink / raw)
To: Sean; +Cc: tglx, git
In-Reply-To: <3259.10.10.10.24.1115859535.squirrel@linux1>
On Wed, 2005-05-11 at 20:58 -0400, Sean wrote:
> > Try to find out the history of kernel.org/.../dwmw2/audit-2.6 in
> > correct order, using the available tools.
> >
> > Come back to me when you are done.
>
> Ask me any question that matters and i'll answer it with available
> tools.
The above question matters, so please answer it if you can. I'll make it
clearer for you though...
By 'correct order' Thomas means the order in which my old BK-export
script used to generate the "changesets since last release" web page;
the order in which the changes actually got merged into Linus'
repository.
If I looked at the page yesterday, and then I look at it again today, I
want all the commits I hadn't seen already to be at the _top_.
Regardless of the date on which they were _originally_ committed to some
private tree elsewhere.
There were a lot of complaints until I worked out how to get that
ordering out of BitKeeper.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 9:46 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115890792.22180.306.camel@tglx>
On Thu, May 12, 2005 5:39 am, Thomas Gleixner said:
> Please do the complete test. Sync test2 with test1 and show me the
> picture there. It will be the same as you see in test1, which is wrong
It will get the fast forward head from test1, and so it _should_ show the
exact same thing! The repositories are in sync, they should display the
exact same way. What is the problem?
> Having the repository id in there you can identify the different order
> of test2
>
What different order? Everything I want as a developer or even as a QA
department is right there in front of me. What VALUE does some other
order have? What question will you answer with a different order? Who
will ask this question? Why would anyone care?
Sean
^ permalink raw reply
* Mercurial 0.4e vs git network pull
From: Matt Mackall @ 2005-05-12 9:44 UTC (permalink / raw)
To: linux-kernel, git, mercurial, Linus Torvalds
Now that I'm back from vacation, there's a new Mercurial release as
well as snapshots at:
http://selenic.com/mercurial/
A combined self-hosting repository / web interface can be found at:
http://selenic.com/hg/
And there's now a mailing list at:
http://selenic.com/mailman/listinfo/mercurial
The big news is that Mercurial now has a very fast network protocol.
This benchmark is pulling and merging 819 changesets (again, taken
from 2.6.12-rc2-mm3) from one repo to another over DSL using
Mercurial's new delta protocol:
$ time hg merge hg://selenic.com/linux-hg/
retrieving changegroup
merging changesets
merging manifests
merging files
real 0m10.276s
user 0m3.299s
sys 0m0.689s
For comparison, rsyncing the same set of changes between git repos from
the same server:
$ time rsync -a rsync://10.0.0.12:2000/git/lgb/.git .
sent 171508 bytes received 31225542 bytes 312408.46 bytes/sec
real 1m40.470s
user 0m0.655s
sys 0m1.896s
The original broken-out.tar.bz2: 2.3M
The same, uncompressed: 15M
The same, rsynced with git: 30M
The same, pulled with hg (zlib): 2.5M <- what I used above
The same, pulled with hg (bz2): 2.1M
The server in question is a relatively busy 1GHz Athlon. The server
side of the hg protocol is stateless and is serviced by a simple CGI
script run under Apache.
Mercurial is more than 10 times as bandwidth efficient and
considerably more I/O efficient. On the server side, rsync uses about
twice as much CPU time as the Mercurial server and has about 10 times
the I/O and pagecache footprint as well.
Mercurial is also much smarter than rsync at determining what
outstanding changesets exist. Here's an empty pull as a demonstration:
$ time hg merge hg://selenic.com/linux-hg/
retrieving changegroup
real 0m0.363s
user 0m0.083s
sys 0m0.007s
That's a single http request and a one line response.
And now with rsync:
$ time rsync -av rsync://10.0.0.12:2000/git/lgb/.git .
receiving file list ... done
sent 76 bytes received 1280245 bytes 2560642.00 bytes/sec
total size is 85993841 speedup is 67.17
real 0m0.539s
user 0m0.185s
sys 0m0.148s
Mercurial's communication here scales O(min(changed branches, log new
changesets)) which is less than O(new changesets), while rsync scales
with O(total number of file revisions) (ouch!). The above transfer
size for an empty pull will go from 1.2M to >12M when there's similar
history in git to what's in BK.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 9:39 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1895.10.10.10.24.1115890333.squirrel@linux1>
On Thu, 2005-05-12 at 05:32 -0400, Sean wrote:
> In fact, please see attached .png image that shows how the nice gitk tool
> from Paul Mackerras displays it exactly as you request WITHOUT Repo-id.
Please do the complete test. Sync test2 with test1 and show me the
picture there. It will be the same as you see in test1, which is wrong
> * Please * explain what problem you are trying to solve and how repoid
> will solve it.
Having the repository id in there you can identify the different order
of test2
tglx
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Sean @ 2005-05-12 9:32 UTC (permalink / raw)
To: tglx; +Cc: Junio C Hamano, H. Peter Anvin, git
In-Reply-To: <1115884637.22180.277.camel@tglx>
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
On Thu, May 12, 2005 3:57 am, Thomas Gleixner said:
> On Wed, 2005-05-11 at 18:46 -0700, Junio C Hamano wrote:
>> >>>>> "TG" == Thomas Gleixner <tglx@linutronix.de> writes:
>> So I am having a hard time understanding what problem repo-id
>> solves.
>
> Rn o
> > \
> Rn-1 o |
> > o Mn
> > o Mn-1
> Rn-2 o /
> Rn-3 o
>
[snip]
All you forgot was to explain how repo-id helps one iota. And if you're
up to it, explain how it would help sort out the following, where Xn is a
fast forward head:
Rn o
> \
Rn-1 o |
> o Mn
> o Mn-1
Rn-2 o /
Xn o
And what about sorting out branches created by a single developer in a
single repository? doh! Sounds like a solution that addresses all these
should be worked out instead of repoid. You really are barking up the
wrong tree here.
Just because rev-tree may get it wrong, doesn't mean every other tool does.
Actually, I just ran your above scenario through git, and here is what
cg-log shows, which seems perfectly acceptable:
commit 19de0d5cd9269f0869fecb0b866efa12ef882a11
parent 490ae38bcbf70fe19bcc0c1a28d1fa301620a2d5
parent 71890fc6b9e3da470623dbbf3dc492b937757a37
Merge with ../test2/.git
Rn
commit 490ae38bcbf70fe19bcc0c1a28d1fa301620a2d5
parent b96d60d7b632a188f4550762f8a1a99f8b381c9b
Rn-1
commit b96d60d7b632a188f4550762f8a1a99f8b381c9b
parent 0dbe9da9b565bb695d464532470734c6f4676951
Rn-2
commit 71890fc6b9e3da470623dbbf3dc492b937757a37
parent 81dbf4bac14c3caeadfa084d57ad78544e69d6d8
Mn
commit 81dbf4bac14c3caeadfa084d57ad78544e69d6d8
parent 0dbe9da9b565bb695d464532470734c6f4676951
Mn-1
commit 0dbe9da9b565bb695d464532470734c6f4676951
parent 221a1474b35d700fd67895cb6206d04fc17b083a
Rn-3
In fact, please see attached .png image that shows how the nice gitk tool
from Paul Mackerras displays it exactly as you request WITHOUT Repo-id.
* Please * explain what problem you are trying to solve and how repoid
will solve it.
Sean
[-- Attachment #2: what_problem.png --]
[-- Type: image/png, Size: 2188 bytes --]
^ permalink raw reply
* [PATCH] Add git-ls-files -k option.
From: Junio C Hamano @ 2005-05-12 9:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Pasky, you may remember the discussion on how "chilly" the
proposed behaviour of checkout-cache -f obliterating conflicting
paths was, and what I think is needed for the Porcelain layer if
it chooses to save such files before checking things out.
Here is a patch to add -k (killed) option to git-ls-files to
find out what files are need to be killed to make checkout-cache
to succeed. The Porcelain can run it immediately before
checkout-cache, save the files reported, and the run
checkout-cache -f. If your checkout-cache does not have that
"chilly" enhancement, in addition to saving the files above, it
also has to move them out of the way.
Note: To be applied after ls-files --other symlink fix.
------------
When checkout-cache attempts to check out a non-directory where
a directory exists on the work tree, or to check out a file
under directory D when path D is a non-directory on the work
tree, the attempt fails. Before running checkout-cache, the
user can run git-ls-files with the -k (killed) option to get a
list of such paths.
This also includes the test for this functionality and
documentation of the new option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-ls-files.txt | 10 +++-
ls-files.c | 95 +++++++++++++++++++++++++++++++++--------
t/t0500-ls-files.sh | 55 +++++++++++++++++++++++
3 files changed, 140 insertions(+), 20 deletions(-)
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -10,8 +10,8 @@ git-ls-files - Information about files i
SYNOPSIS
--------
'git-ls-files' [-z] [-t]
- (--[cached|deleted|others|ignored|stage|unmerged])\*
- (-[c|d|o|i|s|u])\*
+ (--[cached|deleted|others|ignored|stage|unmerged|killed])\*
+ (-[c|d|o|i|s|u|k])\*
[-x <pattern>|--exclude=<pattern>]
[-X <file>|--exclude-from=<file>]
@@ -45,6 +45,11 @@ OPTIONS
-u|--unmerged::
Show unmerged files in the output (forces --stage)
+-k|--killed::
+ Show files on the filesystem that need to be removed due
+ to file/directory conflicts for checkout-cache to
+ succeed.
+
-z::
\0 line termination on output
@@ -65,6 +70,7 @@ OPTIONS
H cached
M unmerged
R removed/deleted
+ K to be killed
? other
Output
--- a/ls-files.c
+++ b/ls-files.c
@@ -16,12 +16,14 @@ static int show_others = 0;
static int show_ignored = 0;
static int show_stage = 0;
static int show_unmerged = 0;
+static int show_killed = 0;
static int line_terminator = '\n';
static const char *tag_cached = "";
static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
+static const char *tag_killed = "";
static int nr_excludes;
static const char **excludes;
@@ -87,24 +89,36 @@ static int excluded(const char *pathname
return 0;
}
-static const char **dir;
+struct nond_on_fs {
+ int len;
+#define IN_CACHE 1
+#define REPORTED_KILL 2
+ char flag;
+ char name[0];
+};
+
+static struct nond_on_fs **dir;
static int nr_dir;
static int dir_alloc;
static void add_name(const char *pathname, int len)
{
- char *name;
+ struct nond_on_fs *ent;
+ int pos;
- if (cache_name_pos(pathname, len) >= 0)
+ pos = cache_name_pos(pathname, len);
+ if (!show_killed && pos >= 0)
return;
if (nr_dir == dir_alloc) {
dir_alloc = alloc_nr(dir_alloc);
- dir = xrealloc(dir, dir_alloc*sizeof(char *));
+ dir = xrealloc(dir, dir_alloc*sizeof(ent));
}
- name = xmalloc(len + 1);
- memcpy(name, pathname, len + 1);
- dir[nr_dir++] = name;
+ ent = xmalloc(sizeof(*ent) + len + 1);
+ ent->flag = (0 <= pos) ? IN_CACHE : 0;
+ ent->len = len;
+ memcpy(ent->name, pathname, len);
+ dir[nr_dir++] = ent;
}
/*
@@ -164,11 +178,46 @@ static void read_directory(const char *p
static int cmp_name(const void *p1, const void *p2)
{
- const char *n1 = *(const char **)p1;
- const char *n2 = *(const char **)p2;
- int l1 = strlen(n1), l2 = strlen(n2);
+ const struct nond_on_fs *e1 = *(const struct nond_on_fs **)p1;
+ const struct nond_on_fs *e2 = *(const struct nond_on_fs **)p2;
+
+ return cache_name_compare(e1->name, e1->len,
+ e2->name, e2->len);
+}
+
+static void show_killed_files()
+{
+ int i, j;
- return cache_name_compare(n1, l1, n2, l2);
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ if (ce_stage(ce))
+ continue; /* these won't be checked out */
+ /* Find things that are being killed; that is,
+ * the ones are prefix of ce->name, or suffix of it.
+ * The ones that are exactly the same as ce->name
+ * are fine, because they are what are going to be
+ * checked out.
+ */
+ for (j = 0; j < nr_dir; j++) {
+ int len;
+ int l;
+ if (dir[j]->flag & REPORTED_KILL)
+ continue;
+ len = ce_namelen(ce);
+ l = (len < dir[j]->len) ? len : dir[j]->len;
+ if (!strncmp(ce->name, dir[j]->name, l) &&
+ ( ((len < dir[j]->len) &&
+ (dir[j]->name[l] == '/')) ||
+ ((dir[j]->len < len) &&
+ (ce->name[l] == '/')) ) ) {
+ printf("%s%.*s%c", tag_killed,
+ dir[i]->len, dir[i]->name,
+ line_terminator);
+ dir[j]->flag |= REPORTED_KILL;
+ }
+ }
+ }
}
static void show_files(void)
@@ -176,11 +225,18 @@ static void show_files(void)
int i;
/* For cached/deleted files we don't need to even do the readdir */
- if (show_others) {
+ if (show_others || show_killed) {
read_directory(".", "", 0);
- qsort(dir, nr_dir, sizeof(char *), cmp_name);
- for (i = 0; i < nr_dir; i++)
- printf("%s%s%c", tag_other, dir[i], line_terminator);
+ qsort(dir, nr_dir, sizeof(struct nond_on_fs *), cmp_name);
+ if (show_others)
+ for (i = 0; i < nr_dir; i++)
+ if (!(dir[i]->flag & IN_CACHE))
+ printf("%s%.*s%c", tag_other,
+ dir[i]->len,
+ dir[i]->name,
+ line_terminator);
+ if (show_killed)
+ show_killed_files();
}
if (show_cached | show_stage) {
for (i = 0; i < active_nr; i++) {
@@ -219,8 +275,8 @@ static void show_files(void)
}
static const char *ls_files_usage =
- "ls-files [-z] [-t] (--[cached|deleted|others|stage|unmerged])* "
- "[ --ignored [--exclude=<pattern>] [--exclude-from=<file>) ]";
+"ls-files [-z] [-t] (--[cached|deleted|others|stage|unmerged|killed])* "
+"[ --ignored [--exclude=<pattern>] [--exclude-from=<file>) ]";
int main(int argc, char **argv)
{
@@ -236,6 +292,7 @@ int main(int argc, char **argv)
tag_unmerged = "M ";
tag_removed = "R ";
tag_other = "? ";
+ tag_killed = "K ";
} else if (!strcmp(arg, "-c") || !strcmp(arg, "--cached")) {
show_cached = 1;
} else if (!strcmp(arg, "-d") || !strcmp(arg, "--deleted")) {
@@ -246,6 +303,8 @@ int main(int argc, char **argv)
show_ignored = 1;
} else if (!strcmp(arg, "-s") || !strcmp(arg, "--stage")) {
show_stage = 1;
+ } else if (!strcmp(arg, "-k") || !strcmp(arg, "--killed")) {
+ show_killed = 1;
} else if (!strcmp(arg, "-u") || !strcmp(arg, "--unmerged")) {
/* There's no point in showing unmerged unless
* you also show the stage information.
@@ -271,7 +330,7 @@ int main(int argc, char **argv)
}
/* With no flags, we default to showing the cached files */
- if (!(show_stage | show_deleted | show_others | show_unmerged))
+ if (!(show_stage | show_deleted | show_others | show_unmerged | show_killed))
show_cached = 1;
read_cache();
Created: t/t0500-ls-files.sh (mode:100755)
--- /dev/null
+++ b/t/t0500-ls-files.sh
@@ -0,0 +1,55 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+. ./test-lib.sh
+test_description "$@" 'git-ls-files -k flag test.
+
+This test prepares the following in the cache:
+
+ path0 - a file
+ path1 - a symlink
+ path2/file2 - a file in a directory
+ path3/file3 - a file in a directory
+
+and the following on the filesystem:
+
+ path0/file0 - a file in a directory
+ path1/file1 - a file in a directory
+ path2 - a file
+ path3 - a symlink
+ path4 - a file
+ path5 - a symlink
+ path6/file6 - a file in a directory
+
+git-ls-files -k should report that existing filesystem
+objects except path4, path5 and path6/file6 to be killed.
+'
+
+date >path0
+ln -s xyzzy path1
+mkdir path2 path3
+date >path2/file2
+date >path3/file3
+git-update-cache --add -- path0 path1 path?/file?
+
+rm -fr path?
+date >path2
+ln -s frotz path3
+ln -s nitfol path5
+mkdir path0 path1 path6
+date >path0/file0
+date >path1/file1
+date >path6/file6
+
+git-ls-files -k >.output
+cat >.expected <<EOF
+path0/file0
+path1/file1
+path2
+path3
+EOF
+
+test_expect_success 'diff .output .expected'
+test_done
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 9:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Dmitry Torokhov, git
In-Reply-To: <4282ADC9.2010900@zytor.com>
On Wed, 2005-05-11 at 18:13 -0700, H. Peter Anvin wrote:
> > You shouldn't be rsyncing the .git directory, only .git/objects anyway.
> > Some people seem to have merely copied Linus' entire tree, and that's
> > what causing problems.
> > That one you can't win.
:)
> What I meant with that is I think .git/repoid is the right thing, if the
> file doesn't exist a new ID file is generated.
Yep, convinced.
The only thing I'd like to see is some thing which is human readable and
maybe helpful to deduce the context of this.
Adding a dev/random number to make it unique is not bad.
So what about
repoid 'pwd' 'random' ?
> If people are copying their repoid file explicitly it's up to them to
> know what they're doing.
True. I makes sense for maintainers doing updates to their public
repositories to keep the same repoid in their working copy at home/work.
tglx
^ permalink raw reply
* [PATCH] Tests for env variable rename and update-cache f/d conflicts.
From: Junio C Hamano @ 2005-05-12 8:06 UTC (permalink / raw)
To: pasky; +Cc: git
These are test cases to prevent regression from happening for
the recent two changes we made. They depend on the test suite
infrastructure I have sent in earlier.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t0100-environment-names.sh | 82 +++++++++++++++++++++++++++++++++++++++++++
t/t0200-update-cache.sh | 46 ++++++++++++++++++++++++
2 files changed, 128 insertions(+)
Created: t/t0100-environment-names.sh (mode:100755)
--- /dev/null
+++ b/t/t0100-environment-names.sh
@@ -0,0 +1,82 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+. ./test-lib.sh
+test_description "$@" 'general environment name warning test.
+
+This test makes sure that use of deprecated environment variables
+trigger the warnings from gitenv().'
+
+env_vars='GIT_AUTHOR_DATE:AUTHOR_DATE
+GIT_AUTHOR_EMAIL:AUTHOR_EMAIL
+GIT_AUTHOR_NAME:AUTHOR_NAME
+GIT_COMMITTER_EMAIL:COMMIT_AUTHOR_EMAIL
+GIT_COMMITTER_NAME:COMMIT_AUTHOR_NAME
+GIT_ALTERNATE_OBJECT_DIRECTORIES:SHA1_FILE_DIRECTORIES
+GIT_OBJECT_DIRECTORY:SHA1_FILE_DIRECTORY'
+
+export_them () {
+ for ev in $env_vars
+ do
+ new=$(expr "$ev" : '\(.*\):')
+ old=$(expr "$ev" : '.*:\(.*\)')
+ # Build and eval the following:
+ # case "${VAR+set}" in set) export VAR;; esac
+ evstr='case "${'$new'+set}" in set) export '$new';; esac'
+ eval "$evstr"
+ evstr='case "${'$old'+set}" in set) export '$old';; esac'
+ eval "$evstr"
+ done
+}
+
+date >path0
+git-update-cache --add path0
+tree=$(git-write-tree)
+
+AUTHOR_DATE='Wed May 11 23:55:18 2005'
+AUTHOR_EMAIL='author@example.xz'
+AUTHOR_NAME='A U Thor'
+COMMIT_AUTHOR_EMAIL='author@example.xz'
+COMMIT_AUTHOR_NAME='A U Thor'
+SHA1_FILE_DIRECTORY=.git/objects
+
+export_them
+
+test_debug 'echo with only old variables exported.'
+
+echo 'foo' | git-commit-tree $tree >/dev/null 2>errmsg
+cat >expected-err <<\EOF
+warning: Attempting to use SHA1_FILE_DIRECTORY
+warning: GIT environment variables have been renamed.
+warning: Please adjust your scripts and environment.
+warning: old AUTHOR_DATE => new GIT_AUTHOR_DATE
+warning: old AUTHOR_EMAIL => new GIT_AUTHOR_EMAIL
+warning: old AUTHOR_NAME => new GIT_AUTHOR_NAME
+warning: old COMMIT_AUTHOR_EMAIL => new GIT_COMMITTER_EMAIL
+warning: old COMMIT_AUTHOR_NAME => new GIT_COMMITTER_NAME
+warning: old SHA1_FILE_DIRECTORY => new GIT_OBJECT_DIRECTORY
+EOF
+sed -ne '/^warning: /p' <errmsg >generated-err
+test_debug 'cat errmsg'
+test_expect_success 'cmp generated-err expected-err'
+
+test_debug 'echo with new variables exported.'
+
+for ev in $env_vars
+do
+ new=$(expr "$ev" : '\(.*\):')
+ old=$(expr "$ev" : '.*:\(.*\)')
+ # Build and eval the following:
+ # NEWENV=$OLDENV
+ evstr="$new=\$$old"
+ eval "$evstr"
+done
+export_them
+echo 'foo' | git-commit-tree $tree >/dev/null 2>errmsg
+sed -ne '/^warning: /p' <errmsg >generated-err
+test_debug 'cat errmsg'
+test_expect_success 'cmp generated-err /dev/null'
+
+test_done
Created: t/t0200-update-cache.sh (mode:100755)
--- /dev/null
+++ b/t/t0200-update-cache.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+. ./test-lib.sh
+test_description "$@" 'git-update-cache nonsense-path test.
+
+This test creates the following structure in the cache:
+
+ path0 - a file
+ path1 - a symlink
+ path2/file2 - a file in a directory
+ path3/file3 - a file in a directory
+
+and tries to git-update-cache --add the following:
+
+ path0/file0 - a file in a directory
+ path1/file1 - a file in a directory
+ path2 - a file
+ path3 - a symlink
+
+All of the attempts should fail.
+'
+
+mkdir path2 path3
+date >path0
+ln -s xyzzy path1
+date >path2/file2
+date >path3/file3
+
+git-update-cache --add -- path0 path1 path2/file2 path3/file3
+
+rm -fr path?
+
+mkdir path0 path1
+date >path2
+ln -s frotz path3
+date >path0/file0
+date >path1/file1
+
+for p in path0/file0 path1/file1 path2 path3
+do
+ test_expect_failure "git-update-cache --add -- $p"
+done
+test_done
^ permalink raw reply
* Re: [PATCH] [RFD] Add repoid identifier to commit
From: Thomas Gleixner @ 2005-05-12 7:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7vekcdmd16.fsf@assigned-by-dhcp.cox.net>
On Wed, 2005-05-11 at 18:46 -0700, Junio C Hamano wrote:
> >>>>> "TG" == Thomas Gleixner <tglx@linutronix.de> writes:
> So I am having a hard time understanding what problem repo-id
> solves.
Rn o
| \
Rn-1 o |
| o Mn
| o Mn-1
Rn-2 o /
Rn-3 o
rev-tree shows you
Rn
Rn-1
Mn
Mn-1
Rn-2
Rn-3
Which is wrong.
After syncing M to Rn you see the same thing in M
Rn
Rn-1
Mn
Mn-1
Rn-2
Rn-3
which is also wrong.
The correct display looking at R is
Rn
Mn
Mn-1
Rn-1
Rn-2
Rn-3
Looking from M it is
Rn
Rn-1
Rn-2
Mn
Mn-2
Rn-3
tglx
^ permalink raw reply
* Re: [PATCH Cogito] match pathnames in exclude handling
From: Matthias Urlichs @ 2005-05-12 7:54 UTC (permalink / raw)
To: H. Peter Anvin
Cc: David Mansfield, Jan-Benedict Glaw, Junio C Hamano, Brian Gerst,
git
In-Reply-To: <4282797A.5020001@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Hi,
H. Peter Anvin:
> How does that mean foo*.c would match foo/bar/quux.c? That's probably a
> bad thing.
>
No, of course not -- that was a thinko on my part when I typed the
examples. :-/
> I do like the (sadly, rarely used) convention that ** matches / whereas
> * doesn't.
>
fnmatch() doesn't support that. Of course, if there's demand for it,
it should be reasonably easy to have our own extended copy.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Support symlinks in git-ls-files --others.
From: Junio C Hamano @ 2005-05-12 7:48 UTC (permalink / raw)
To: pasky, Kay Sievers; +Cc: git
It is kind of surprising that this was missed in the last round,
but the work tree scanner in git-ls-files is still deliberately
ignoring symlinks. This patch fixes it.
This depends on the test suite infrastructure I sent in earlier.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Petr, I am not CCing Linus and you know what I mean by it ;-).
cache.h | 1 +
ls-files.c | 8 +++++---
t/t0400-ls-files.sh | 29 +++++++++++++++++++++++++++++
3 files changed, 35 insertions(+), 3 deletions(-)
t/t0400-ls-files.sh (. --> 100755)
--- a/cache.h
+++ b/cache.h
@@ -27,6 +27,7 @@
#define DT_UNKNOWN 0
#define DT_DIR 1
#define DT_REG 2
+#define DT_LNK 3
#define DTYPE(de) DT_UNKNOWN
#endif
--- a/ls-files.c
+++ b/ls-files.c
@@ -109,8 +109,9 @@
/*
* Read a directory tree. We currently ignore anything but
- * directories and regular files. That's because git doesn't
- * handle them at all yet. Maybe that will change some day.
+ * directories, regular files and symlinks. That's because git
+ * doesn't handle them at all yet. Maybe that will change some
+ * day.
*
* Also, we currently ignore all names starting with a dot.
* That likely will not change.
@@ -141,7 +142,7 @@
case DT_UNKNOWN:
if (lstat(fullname, &st))
continue;
- if (S_ISREG(st.st_mode))
+ if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode))
break;
if (!S_ISDIR(st.st_mode))
continue;
@@ -152,6 +153,7 @@
baselen + len + 1);
continue;
case DT_REG:
+ case DT_LNK:
break;
}
add_name(fullname, baselen + len);
--- a/t/t0400-ls-files.sh
+++ b/t/t0400-ls-files.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+. ./test-lib.sh
+test_description "$@" 'git-ls-files test.
+
+This test runs git-ls-files --others with the following on the
+filesystem.
+
+ path0 - a file
+ path1 - a symlink
+ path2/file2 - a file in a directory
+'
+
+date >path0
+ln -s xyzzy path1
+mkdir path2
+date >path2/file2
+git-ls-files --others >.output
+cat >.expected <<EOF
+path0
+path1
+path2/file2
+EOF
+
+test_expect_success 'diff .output .expected'
+test_done
------------------------------------------------
Compilation finished at Thu May 12 00:43:56
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: James Purser @ 2005-05-12 6:33 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.21.0505120137200.30848-100000@iabervon.org>
I've really got remember that reply to all option.
On Thu, 2005-05-12 at 15:46, Daniel Barkalow wrote:
> On Thu, 12 May 2005, James Purser wrote:
>
> > On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:
> > > If you think about it as git and cogito being entirely separate
projects,
> > > where users would be expected to have the right version of git
most of the
> > > time (or ever), this is true. But I think that cogito is as
closely tied
> > > to git as the kernel is to kbuild or kconfig; the difference is
that git
> > > is not solely available with cogito, like kbuild is solely
available with
> > > the kernel.
> > I tend to disagree with you on this point. Cogito and Git share
> > arelationship more akin to xorg and gnome and this is something I
think
> > Linus intended so that it would be very easy to build a layer on top
of
> > the git toolset. Cogito is great and it fills a need but give it
time
> > and other implementations and tool sets will come along that may
> > supersede it.
>
> The point of this feature is to support other implementations and tool
> sets. If there weren't other things using the git core, there would be
no
> reason to leave the current situation where cogito simply includes the
> complete contents of git-pb. The relationship between cogito and git
is,
> however, not at all like that between Gnome and x.org; gnome could not
be
> started until X was essentially completely stable for several years
(after
> which X could be reimplemented and extended, so long as it retained
the
> same API). Cogito, on the other hand, is being developed concurrently
with
> git, and substantially informs git development. The current cogito
doesn't
> work completely correctly with any mainline git, whereas the current
Gnome
> works with every x.org release as well as any XFree86 or most other X
> servers since the mid 90's.
>
> Also, any particular user is probably only going to use one git-based
> system, but will almost certainly use many different X clients.
>
> -Daniel
> *This .sig left intentionally blank*
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Okay the gnome/xorg is a bad example the point I was trying to get
across was that cogito and git are not as intertwined as you say, if
development of cogito stopped tomorrow then git would keep going and
another second layer app would take its place.
Yes cogito helps with git development as it provides a great way to test
different situations in a different environment than you would normally
get by running the bare git tools your self.
The way I have been reading things (and I may be wrong about this, it
wouldn't be the first time :)) is that git is THE base line providing
the necessary tools and structure for anyone who wishes to build an
application on top. Cogito is an example of that second layer app, built
on top of the toolset and still able to talk to non cogito managed
trees. Sort of like CVS and its various client implentations (Command
Line, GCVS etc).
Again I may have gotten things arse about, if I have then I blame lack
of sleep :)
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: Junio C Hamano @ 2005-05-12 6:28 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505120147100.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> My reasons for having it in the core are as follows:
DB> - All of the porcelain layers have to, at least, agree as
DB> to how this is represented in order for repositories to be
DB> portable; since the representation is common, it might as
DB> well be core.
That is weak. .git/refs/heads/master is not core, but something
Porcelain need to agree on [*1*].
DB> - There are currently no special files which are tracked for cogito (et
DB> al) to put the information in.
I am somewhat sympathetic to this, but then there are probably
lot other things that are more relevant than this "required
version" thing. One thing that immediately comes to mind is the
dontdiff list. Also, if you consider Cogito and GIT independent
projects as you said, you would probably need to have "require
{project-name} {commit-id}", not "include {commit-id}". Things
start smelling much more like the traditional package version
matching issue which is outside of SCM (let alone core GIT).
DB> - Ideally, the dependancy would only be per-commit, not
DB> per-tree; if Petr releases a new cogito which only merges a
DB> new mainline with the git-pb, the cogito tree object should
DB> be the same (since the cogito content didn't change). This
DB> means that it can't be anywhere other than the commit.
As I already said, I consider the current "overlayed" directory
structure broken and not worth considering the toolset support
[*2*].
DB> - If the solution to the issue of finding the necessary
DB> git-pb is to store it with cogito, then the programs that
DB> pull from this repository need to know that they need to
DB> pull the git-pb portion, and fsck-cache needs to know that
DB> the cogito references the git-pb.
I do not think this is necessary for the same reason as I
dismissed the third point above.
[Footnotes]
*1* I consider git-pull-script one example of Porcelain, JIT
knows about it as well.
*2* "Broken" is probably a too strong word here. I know Petr
did it that way because it was the simplest way to start, and I
started the same way when I started JIT, until I realized
separating the core and treating the core as something I can
borrow from the neighbouring directory is much easier to manage.
I think Petr knows this, and I further think that is why he
started git-pb.
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: Junio C Hamano @ 2005-05-12 6:14 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <7v8y2lknsp.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == Junio C Hamano <junkio@cox.net> writes:
Daniel, I am sorry but I realize I completely misunderstood what
you meant by "projects including other projects". What you are
trying to solve is the problem of feeding core GIT changes and
pure Cogito changes separately to the upstream _within_ _the_
_current_ _source_ _tree_ _structure_ of Cogito, isn't it?
That's where your juggling index files and other complexity
comes from, and I did not realize that was what you were talking
about. I should have realized it when you mentioned kbuild.
Well, personally I do not think such project _overlays_ are
worth supporting because it happens rarely, and to a certain
extent it is simply an undisciplined way to organize the source
tree. Kbuild case may be justified, but I vaguely recall
something very similar build infrastructure was used by busybox
folks---it could be using just their own copy of kbuild for that
matter.
But as you said in a separate message, I agree that core GIT
layer is meant to be independent from what Porcelain you put on
it. The relationship between Cogito and core GIT is not similar
to kbuild and the kernel. It is more like a random X11
application and Xlib. Having them in the same source tree,
intermixed, is less than optimal.
I would not be surprised when future, if not the next, Cogito
release has source tree organized more like JIT sources,
shipping git-pb and cogito in separate directories, managed by
separate GIT_DIR. That would make Pasky's life a lot simpler.
And once the separation happens, the issue becomes just a simple
package version matching every distribution does (e.g. Debian's
binary package and library dependencies, or source Build-Depends
dependencies), which is something already has been solved.
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: Daniel Barkalow @ 2005-05-12 6:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <7v8y2lknsp.fsf@assigned-by-dhcp.cox.net>
On Wed, 11 May 2005, Junio C Hamano wrote:
> I do not think the issues you are raising are solved by having
> that "include {hash}" thing in the commit like you propose here,
> instead of keeping it outside of the commit like I suggested.
>
> What I meant to say was just I do not think having this "version
> dependency" in the core or outside of the core would make any
> difference.
I was primarily responding to your idea of it being outside the scope of
cogito as well as outside the core.
My reasons for having it in the core are as follows:
- All of the porcelain layers have to, at least, agree as to how this is
represented in order for repositories to be portable; since the
representation is common, it might as well be core.
- There are currently no special files which are tracked for cogito (et
al) to put the information in.
- Ideally, the dependancy would only be per-commit, not per-tree; if Petr
releases a new cogito which only merges a new mainline with the git-pb,
the cogito tree object should be the same (since the cogito content
didn't change). This means that it can't be anywhere other than the
commit.
- If the solution to the issue of finding the necessary git-pb is to
store it with cogito, then the programs that pull from this repository
need to know that they need to pull the git-pb portion, and fsck-cache
needs to know that the cogito references the git-pb.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: Daniel Barkalow @ 2005-05-12 5:46 UTC (permalink / raw)
To: James Purser; +Cc: Junio C Hamano, git, Petr Baudis, Linus Torvalds
In-Reply-To: <1115876231.3085.4.camel@kryten>
On Thu, 12 May 2005, James Purser wrote:
> On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:
> > If you think about it as git and cogito being entirely separate projects,
> > where users would be expected to have the right version of git most of the
> > time (or ever), this is true. But I think that cogito is as closely tied
> > to git as the kernel is to kbuild or kconfig; the difference is that git
> > is not solely available with cogito, like kbuild is solely available with
> > the kernel.
> I tend to disagree with you on this point. Cogito and Git share
> arelationship more akin to xorg and gnome and this is something I think
> Linus intended so that it would be very easy to build a layer on top of
> the git toolset. Cogito is great and it fills a need but give it time
> and other implementations and tool sets will come along that may
> supersede it.
The point of this feature is to support other implementations and tool
sets. If there weren't other things using the git core, there would be no
reason to leave the current situation where cogito simply includes the
complete contents of git-pb. The relationship between cogito and git is,
however, not at all like that between Gnome and x.org; gnome could not be
started until X was essentially completely stable for several years (after
which X could be reimplemented and extended, so long as it retained the
same API). Cogito, on the other hand, is being developed concurrently with
git, and substantially informs git development. The current cogito doesn't
work completely correctly with any mainline git, whereas the current Gnome
works with every x.org release as well as any XFree86 or most other X
servers since the mid 90's.
Also, any particular user is probably only going to use one git-based
system, but will almost certainly use many different X clients.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: Junio C Hamano @ 2005-05-12 5:37 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505120057250.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> When a particular cogito commit is made, it is impossible to tell whether
DB> the next git-pb will work with it; the current set of patches could be
DB> rejected in mainline git, and different support for the same functionality
DB> added which requires something different from cogito...
... Many problems with the approach of saying "this Cogito
requires this git-pb" omitted here; I agree that alone
may not solve problems ...
DB> I think your idea is theoretically possible, but that it is just too
DB> impractical...
I do not think it is my idea. Maybe I misunderstood what you
meant, but here is what you wrote in the message I responded to.
... There is a bit of convenience to having the tools magically
do the right thing when you check out the child project, but the
thing that really requires tool support is that you need to be
able to find the version of git-pb which matches the version of
cogito you're trying to build (and you might be searching the
history for where a bug was introduced, so you may not be able
to use the latest of either).
That part is fine. I already agreed that recording such version
dependency would be a good thing. I disagreed with the
"solution", however, of having that recorded at the core level:
The solution is to add a header to commits: "include {hash}",
which simply says that the given hash, which is from the core
project, is the commit needed to build this commit of the
non-core project. This comes from an argument to commit-tree
("-I", perhaps), and the parsing code needs to identify the
reference so that fsck-cache stays happy.
I do not think the issues you are raising are solved by having
that "include {hash}" thing in the commit like you propose here,
instead of keeping it outside of the commit like I suggested.
What I meant to say was just I do not think having this "version
dependency" in the core or outside of the core would make any
difference.
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: James Purser @ 2005-05-12 5:37 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, Petr Baudis, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505120057250.30848-100000@iabervon.org>
On Thu, 2005-05-12 at 15:19, Daniel Barkalow wrote:
> If you think about it as git and cogito being entirely separate projects,
> where users would be expected to have the right version of git most of the
> time (or ever), this is true. But I think that cogito is as closely tied
> to git as the kernel is to kbuild or kconfig; the difference is that git
> is not solely available with cogito, like kbuild is solely available with
> the kernel.
I tend to disagree with you on this point. Cogito and Git share
arelationship more akin to xorg and gnome and this is something I think
Linus intended so that it would be very easy to build a layer on top of
the git toolset. Cogito is great and it fills a need but give it time
and other implementations and tool sets will come along that may
supersede it.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: Daniel Barkalow @ 2005-05-12 5:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <7vk6m5kpue.fsf@assigned-by-dhcp.cox.net>
On Wed, 11 May 2005, Junio C Hamano wrote:
> I think that the core of your idea of recording "required
> version" of the depended project (core GIT) in the depending
> project (Cogito) is a very sound one. GNU Arch folks do
> something similar in their "package-framework" stuff.
>
> I however do not think that belongs to the core GIT nor even to
> Cogito for that matter. To me, it feels like this is a pure
> build infrastructure issue.
If you think about it as git and cogito being entirely separate projects,
where users would be expected to have the right version of git most of the
time (or ever), this is true. But I think that cogito is as closely tied
to git as the kernel is to kbuild or kconfig; the difference is that git
is not solely available with cogito, like kbuild is solely available with
the kernel.
> I think you could arrange something like that with today's core
> GIT tools, like this:
>
> - Tweak Cogito Makefile so that pure Cogito and core GIT are
> housed in separate subdirectories;
>
> - Add "required-git-pb" file to Cogito source as a tracked
> source file, and record the required version of git-pb there;
>
> - Arrange Cogito Makefile to make sure the subtree that has the
> core GIT side meets "required-git-pb" constraints. The
> constraints could be "at least contains this one", "exactly
> this one". The policy would be differnt from a depending
> project to another. What happens if the requirements are not
> met is also up to the policy of that depending project.
When a particular cogito commit is made, it is impossible to tell whether
the next git-pb will work with it; the current set of patches could be
rejected in mainline git, and different support for the same functionality
added which requires something different from cogito.
This also means that Petr can't really test changes to git before
commiting them (and a new cogito with the constraint changed), because the
cogito build system would then require him to use a version he's not
testing.
Also, either the user has to keep track of two projects without any system
support in the same directory structure and figure out how to follow the
instructions from the build system in getting the right version checked
out in the right place, or the build system is tied to a particular
wrapper layer.
I think your idea is theoretically possible, but that it is just too
impractical for anyone to ever actually use it. It's something that people
could do with CVS (and it would actually work better, due to CVS's
limitations making the issues simpler), but people don't.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Support projects including other projects
From: Junio C Hamano @ 2005-05-12 4:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505112350420.30848-100000@iabervon.org>
I think that the core of your idea of recording "required
version" of the depended project (core GIT) in the depending
project (Cogito) is a very sound one. GNU Arch folks do
something similar in their "package-framework" stuff.
I however do not think that belongs to the core GIT nor even to
Cogito for that matter. To me, it feels like this is a pure
build infrastructure issue.
I think you could arrange something like that with today's core
GIT tools, like this:
- Tweak Cogito Makefile so that pure Cogito and core GIT are
housed in separate subdirectories;
- Add "required-git-pb" file to Cogito source as a tracked
source file, and record the required version of git-pb there;
- Arrange Cogito Makefile to make sure the subtree that has the
core GIT side meets "required-git-pb" constraints. The
constraints could be "at least contains this one", "exactly
this one". The policy would be differnt from a depending
project to another. What happens if the requirements are not
met is also up to the policy of that depending project.
^ permalink raw reply
* Re: [PATCH] improved delta support for git
From: Junio C Hamano @ 2005-05-12 4:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0505112309480.5426@localhost.localdomain>
The changes to sha1_file interface seems to be contained to
read_sha1_file() only; which is a very good sign. You have
already expressed that you are aware that fsck-cache needs to be
taught about the delta objects, so I'd trust that would be what
you will be tackling next.
I started wondering how the delta chains would affect pull.c,
the engine that decides which files under GIT_OBJECT_DIRECTORY
need to be pulled from the remote side in order to construct the
set of objects needed by the given commit ID, under various
combinations of cut-off criteria given with -c, -t, and -a
options.
It appears to me that changes to the make_sure_we_have_it()
routine along the following lines (completely untested) would
suffice. Instead of just returning success, we first fetch the
named object from the remote side, read it to see if it is
really the object we have asked, or just a delta, and if it is a
delta call itself again on the underlying object that delta
object depends upon.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
# - git-pb: Fixed a leak in read-tree
# + (working tree)
--- a/pull.c
+++ b/pull.c
@@ -32,11 +32,23 @@ static void report_missing(const char *w
static int make_sure_we_have_it(const char *what, unsigned char *sha1)
{
int status;
+ unsigned long mapsize;
+ void *map, *buf;
+
if (has_sha1_file(sha1))
return 0;
status = fetch(sha1);
if (status && what)
report_missing(what, sha1);
+
+ map = map_sha1_file(sha1, &mapsize);
+ if (map) {
+ buf = unpack_sha1_file(map, mapsize, type, size);
+ munmap(map, mapsize);
+ if (buf && !strcmp(type, "delta"))
+ status = make_sure_we_have_it(what, buf);
+ free(buf);
+ }
return status;
}
^ permalink raw reply
* [RFC] Support projects including other projects
From: Daniel Barkalow @ 2005-05-12 4:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Petr Baudis, Linus Torvalds
I've come up with a way to handle projects like cogito which are based on
other projects. I think that it actually solves the real problem with such
projects, and it is actually very simple.
The problem that such projects run into, especially while both the core
and the non-core projects are in a state of substantial flux and when the
non-core developer(s) contribute needed changes to the core, is that the
two projects not only have to be tracked, they have to be kept in
sync. That is, a particular version of cogito requires a particular
version of git. There is a bit of convenience to having the tools
magically do the right thing when you check out the child project, but the
thing that really requires tool support is that you need to be able to
find the version of git-pb which matches the version of cogito you're
trying to build (and you might be searching the history for where a bug
was introduced, so you may not be able to use the latest of either).
The solution is to add a header to commits: "include {hash}", which simply
says that the given hash, which is from the core project, is the commit
needed to build this commit of the non-core project. This comes from an
argument to commit-tree ("-I", perhaps), and the parsing code needs to
identify the reference so that fsck-cache stays happy.
Git doesn't do anything more; wrapping layers would be able to take care
of the rest. When the wrapping layer determines that you are checking out
a commit with an include header, it also checks out the included commit,
using a different index file. The core treats everything as if you had a
bunch of non-tracked files in the directory (those being the things in the
other project). When you commit, it first commits any includes (if
needed), identifies the resulting core head, and passes that to the
include for the final result.
It seems to me like this should work perfectly. The one weakness is that
it's quite annoying to do by hand, since you have to simultaneously track
two index files and remember to pass the argument to commit-tree each
time. (Also, it means that you'd ideally pull git-pb from the cogito
repository with a client that ignores things not reachable from your head,
although Petr could still just copy and prune to match the current
situation).
I've written up the git changes needed, if people are interested in the
patch.
-Daniel
*This .sig left intentionally blank*
^ 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