Re: Re-done kernel archive - real one?
On Tue, Apr 19, 2005 at 01:09:42AM +0200, Petr Baudis wrote: Essentially, with BK, at 7am localtime each morning, I'd: - update my baseline linux 2.6 tree - for each working tree which may be pulled from - if the baseline is a superset - update working tree from baseline The net result is that my workflow consisted entirely of: 1. commit whatever into working tree 2. test 3. send linus a pull request 4. repeat next day The tree resynchronisation happened completely and entirely in the background with no user intervention required at all. And in the case of conflicts...? If the baseline is a superset of the working tree, there will never be any conflicts. Note that as I said above, this is a condition on doing the pull in the first place. How we determine that with git is another matter though. 8) -- Russell King - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCM ideas from 2003
KS == Kevin Smith [EMAIL PROTECTED] writes: KS what's so special about files ? where the author suggests that KS existing SCM systems are so blinded by the tradition of file KS orientation that they can't see that there might be alternatives. Correct: file orientation is eventually a limitation. But there are other dimensions to investigate in order to overcome it. The issue is to offer a *location* for the possible versions -- not only sequential changes but also alternatives. A directory may be considered as a namespace. Note that there are other cases of 'containers': archives, packages, libraries, etc... -- Marc GirodP.O. Box 323Voice: +358-71 80 25581 Nokia BI 00045 NOKIA Group Mobile: +358-50 38 78415 Valimo 21 / B616 Finland Fax:+358-71 80 64474 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: True git merge in git-pasky
Dear diary, on Tue, Apr 19, 2005 at 07:43:07AM CEST, I got a letter where bert hubert [EMAIL PROTECTED] told me that... On Tue, Apr 19, 2005 at 05:51:07AM +0200, Petr Baudis wrote: http://pasky.or.cz/~pasky/dev/git I pulled the tar.bz2 and did make: gcc -g -O3 -Wall -o merge-cache merge-cache.o libgit.a libgit.a -lssl -lz gcc -g -O3 -Wall -c -o unpack-file.o unpack-file.c gcc -g -O3 -Wall -o unpack-file unpack-file.o libgit.a libgit.a -lssl -lz make: commit-id: Command not found Generating gitversion.sh... Is this bad? It will cause a 40-digit hexadecimal number missing in your git help and git version output. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
Aye, that will require some metadata on the git side (the hack, suggested by Linus, of using git hashes to notice moves won't work). So, why won't it work? Because two files can legitimately have identical contents without being ``the same'' file from the VC system's point of view. In other words, two files may happen to have the same contents but have distinct histories. Juliusz - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More git pull problems
Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... My automatic pull this morning produced the following messages, which seem to indicate that something's up with git pull now. git-pasky-0.4 (7bef49b5d53218ed3fa8bac291b5515c6479810c) New branch: 945a2562ee9e632bc6b3399fd49e028c39d19023 Tracked branch, applying changes... Fast-forwarding 945a2562ee9e632bc6b3399fd49e028c39d19023 - 945a2562ee9e632bc6b3399fd49e028c39d19023 on top of 945a2562ee9e632bc6b3399fd49e028c39d19023... gitdiff.sh: trying to diff 67607f05a66e36b2f038c77cfb61350d2110f7e8 against itself This means nothing more than you pulled your tracked branch for the first time, but before you already had the latest copy; this wouldn't have happened with subsequent pulls, and it was fixed some time ago - it would be really nice if you could try the new pull and merge. It is harmless anyway. It got confused and tried to do zero-length fast forward, which git diff complained about, but it couldn't do any harm (I hope). -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: More git pull problems
On Tue, Apr 19, 2005 at 10:23:41AM +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter where Russell King [EMAIL PROTECTED] told me that... My automatic pull this morning produced the following messages, which seem to indicate that something's up with git pull now. git-pasky-0.4 (7bef49b5d53218ed3fa8bac291b5515c6479810c) New branch: 945a2562ee9e632bc6b3399fd49e028c39d19023 Tracked branch, applying changes... Fast-forwarding 945a2562ee9e632bc6b3399fd49e028c39d19023 - 945a2562ee9e632bc6b3399fd49e028c39d19023 on top of 945a2562ee9e632bc6b3399fd49e028c39d19023... gitdiff.sh: trying to diff 67607f05a66e36b2f038c77cfb61350d2110f7e8 against itself This means nothing more than you pulled your tracked branch for the first time, but before you already had the latest copy; this wouldn't have happened with subsequent pulls, and it was fixed some time ago - it would be really nice if you could try the new pull and merge. That's not the case. This tree has been sitting around for about 6 days now, and every day at 7am it gets a git pull. One thing which did change was the version of git installed, which now has this fast forwarding feature in. Maybe gitmerge.sh should check whether it needs to do anything before attempting to do something? -- Russell King - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: full kernel history, in patchset format
David Mansfield [EMAIL PROTECTED] wrote: Catalin Marinas wrote: AFAIK, cvsps uses the date/time to create the changesets. There is a problem with the BKCVS export since some files in the same commit can have a different time (by an hour). I posted a mail some time ago about this - http://marc.theaimsgroup.com/?l=linux-kernelm=110026570201544w=2 I read that the old history won't be merged into the new repository but, if you are interested, I have a script that can do this based on the (Logical change ...) string in the file commit logs and it is quite fast at generating the patches. Hmmm. I read that message just now. Is it a matter of 'perfection' that is the issue here, or actual correctness when applying the patches in order? I see it as a matter of correctness since in a given BKCVS changeset (i.e. revision in the ChangeSet,v file) you may miss files. You would eventually get them, with the same log, but in a different patch. If you don't care about this, you can call it 'perfection'. At that time I thought about modifying cvsps to use the (Logical change ...) string instead of time/date for grouping the files but I realised it is easier with a shell script. (perhaps this has now been fixed). There was no reply to this e-mail. It might have been fixed in the meantime but I don't think the history was fixed as well. -- Catalin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
Hi all, I'm working on an OO perl alternative to Petr's git scripts, which I'm currently calling yogi (your other git interface). While I'm not ready to release that just yet, I wanted to start floating some patches to the core plumbing to support the respective packages' potentially divergent demands. For those die-hard perl hackers, I can float you a copy of the package off-list if you're interested; I'm hoping to finish a public 0.0.1 release by the end of the week. The first two patches in the series are already in the pasky.git repository, but Linus hasn't merged them yet. The are included only because the next few patches expect them to be in place. The third patch in the series prepares for the forth patch by factoring the object directory detection and creation functionality. The fifth patch makes one final pass at cleaning up init-db. The 3rd and 5th patches aren't particularly valuable unless the remaining patches are also applied, but they do make the code a bit prettier. To me, at least. The remaining patches (4,6,7,8) add the ability for the '.git' index directory to be overridden in the same manner as the object directory. This allows me to create my own independent '.yogi' trees, the very notion of which may cause this whole series to be henceforth flamed into oblivion. Here's to hoping otherwise Cheers, Zach Welch Superlucidity Services These patches are based off commit 5b53d3a08d64198d26d4f2323f235790c04aeaab. There are 8 patches in this series: [PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call [PATCH 2/8] init-db.c: [RESEND] make init-db work with common objects [PATCH 3/8] init-db.c: refactor directory creation [PATCH 4/8] init-db.c: add INDEX_FILE_DIRECTORY support [PATCH 5/8] init-db.c: refactor mkdir logic [PATCH 6/8] read-cache.c: add INDEX_FILE_DIRECTORY support [PATCH 7/8] read-tree.c: add INDEX_FILE_DIRECTORY support [PATCH 8/8] update-cache.c: add INDEX_FILE_DIRECTORY support - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
init-db calls getenv(DB_ENVIRONMENT) twice. Once should be enough.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
init-db.c |3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Signed-Off-By: Tony Luck [EMAIL PROTECTED]
--- a/init-db.c 2005-04-14 11:01:52.0 -0700
+++ b/init-db.c 2005-04-14 11:01:52.0 -0700
@@ -7,7 +7,7 @@
int main(int argc, char **argv)
{
- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
+ char *sha1_dir, *path;
int len, i;
if (mkdir(.git, 0755) 0) {
-
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] init-db.c: refactor directory creation
This patch factors the init-db directory creation into a new function,
which is then reused in the next patch.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
[PATCH 2/8] init-db.c: [RESEND] make init-db work with common objects
init-db.c | 61 ---
1 files changed, 34 insertions(+), 27 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
--- a/init-db.c
+++ b/init-db.c
@@ -4,43 +4,50 @@
* Copyright (C) Linus Torvalds, 2005
*/
#include cache.h
+/*
+ * If you want to, you can share the DB area with any number of branches.
+ * That has advantages: you can save space by sharing all the SHA1 objects.
+ * On the other hand, it might just make lookup slower and messier. You
+ * be the judge. The default case is to have a DB per managed directory.
+ */
+
+static char* init_dir(char *env, char *std, char *label, int *len)
+{
+ char *dir;
+ dir = getenv(env);
+ if (dir) {
+ struct stat st;
+ if (stat(dir, st) 0 || !S_ISDIR(st.st_mode)) {
+ fprintf(stderr, %s set to bad directory %s: , env,
dir);
+ exit(1);
+ }
+ }
+ else {
+ dir = std;
+ fprintf(stderr, defaulting to private %s area\n, label);
+ }
+ if (mkdir(dir, 0755) 0) {
+ if (errno != EEXIST) {
+ perror(dir);
+ exit(1);
+ }
+ }
+ if (len)
+ *len = strlen(dir);
+ return dir;
+}
int main(int argc, char **argv)
{
char *sha1_dir, *path;
int len, i;
if (mkdir(.git, 0755) 0) {
perror(unable to create .git directory);
exit(1);
}
-
- /*
-* If you want to, you can share the DB area with any number of
branches.
-* That has advantages: you can save space by sharing all the SHA1
objects.
-* On the other hand, it might just make lookup slower and messier. You
-* be the judge.
-*/
- sha1_dir = getenv(DB_ENVIRONMENT);
- if (sha1_dir) {
- struct stat st;
- if (!stat(sha1_dir, st) S_ISDIR(st.st_mode))
- return 0;
- fprintf(stderr, DB_ENVIRONMENT set to bad directory %s: ,
sha1_dir);
- }
-
- /*
-* The default case is to have a DB per managed directory.
-*/
- sha1_dir = DEFAULT_DB_ENVIRONMENT;
- fprintf(stderr, defaulting to private storage area\n);
- len = strlen(sha1_dir);
- if (mkdir(sha1_dir, 0755) 0) {
- if (errno != EEXIST) {
- perror(sha1_dir);
- exit(1);
- }
- }
+ sha1_dir = init_dir(DB_ENVIRONMENT, DEFAULT_DB_ENVIRONMENT, storage,
len);
+
path = malloc(len + 40);
memcpy(path, sha1_dir, len);
for (i = 0; i 256; i++) {
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] init-db.c: add INDEX_FILE_DIRECTORY support
This patch give init-db the ability for the index directory to be
overridden by the INDEX_FILE_DIRECTORY environment variable.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
[PATCH 2/8] init-db.c: [RESEND] make init-db work with common objects
[PATCH 3/8] init-db.c: refactor directory creation
cache.h |3 +++
init-db.c |5 +
2 files changed, 4 insertions(+), 4 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
--- a/cache.h 2005-04-18 21:13:36.0 -0700
+++ b/cache.h 2005-04-18 21:13:44.0 -0700
@@ -81,6 +81,9 @@
struct cache_entry **active_cache;
unsigned int active_nr, active_alloc;
+#define INDEX_ENVIRONMENT INDEX_FILE_DIRECTORY
+#define DEFAULT_INDEX_ENVIRONMENT .git
+
#define DB_ENVIRONMENT SHA1_FILE_DIRECTORY
#define DEFAULT_DB_ENVIRONMENT .git/objects
--- a/init-db.c 2005-04-18 21:21:02.0 -0700
+++ b/init-db.c 2005-04-18 21:15:14.0 -0700
@@ -42,10 +42,7 @@
char *sha1_dir, *path;
int len, i;
- if (mkdir(.git, 0755) 0) {
- perror(unable to create .git directory);
- exit(1);
- }
+ (void) init_dir(INDEX_ENVIRONMENT, DEFAULT_INDEX_ENVIRONMENT, index,
NULL);
sha1_dir = init_dir(DB_ENVIRONMENT, DEFAULT_DB_ENVIRONMENT, storage,
len);
path = malloc(len + 40);
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] init-db.c: refactor mkdir logic
Move redundant mkdir call logic into helper function.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
[PATCH 2/8] init-db.c: [RESEND] make init-db work with common objects
[PATCH 3/8] init-db.c: refactor directory creation
[PATCH 4/8] init-db.c: add INDEX_FILE_DIRECTORY support
init-db.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
--- a/init-db.c 2005-04-19 01:36:58.0 -0700
+++ b/init-db.c 2005-04-19 01:37:03.0 -0700
@@ -11,6 +11,16 @@
* be the judge. The default case is to have a DB per managed directory.
*/
+static void create_dir(char *path)
+{
+ if (mkdir(dir, 0755) 0) {
+ if (errno != EEXIST) {
+ perror(dir);
+ exit(1);
+ }
+ }
+}
+
static char* init_dir(char *env, char *std, char *label, int *len)
{
char *dir;
@@ -26,12 +36,7 @@
dir = std;
fprintf(stderr, defaulting to private %s area\n, label);
}
- if (mkdir(dir, 0755) 0) {
- if (errno != EEXIST) {
- perror(dir);
- exit(1);
- }
- }
+ create_dir(dir);
if (len)
*len = strlen(dir);
return dir;
@@ -49,12 +54,7 @@
memcpy(path, sha1_dir, len);
for (i = 0; i 256; i++) {
sprintf(path+len, /%02x, i);
- if (mkdir(path, 0755) 0) {
- if (errno != EEXIST) {
- perror(path);
- exit(1);
- }
- }
+ create_dir(path);
}
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] read-tree.c: add INDEX_FILE_DIRECTORY support
This patch give read-tree the ability for the index directory to be
overridden by the INDEX_FILE_DIRECTORY environment variable.
This patch applies on top of:
[PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
[PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
[PATCH 2/8] init-db.c: [RESEND] make init-db work with common objects
[PATCH 3/8] init-db.c: refactor directory creation
[PATCH 4/8] init-db.c: add INDEX_FILE_DIRECTORY support
[PATCH 5/8] init-db.c: refactor mkdir logic
[PATCH 6/8] read-cache.c: add INDEX_FILE_DIRECTORY support
read-tree.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
read-tree.c: 42556c82def1d23f21116a2c1b3e7ae27c0605c5
--- a/read-tree.c
+++ b/read-tree.c
@@ -65,12 +65,12 @@ static int read_tree(unsigned char *sha1
return 0;
}
-static int remove_lock = 0;
+static char *index_lock = NULL;
static void remove_lock_file(void)
{
- if (remove_lock)
- unlink(.git/index.lock);
+ if (index_lock)
+ unlink(index_lock);
}
static int same(struct cache_entry *a, struct cache_entry *b)
@@ -154,14 +154,27 @@ static void trivially_merge_cache(struct
int main(int argc, char **argv)
{
- int i, newfd;
+ int i, newfd, len;
unsigned char sha1[20];
+ char *index_file, *index_path;
- newfd = open(.git/index.lock, O_RDWR | O_CREAT | O_EXCL, 0600);
+ index_path = getenv(INDEX_ENVIRONMENT);
+ if (!index_path)
+ index_path = DEFAULT_INDEX_ENVIRONMENT;
+
+ len = strlen(index_path);
+ index_file = malloc(len + 7);
+ if (!index_file) error(out of memory);
+ sprintf(index_file, %s/index, index_path);
+
+ index_lock = malloc(len + 12);
+ if (!index_lock) error(out of memory);
+ sprintf(index_lock, %s/index.lock, index_path);
+
+ newfd = open(index_lock, O_RDWR | O_CREAT | O_EXCL, 0600);
if (newfd 0)
die(unable to create new cachefile);
atexit(remove_lock_file);
- remove_lock = 1;
for (i = 1; i argc; i++) {
const char *arg = argv[i];
@@ -182,8 +195,12 @@ int main(int argc, char **argv)
if (stage == 4)
trivially_merge_cache(active_cache, active_nr);
if (write_cache(newfd, active_cache, active_nr) ||
- rename(.git/index.lock, .git/index))
+ rename(index_lock, index_file))
die(unable to write new index file);
- remove_lock = 0;
+
+ free(index_file);
+ free(index_lock);
+ index_lock = NULL;
+
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
David A. Wheeler wrote: I propose changing pull to ONLY download, and update to pull AND merge. Why? It seems oddly inconsistent that pull sometimes merges in changes, but at other times it doesn't. true I propose that there be two subcommands, pull and update (now that update isn't a reserved word again). A git pull ONLY downloads; a git update pulls AND merges. What's the most common thing to do? pull or update? which is easier to type? what are people used to? I'm not sure but I suggest that pull and get would be better choices. git pull git get is it rare enough to justify: git --download-only pull David -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
On Mon, Apr 18, 2005 at 08:38:25AM -0700, Linus Torvalds wrote: On Mon, 18 Apr 2005, David Roundy wrote: In particular, it would make life (that is, life interacting back and forth with git) easier if we were to embed darcs patches in their entirety in the git comment block. Hell no. I was afraid that would be the response... The commit _does_ specify the patch uniquely and exactly, so I really don't see the point. You can always get the patch by just doing a git diff $parent_tree $thistree so putting the patch in the comment is not an option. The issue is that in darcs the parent and child trees *don't* uniquely or exactly specify the patch. In fact, even the output of git diff will depend on what version of diff you're using (e.g. if someone were to use BSD diff rather than GNU diff). As I say, it's a bit ugly, and before we explore the idea further, it would be nice to know if this would cause Linus to vomit in disgust and/or refuse patches from darcs users. That's definitely the case. I will _not_ be taking random files etc just to keep other peoples stuff straightened up. Okay. Another slightly less noxious possibility would be to store the darcs patch as a hidden file, if git were given the concept of commit-specific files. No, git will not track commit-specific files. There's the comment section, and that _is_ the commit-specific file. But I will refuse to take any comments that aren't just human-readable explanations, together with maybe one extra line of # Darcs ID: 780c057447d4feef015a905aaf6c87db894ff58c (others will want to track _their_ PR numbers etc) and that's it. The actual darcs data that that ID refers to can obviously be maintained in _another_ git archive, but it's not one I'm going to carry about. The trouble is that the philosophy of darcs and git are about as orthogonal as one can come. Git treats the content as fundamental, where in darcs the changes are fundamental. Since in darcs there can be different changes that lead from the same parent to the same child--and these differences are meaningful when merges happen---when interacting with git, we either need to restrict darcs to only describe changes in a way that can be uniquely determined by a parent and child, or we need to have extra metadata somewhere. For bidirectional functionality, we either need to avoid the use of advanced darcs features, or we need to include that information in git somehow, or we need to keep a parallel darcs archive holding that information. Would a small amount of human-readable change information be acceptable in the free-form comment area? In the rename thread I got the impression this would be okay for renames. For example, rename foo bar or (this is less important, but you might consider it to be a useful human-readable comment) replace [_a-zA-Z0-9] old_variable new_variable file/path Currently these two patch types account for almost the sum total of the cases where different patches lead to the same resulting trees. -- David Roundy - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter where Martin Schlemmer [EMAIL PROTECTED] told me that... On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter where David Greaves [EMAIL PROTECTED] told me that... Dunno. I do it personally all the time, with git at least. What do others think? :-) I think pull is pull. If you are doing lots of local stuff and do not want it overwritten, it should have been in a forked branch. I disagree. This already forces you to have two branches (one to pull from to get the data, mirroring the remote branch, one for your real work) uselessly and needlessly. I think there is just no good name for what pull is doing now, and update seems like a great name for what pull-and-merge really is. Pull really is pull - it _pulls_ the data, while update also updates the given tree. No surprises. (We should obviously have also update-without-pull but that is probably not going to be so common so a parameter for update (like -n) should be fine for that.) These naming issues may appear silly but I think they matter big time for usability, intuitiveness, and learning curve (I don't want git-pasky become another GNU arch). Kind regards, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
On Tue, Apr 19, 2005 at 02:55:05AM +0200, Juliusz Chroboczek wrote: [Using git as a backend for Darcs.] ... 1. remove the assumption that patch IDs have a fixed format. Patch IDs should be opaque blobs of binary data that Darcs only compares for equality. I'm not really comfortable with this, Why? I'm not clear why it would be necesary, and it takes the only immutable piece of information regarding a patch, and makes it variable. Just seems dangerous and complicated, and I'm not sure why we'd need to do it. Suppose I record a patch in Darcs; it gets a Darcs id. I push it into git, at which point it gets a git id, whether we want it to or not. What do we do when we pull that patch back into darcs? Either we arbitrarily discard one of the ids (which one?), or we keep both. If there's more pulling/pushing going on on the git side, we definitely need to keep both. Or alternatively, we could have a one-to-one mapping between git IDs and darcs IDs, which is what I'd do. I think when dealing with git (and probably also with *any* other SCM (arch being a possible exception), we need to consider the exchange medium to be not a patch, but a tag. We're thinking in opposite directions -- you're thinking of the alien versions as integrals of Darcs patches, I'm thinking of Darcs patches as derivatives of alien versions. You: alien version = Darcs tag Me: Darcs patch = pair of successive alien versions My gut instinct is that the second model can be made to work almost seamlessly, unlike the first one. But that's just a guess. The problem is that there is no sequence of alien versions that one can differentiate. Git has a branched history, with each version that follows a merge having multiple parents. How do you define that change? It's easy enough to do if we tag each git version in darcs, since we know what the two parents are, and we know what the final state is, but there *is* no translation from a single git ID either to a single patch(1) patch, or to a single darcs patch--unless you treat its parents as tags. The key is that we can't make git work like darcs, so we'll have to make darcs work like git. If we do it right (automatically tagging like crazy people), darcs users between themselves can cherry-pick all they like, without introducing inconsistencies or losing interoperability with git. To summarize how I'd see the mapping between git information and darcs, a git commit would be composed of one darcs patch and one darcs tag. With this mapping, I don't believe we lose any information, and I believe we'll be able to (except that patches would have to be uniquely determined by a pair of trees) simply translate the darcs system right back again, since it's a one-to-one correspondence of information. My proposed mapping: tree 6ff0e9f3d131bd110d32829f0b14f07da8313c45 # This is a darcs tag ID parent abd62b9caee377595a9bf75f363328c82a38f86e # This is the context of both a patch and tag. author James Bottomley [EMAIL PROTECTED] 1113879319 -0700 # This is the author and date of the patch committer Linus Torvalds [EMAIL PROTECTED](none) 1113879319 -0700 # This is the author and date of the tag # Everything below would be the name and long comment of the patch [PATCH] SCSI trees, merges and git status Doing the latest SCSI merge exposed two bugs in your merge script: 1) It doesn't like a completely new directory (the misc tree contains a new drivers/scsi/lpfc) 2) the merge testing logic is wrong. You only want to exit 1 if the merge fails. -- David Roundy http://www.darcs.net - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
On Mon, Apr 18, 2005 at 06:42:11PM -0700, Ray Lee wrote: On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote: You could guess, but that's not good enough for darcs to be able to reliably commute the patches later. Who said anything about guessing? If a user replaces all instances of foo with bar, that's as close to proof as you can ever get, without recording intent of the user at the time it's done. Now, I realize that darcs *does* record intent, but I claim that's immaterial. The problem is, how do you know how to define a token? That's also included in a darcs patch. And a darcs user may choose not to use a replace patch, if (for example) he's renaming a local variable, since he might not want to mess with other functions in the same file. Guessing the author's intent cannot reliably reproduce the author's stated intent. Either we need to include that information in one form or another (and in one location or another), or we've got to simply disallow replaces (and moves?) when interacting with git. -- David Roundy http://www.darcs.net - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
[Removing Linus from CC, keeping the Git list -- or should we remove it?] I'm not clear why it would be necesary, and it takes the only immutable piece of information regarding a patch, and makes it variable. Er... I'm not suggesting to make it variable, just to make it an opaque blob of bytes (still immutable). I see from the examples you give below that you agree that the format needs extending, so I suspect we're actually agreeing here, just failing to communicate. about having multiple ids per patch: Or alternatively, we could have a one-to-one mapping between git IDs and darcs IDs, which is what I'd do. Okay, you've convinced me. It's much simpler that way, we'll see how well it works. The problem is that there is no sequence of alien versions that one can differentiate. Git has a branched history, with each version that follows a merge having multiple parents. Yep. I've just realised that this morning. Is there some notion of ``primary parent'' as in Arch? Can a changeset have 0 parents? If we do it right (automatically tagging like crazy people), darcs users between themselves can cherry-pick all they like, without introducing inconsistencies or losing interoperability with git. You've lost me here. How can you cherry-pick if every tag depends on the preceding patches? Or are you thinking of pulling just the patch and not the tag -- in that case, what happens when you push to git a Darcs patch that depends on a patch that originated with git? I've started interfacing Haskell with git this week-end, that's something we'll need whichever model we choose. We should be able to start playing with actually modifying Darcs after next week-end. Juliusz - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
Dear diary, on Tue, Apr 19, 2005 at 02:20:55PM CEST, I got a letter where Juliusz Chroboczek [EMAIL PROTECTED] told me that... The problem is that there is no sequence of alien versions that one can differentiate. Git has a branched history, with each version that follows a merge having multiple parents. Yep. I've just realised that this morning. Is there some notion of ``primary parent'' as in Arch? Can a changeset have 0 parents? Yes, the root commit. Usually, there is only one, but there may be multiple of them theoretically. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
missing: git api, reference, user manual and mission statement
Dear all, please don't bother me with ``read the source dude'' or similar answers to this post. If it's tone or contents just piss You off, ignore it. I read a little about git lately, and tried to get it running the last two days. I found the following things lacking: 1) There is no clear (e.g. by name) distinction between ``git as done by Linus'', which is a kind of content addressable database with added semantics, and ``git as done by the rest of You'', which is a kind of SCM on top of Linuses stuff. 2) For Linuses stuff I dare to say that it is an evil hack from hell. A prototype come alive. This is not meant as an insult; I guess Linus agrees. What it misses the most is a written reasoning about the WHYs, HOWs and WHATFORs of git. There is the README which tells us a little about the WHAT on a level just above source code. Linus must have had an idea of the final product, and how to use that. The real day to day workflow. From that, and from his experience with BK and the glimpse he took at monotone, he deduced what limits the backend of his new distributed SCM system should have. That is what he implemented: A storage backend for an SCM. (Unfortunately he didn't tell us for which. This is like having the answer without the question. That is gitLinus is just like ``42''.) Unfortunately what this storage backend does not have is an API or UI definition. I.e. there is no definition of git interaction except for the git source code and the application on BLOB, TREE, CHANGESET as described in the README. I do think there should be a well defined API or UI so that the backend could be replaced / changed / improved as need dictates. 3) As of the gitSCM stuff, I really miss any kind of description how it works. That is it completely lacks any concept, except for ``we will use gitLinus as backend''. Take a look at some other distributed SCM (e.g. monotone -- which might be too slow for a project like the kernel) and see how much these people think about usage. Do not reinvent the wheel, there is prior art for use cases, too! Some examples are: 1) What does the typical usage look like? 2) What is a version? 3) What is fork? (Especially in the context of a distributed SCM.) 4) What is a branch? 5) Which questions do we want the SCM to answer? 6) What is our security modell? 7) How do we synchronise? (Not what command do we use , i.e. ``rsync'', but what is the operation, e.g. ``full replication of state''.) I really believe a lot of questions on the git mailing list could be answered if there was a user manual and a reference for git. Even before all of it will be implemented. 4) Concerning usability on systems other than Linux... I guess this one can be ignored by most. The source still uses st-st_mtim.tv_nsec which should be -st_mtimensec, I guess. git is implemented as mostly sh shell scripts. gitdiff-do and gitlog.sh rely on bash, more precisely on /bin/bash. git pull uses rsync ... The list of dependencies is long and growing. So if the intent of doing gitSCM with shell scripts was to make it portable: that goal was missed. 5) gitLinus as library. First I have to say that between what I saw in git-0.04 and the current stuff from git-pasky there has been quite a lot of work to get further away from the evil prototype. Still gitLinus lacks a clear definition of its interface, so I guess no one will be able to tell if it works correct. How could You do a test case without knowing a) what the software should do and b) how You should tell it? And of course there are still memory leaks. The obvious --- i.e. malloc and (missing) free in the same function --- I found while reading the git-0.04 source yesterday are gone. Still I found one of the ``malloc in called function no free in caller'' leaks in git-pasky as pulled NOW. And all I did was `grep malloc *'. Someone should sit down and read all the source top to bottom. And the software should either check its resource usage or someone should use a good tool on it. Thanks for Your time and patience, --Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: space compression (again)
On Sat, Apr 16, 2005 at 07:37:02PM +0200, Martin Uecker wrote: On Sat, Apr 16, 2005 at 11:11:00AM -0400, C. Scott Ananian wrote: The rsync approach does not use fixed chunk boundaries; this is necessary to ensure good storage reuse for the expected case (ie; inserting a single line at the start or in the middle of the file, which changes all the chunk boundaries). Yes. The chunk boundaries should be determined deterministically from local properties of the data. Use a rolling checksum over some small window and split the file it it hits a special value (0). This is what the rsyncable patch to zlib does. This is certainly uninteresting for source code repositories but for people who manage repositories of rsyncable binary packages this would save a lot of space, bandwidth and cpu time (compared to rsync because the scanning phase is not necessary anymore). Martin -- One night, when little Giana from Milano was fast asleep, she had a strange dream. signature.asc Description: Digital signature
naive question
Is there a way to check out a tree without changing the mtime of any files that you have already checked out and which are the same as the version you are checking out? It seems that checkout-cache -a doesn't overwrite any existing files, and checkout-cache -f -a overwrites all files and gives them the current mtime. This is a pain if you are using make and your tree is large (like, for instance, the linux kernel :), because it means that after a checkout-cache -f -a you get to recompile everything. Paul. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: naive question
* David Woodhouse [EMAIL PROTECTED] wrote: On Tue, 2005-04-19 at 23:00 +1000, Paul Mackerras wrote: Is there a way to check out a tree without changing the mtime of any files that you have already checked out and which are the same as the version you are checking out? It seems that checkout-cache -a doesn't overwrite any existing files, and checkout-cache -f -a overwrites all files and gives them the current mtime. This is a pain if you are using make and your tree is large (like, for instance, the linux kernel :), because it means that after a checkout-cache -f -a you get to recompile everything. Corollary: why aren't we storing mtime in the tree objects? Check the [bug] git: check-files mtime problem? thread - i noticed this problem before and gave a few suggestions but the discussion got nowhere. But the problem is still very much present. Ingo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
I disagree. This already forces you to have two branches (one to pull from to get the data, mirroring the remote branch, one for your real work) uselessly and needlessly. ... These naming issues may appear silly but I think they matter big time for usability, intuitiveness, and learning curve (I don't want git-pasky become another GNU arch). Not that it is worth that much, but my $0.02 is that Petr is right on this one. I want something that allows me to get the objects into my local repository without funking with my working directory. As a long time CVS user, git update would do what I expect it to. I don't have any pre-conceptions about what pull does, so it doesn't phase me if pull is used for this purpose. However, perhaps pull means something in some other SCM that would cause confusion for others? Some alternatives to pull are offered: hoard, gather, make-local, download. Regards, jon. -- homepage: http://www.zeta.org.au/~jon/ blog: http://orwelliantremors.blogspot.com/ - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
On Tue, 2005-04-19 at 12:50 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter where Martin Schlemmer [EMAIL PROTECTED] told me that... On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter where David Greaves [EMAIL PROTECTED] told me that... Dunno. I do it personally all the time, with git at least. What do others think? :-) I think pull is pull. If you are doing lots of local stuff and do not want it overwritten, it should have been in a forked branch. I disagree. This already forces you to have two branches (one to pull from to get the data, mirroring the remote branch, one for your real work) uselessly and needlessly. I think there is just no good name for what pull is doing now, and update seems like a great name for what pull-and-merge really is. Pull really is pull - it _pulls_ the data, while update also updates the given tree. No surprises. (We should obviously have also update-without-pull but that is probably not going to be so common so a parameter for update (like -n) should be fine for that.) These naming issues may appear silly but I think they matter big time for usability, intuitiveness, and learning curve (I don't want git-pasky become another GNU arch). Ok, so 'pull' do the bk thing, and 'update' do the cvs thing. I think however you should do either do one or the other. Maybe drop the 'update', and rather add 'checkout' (or 'co' for short) which will update the tree (or merge with local changes if needed). Then you have two distinct separate things (ok, so pretty much how bk do things). This will also enable you to make 'fork', 'export', etc just do the right thing with the database, but leave 'checkout' up to the user if he wants to do so. -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)
Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter where Steven Cole [EMAIL PROTECTED] told me that... Here is perhaps a better way to provide detailed help for each git command. A command.help file for each command can be written in the style of a man page. I don't like it. I think the 'help' command should serve primarily as a quick reference, which does not blend so well with a manual page - it's too long and too convoluted by repeated output. I'd just print the top comment from each file. :-) On the other hand, having more complete docs seems like an excellent idea (and other threads support that) I'd certainly like to see more specification oriented documentation... (even if it turns out to be disposable) Steven, if you carry on sending more verbose docs I'll certainly read and work with you on editing them... Nb kernel-doc doesn't seem appropriate for user level docs. maybe, whilst there's so much flux, have: git man command that just outputs text If Petr wants the top comment to be extracted by help then maybe a bottom comment block could contain the more complete text? I *really* think that the user docs should live in the source for now (hence I think that git man is better than going straight to man/docbook). I wasn't sure whether to perlise the code or do a shell-lib - but looking at the algorithms needed in things like git status I reckon the shell will end up becoming a hackish mess of awk/sed/tr/sort/uniq/pipe (ie perl) anyway. So I'm going to have a go at that - Petr, if you have a minute could you send me, off list, a bit of perl code that epitomises the style you like? David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT Web Interface
On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter where Kay Sievers [EMAIL PROTECTED] told me that... I'm hacking on a simple web interface, cause I missed the bkweb too much. It can't do much more than browse through the source tree and show the log now, but that should change... :) http://ehlo.org/~kay/gitweb.pl?project=linux-2.6 Hmm, looks nice for a start. (But you have obsolete git-pasky tree there! ;-) Yeah, it's fresh now. :) How can I get the files touched with a changeset and the corresponding diffs belonging to it? diff-tree to get the list of files, you can do the corresponding diffs e.g. by doing git diff -r tree1:tree2. Preferably make a patch for it first to make it possible to diff individual files this way. Ah, nice! Got it working. Thanks, Kay - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
On Tue, 19 Apr 2005, Tupshin Harper wrote: I suspect that any use of wildcards in a new format would be impossible for darcs since it wouldn't allow darcs to construct dependencies, though I'll leave it to david to respond to that. Note that git _does_ very efficiently (and I mean _very_) expose the changed files. So if this kind of darcs patch is always the same pattern just repeated over n files, then you really don't need to even list the files at all. Git gives you a very efficient file listing by just doing a diff-tree (which does not diff the _contents_ - it really just gives you a pretty much zero-cost which files changed listing). So that combination would be 100% reliable _if_ you always split up darcs patches to common elements. And note that there does not have to be a 1:1 relationship between a git commit and a darcs patch. For example, say that you have a darcs patch that does a combination of change token x to token y in 100 files and rename file a into b. I don't know if you do those kind of combination patches at all, but if you do, why not just split them up into two? That way the list of files changed _does_ 100% determine the list of files for the token exchange. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT Web Interface
On Tue, Apr 19, 2005 at 05:59:45PM +0200, Kay Sievers wrote: On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter where Kay Sievers [EMAIL PROTECTED] told me that... I'm hacking on a simple web interface, cause I missed the bkweb too much. It can't do much more than browse through the source tree and show the log now, but that should change... :) http://ehlo.org/~kay/gitweb.pl?project=linux-2.6 Hmm, looks nice for a start. (But you have obsolete git-pasky tree there! ;-) Yeah, it's fresh now. :) How can I get the files touched with a changeset and the corresponding diffs belonging to it? diff-tree to get the list of files, you can do the corresponding diffs e.g. by doing git diff -r tree1:tree2. Preferably make a patch for it first to make it possible to diff individual files this way. Ah, nice! Got it working. Looks good, care to post the updated version? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: missing: git api, reference, user manual and mission statement
Dear diary, on Tue, Apr 19, 2005 at 02:36:32PM CEST, I got a letter where Klaus Robert Suetterlin [EMAIL PROTECTED] told me that... 1) There is no clear (e.g. by name) distinction between ``git as done by Linus'', which is a kind of content addressable database with added semantics, and ``git as done by the rest of You'', which is a kind of SCM on top of Linuses stuff. There is git and git-pasky (git-pasky is superset; therefore various patches floating around either get to git-pasky or to both). I'm not sure what else do you mean. 2) For Linuses stuff I dare to say that it is an evil hack from hell. A prototype come alive. This is not meant as an insult; I guess Linus agrees. I don't think it's evil at all. Why should it? I do think there should be a well defined API or UI so that the backend could be replaced / changed / improved as need dictates. It's stabilizing. Mind you, it's 2 weeks old. 3) As of the gitSCM stuff, I really miss any kind of description how it works. That is it completely lacks any concept, except for ``we will use gitLinus as backend''. Have you read the README? If you have any questions, go ahead and ask. _Write_ the description if you miss it. 4) Concerning usability on systems other than Linux... I guess this one can be ignored by most. The source still uses st-st_mtim.tv_nsec which should be -st_mtimensec, I guess. Patches welcome. git is implemented as mostly sh shell scripts. gitdiff-do and gitlog.sh rely on bash, more precisely on /bin/bash. git pull uses rsync ... The list of dependencies is long and growing. So if the intent of doing gitSCM with shell scripts was to make it portable: that goal was missed. I think the way to go now that it's working and we are to add some sweet cream on it is to rewrite it in Perl. I have some parts in progress already. 5) gitLinus as library. First I have to say that between what I saw in git-0.04 and the current stuff from git-pasky there has been quite a lot of work to get further away from the evil prototype. Still gitLinus lacks a clear definition of its interface, so I guess no one will be able to tell if it works correct. How could You do a test case without knowing a) what the software should do and b) how You should tell it? You couldn't. UTSL now and write the docs and the testcases, or wait a while. And of course there are still memory leaks. The obvious --- i.e. malloc and (missing) free in the same function --- I found while reading the git-0.04 source yesterday are gone. Still I found one of the ``malloc in called function no free in caller'' leaks in git-pasky as pulled NOW. And all I did was `grep malloc *'. Someone should sit down and read all the source top to bottom. And the software should either check its resource usage or someone should use a good tool on it. Someone? Again, patches welcome. The patches are likely usually no big deal now, though. I'm by all means for fixing them, especially when git will start to head towards libgit. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [script] ge: export commits as patches
Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... is there any 'export commit as patch' support in git-pasky? I didnt find any such command (maybe it got added meanwhile), so i'm using the 'ge' hack below. e.g. i typically look at commits via 'git log', and then when i see something interesting, i look at the commit via the 'ge' script. E.g. ge 834f6209b22af2941a8640f1e32b0f123c833061 done in the kernel tree will output a particular commit's header and the patch. Nice idea. I will add it, probably as 'git patch'. TREE1=$(cat-file commit 2/dev/null $1 | head -4 | grep ^tree | cut -d' ' -f2) if [ $TREE1 = ]; then echo 'ge commit-ID'; exit -1; fi PARENT=$(cat-file commit 2/dev/null $1 | head -4 | grep ^parent | cut -d' ' -f2) if [ $PARENT = ]; then echo 'ge commit-ID'; exit -1; fi TREE2=$(cat-file commit 2/dev/null $PARENT | head -4 | grep ^tree | cut -d' ' -f2) if [ $TREE2 = ]; then echo 'ge commit-ID'; exit -1; fi commit-id and parent-id tools might be useful. ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT Web Interface
Greg KH greg at kroah.com writes: [...] Looks good, care to post the updated version? http://ehlo.org/~kay/ What about a git repo of gitweb? gitweb2.pl is nice with the browse function. BTW, but there's a '1' artefact right after the browse link in action=show_tree :-) Kay, your script is really nice, good job! Here are some random ideas: * make *any* hash clickable instead of the (show xx) links. Applicable in show_log, show_diff * in show_diff, keep a back link to cset * provide a download link in show_file (as well as show_cset/show_diff ?) * obfuscate against spam the mail adresses in show_log? * use of colors in show_log (commiter, author, ..) * perhaps borrow some ideas from other SCM web interfaces besides BK * kindly ask kernel.org to host your script one day? All the best, -- Stephane - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: naive question
On Tue, 19 Apr 2005, Petr Baudis wrote: I'd actually prefer, if: (i) checkout-cache simply wouldn't touch files whose stat matches with what is in the cache; it updates the cache with the stat informations of touched files Run update-cache --refresh _before_ doing the checkout-cache, and that is exactly what will happen. But yes, if you want to make checkout-cache update the stat info (Ingo wanted to do that too), it should be possible. The end result is a combination of update-cache and checkout-cache, though: you'll effectively need to both (just in one pass). With the current setup, you have to do update-cache --refresh checkout-cache -f -a update-cache --refresh which is admittedly fairly inefficient. The real expense right now of a merge is that we always forget all the stat information when we do a merge (since it does a read-tree). I have a cunning way to fix that, though, which is to make read-tree -m read in the old index state like it used to, and then at the end just throw it away except for the stat information. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT Web Interface
On Tue, Apr 19, 2005 at 07:32:42PM +0200, Kay Sievers wrote: On Tue, Apr 19, 2005 at 09:52:48AM -0700, Greg KH wrote: On Tue, Apr 19, 2005 at 05:59:45PM +0200, Kay Sievers wrote: On Tue, 2005-04-19 at 02:52 +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 02:44:15AM CEST, I got a letter where Kay Sievers [EMAIL PROTECTED] told me that... I'm hacking on a simple web interface, cause I missed the bkweb too much. It can't do much more than browse through the source tree and show the log now, but that should change... :) http://ehlo.org/~kay/gitweb.pl?project=linux-2.6 Hmm, looks nice for a start. (But you have obsolete git-pasky tree there! ;-) Yeah, it's fresh now. :) How can I get the files touched with a changeset and the corresponding diffs belonging to it? diff-tree to get the list of files, you can do the corresponding diffs e.g. by doing git diff -r tree1:tree2. Preferably make a patch for it first to make it possible to diff individual files this way. Ah, nice! Got it working. Looks good, care to post the updated version? Sure, but expect it to change dramatically tonight. :) Ok, how about putting a link to it somewhere then, so you don't have to be bothered with people like me asking for the latest copy? :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add help details to git help command. (This time with Perl)
Dear diary, on Tue, Apr 19, 2005 at 07:35:15PM CEST, I got a letter where Steven Cole [EMAIL PROTECTED] told me that... Example: ..snip a perfect-looking example.. - Speaking of 'git diff', I ran that before applying the following patch, and got a diff starting thusly: --- /dev/null +++ b/gitmerge-file.sh I had earlier done a 'git pull pasky', which was 'Up to date'. Check/prune your add/rm-queue. So, the following patch is a conventional diff. If the Perl filename or code is too hideous, you're more than welcome to change it. I'd actually prefer to just throw the whole help command handling to githelp.pl. I dislike helper scripts if I can avoid them. ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: naive question
On Tue, 19 Apr 2005, Linus Torvalds wrote: The real expense right now of a merge is that we always forget all the stat information when we do a merge (since it does a read-tree). I have a cunning way to fix that, though, which is to make read-tree -m read in the old index state like it used to, and then at the end just throw it away except for the stat information. Ok, done. That was really the plan all along, it just got dropped in the excitement of trying to get the dang thing to _work_ in the first place ;) The current version only does read-tree -m orig branch1 branch2 which now reads the old stat cache information, and then applies that to the end result of any trivial merges in case the merge result matches the old file stats. It really boils down to this littel gem; /* * See if we can re-use the old CE directly? * That way we get the uptodate stat info. */ if (path_matches(result, old) same(result, old)) *result = *old; and it seems to work fine. HOWEVER, I'll also make it do the same for a single-tree merge: read-tree -m newtree so that you can basically say read a new tree, and merge the stat information from the current cache. That means that if you do a read-tree -m newtree followed by a checkout-cache -f -a, the checkout-cache only checks out the stuff that really changed. You'll still need to do an update-cache --refresh for the actual new stuff. We could make checkout-cache update the cache too, but I really do prefer a checkout-cache only reads the index, never changes it world-view. It's nice to be able to have a read-only git tree. Final note: just doing a plain read-tree newtree will still throw all the stat info away, and you'll have to refresh it all... Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
On Tue, 19 Apr 2005, Petr Baudis wrote: I disagree. This already forces you to have two branches (one to pull from to get the data, mirroring the remote branch, one for your real work) uselessly and needlessly. If you pull in a non-tracked tree, it certainly won't apply the changes, so you can just have your local tree and pull other people's trees as desired. I think there is just no good name for what pull is doing now, and update seems like a great name for what pull-and-merge really is. Pull really is pull - it _pulls_ the data, while update also updates the given tree. No surprises. I'm actually getting suspicious that the right thing is to hide pull in the id scheme. That is, instead of saying linus to refer to the linus head that you currently have, you say +linus to refer to the head Linus has on his server currently, and this will cause you to download anything necessary to perform the operation with the resulting value. See, I don't think you ever want to just pull. You want to pull-and-do-something, but the something could be any operation that uses a commit, not necessarily update. So you could do git diff -r +linus to compare your head against current linus. You'd want git update to take a working directory from linus to +linus (just because you know Linus's more recent head doesn't mean you're automatically using it). You could just git merge +linus in your working directory to sync with Linus. Even git log +linus to see his recent changes. I think the only reason not to just make any reference to a head pull it is performance on looking up the head; you don't really want to hammer the server getting these 40-byte files constantly or wait for a connection every time (not to mention the possibility of not being able to connect). But there's no reason to want to not have the latest data, since the older data doesn't go away. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] write-tree performance problems
On Tue, Apr 19, 2005 at 10:36:06AM -0700, Linus Torvalds wrote: In fact, git has all the same issues that BK had, and for the same fundamental reason: if you do distributed work, you have to always append stuff, and that means that you can never re-order anything after the fact. You can, moving a patch around is just a chain of merges. [Warning, ascii art ahead] A merge is traditionally seen as: 1- Start with (A, B, C... are nodes/trees..., Pn are patches/changesets): /--P1-B / A \ \--P2-C 2- End with: /--P1-B / A(P1+P2)-D \ \--P2-C where D is the merge between B and C with A as common ancestor. But you can also see the result as: /--P1-B--P2--\ / \ A D \ / \--P2-C--P1--/ i.e. you have two patch chains, one being A-P1-B-P2-D and the other A-P2-C-P1-D. I.e. you have the two patches P1 and P2 in two possible patching orders. But you can do even more amusing. Start with a patch chain: E--P3--F--P4--G and merge E and G with F as common ancestor. You'll then get H where E--P4--H--P3--G. I.e. you inverted two patches in your patch chain. Or, if you keep H instead of G as your head, you removed P3 from your patch chain. Of course you can permute blocs of patches that way by having E, F and G further away from each other. You just increase the merge conflict probability. That is, I think, the way to do quilt/arch patch handling with safe distribution and safe backtracing procedures. OG. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [script] ge: export commits as patches
* Petr Baudis [EMAIL PROTECTED] wrote:
Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
is there any 'export commit as patch' support in git-pasky? I didnt find
any such command (maybe it got added meanwhile), so i'm using the 'ge'
hack below.
e.g. i typically look at commits via 'git log', and then when i see
something interesting, i look at the commit via the 'ge' script. E.g.
ge 834f6209b22af2941a8640f1e32b0f123c833061 done in the kernel tree
will output a particular commit's header and the patch.
Nice idea. I will add it, probably as 'git patch'.
TREE1=$(cat-file commit 2/dev/null $1 | head -4 | grep ^tree | cut -d' '
-f2)
if [ $TREE1 = ]; then echo 'ge commit-ID'; exit -1; fi
PARENT=$(cat-file commit 2/dev/null $1 | head -4 | grep ^parent | cut -d'
' -f2)
if [ $PARENT = ]; then echo 'ge commit-ID'; exit -1; fi
TREE2=$(cat-file commit 2/dev/null $PARENT | head -4 | grep ^tree | cut
-d' ' -f2)
if [ $TREE2 = ]; then echo 'ge commit-ID'; exit -1; fi
commit-id and parent-id tools might be useful. ;-)
find a cleaned up 'ge' script below.
and please fix gitXnormid.sh to simply echo nothing and return with a -1
exit value when a nonsensical ID is passed to it. Right now the output
is quite ugly if you do 'ge blah'.
Ingo
#!/bin/bash
usage ()
{
echo 'usage: ge commit-ID'
exit -1
}
if [ $# != 1 ]; then
usage
fi
ME=$(commit-id $1); [ $ME = ] usage
PARENT=$(parent-id $ME); [ $PARENT = ] usage
TREE1= $(tree-id $ME); [ $TREE1 = ] usage
TREE2= $(tree-id $PARENT); [ $TREE2 = ] usage
cat-file commit $ME
echo
git diff -r $TREE2:$TREE1
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] write-tree performance problems
On Tue, 19 Apr 2005, Chris Mason wrote: Very true, you can't replace quilt with git without ruining both of them. But it would be nice to take a quilt tree and turn it into a git tree for merging purposes, or to make use of whatever visualization tools might exist someday. Fair enough. The thing is, going from quilt-git really is a pretty big decision, since it's the decision that says I will now really commit all this quilt changes forever and ever. Which is also why I think it's actually ok to take a minute to do 100 quilt patches. This is not something you do on a whim. It's something you'd better think about. It's turning a very fluid environment into a unchangable, final thing. That said, I agree that write-tree is expensive. It tends to be by far the most expensive op you normally do. I'll make sure it goes faster. We already have a trust me, it hasn't changed via update-cache. Heh. I see update-cache not as a it hasn't changed, but a it _has_ changed, and now I want you to reflect that fact. In other words, update-cache is an active statement: it says that you're ready to commit your changes. In contrast, to me your write-tree thing in many ways is the reverse of that: it's saying don't look here, there's nothing interesting there. Which to me smells like trying to hide problems rather than being positive about them. Which it is, of course. It's trying to hide the fact that writing a tree is not instantaenous. With that said, I hate the patch too. I didn't see how to compare against the old tree without reading each tree object from the old tree, and that should be slower then what write-tree does now. Reading a tree is faster, simply because you uncompress instead of compress. So I can read a tree in 0.28 seconds, but it takes me 0.34 seconds to write one. That said, reading the trees has disk seek issues if it's not in the cache. What I'd actually prefer to do is to just handle tree caching the same way we handle file caching - in the index. Ie we could have the index file track what subtree is this directory associated with, and have a update-cache --refresh-dir thing that updates it (and any entry update in that directory obviously removes the dir-cache entry). Normally we'd not bother and it would never trigger, but it would be useful for your scripted setup it would end up caching all the tree information in a very efficient manner. Totally transparently, apart from the one --refresh-dir at the beginning. That one would be slightly expensive (ie would do all the stuff that write-tree does, but it would be done just once). (We could also just make write-tree do it _totally_ transparently, but then we're back to having write-tree both read _and_ write the index file, which is a situation that I've been trying to avoid. It's so much easier to verify the correctness of an operation if it is purely one-way). I'll think about it. I'd love to speed up write-tree, and keeping track of it in the index is a nice little trick, but it's not quite high enough up on my worries for me to act on it right now. But if you want to try to see how nasty it would be to add tree index entries to the index file at write-tree time automatically, hey... Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [script] ge: export commits as patches
On Tue, Apr 19, 2005 at 07:03:20PM +0200, Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... is there any 'export commit as patch' support in git-pasky? I didnt find any such command (maybe it got added meanwhile), so i'm using the 'ge' hack below. e.g. i typically look at commits via 'git log', and then when i see something interesting, i look at the commit via the 'ge' script. E.g. ge 834f6209b22af2941a8640f1e32b0f123c833061 done in the kernel tree will output a particular commit's header and the patch. Nice idea. I will add it, probably as 'git patch'. Ah, thanks for doing this. 'git patch' works great (but you might want to mention in the 'help' that you can give the commit id for the patch, if you don't want to see the HEAD patch.) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Greg KH wrote: Nice, it looks like the merge of this tree, and my usb tree worked just fine. Yup, it all seems to work out. So, what does this now mean? Is your kernel.org git tree now going to be the real kernel tree that you will be working off of now? Should we crank up the nightly snapshots and emails to the -commits list? I'm not quite ready to consider it real, but I'm getting there. I'm still working out some performance issues with merges (the actual merge operation itself is very fast, but I've been trying to make the subsequent update the working directory tree to the right thing be much better). Can I rely on the fact that these patches are now in your tree and I can forget about them? :) Just wondering how comfortable you feel with your git tree so far. Hold off for one more day. I'm very comfortable with how well git has worked out so far, and yes, mentally I consider this the tree, but the fact is, git isn't exactly easy on normal users. I think my merge stuff and Pasky's scripts are getting there, but I want to make sure that we have a version of Pasky's scripts that use the new read-tree -m optimizations to make tracking a tree faster, and I'd like to have them _tested_ a bit first. In other words, I want it to be at the point where people can do git pull repo-address and it will just work, at least for people who don't have any local changes in their tree. None of this check out all the files again crap. But how about a plan that we go live tomorrow - assuming nobody finds any problems before that, of course. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [script] ge: export commits as patches
Dear diary, on Tue, Apr 19, 2005 at 08:56:07PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... and please fix gitXnormid.sh to simply echo nothing and return with a -1 exit value when a nonsensical ID is passed to it. Right now the output is quite ugly if you do 'ge blah'. That's a feature; you can do || exit 1. Put its stderr to /dev/null if you want your own error reporting. BTW, I still think my gitpatch.sh is nicer. ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 12:40:44PM -0700, Linus Torvalds wrote: I'm still working out some performance issues with merges (the actual merge operation itself is very fast, but I've been trying to make the subsequent update the working directory tree to the right thing be much better). Ok, if you want some practice with real merges, feel free to merge from the following two trees whenever you are ready: kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/ for 11 aoe bugfix patches, and: kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ for 13 driver core, sysfs, and debugfs fixes. The diffstats are: aoe: Documentation/aoe/mkdevs.sh |1 Documentation/aoe/mkshelf.sh |1 Documentation/aoe/todo.txt| 14 Documentation/aoe/udev-install.sh |6 +- drivers/block/aoe/aoe.h | 23 +-- drivers/block/aoe/aoeblk.c|5 + drivers/block/aoe/aoecmd.c| 110 ++ drivers/block/aoe/aoedev.c|8 +- drivers/block/aoe/aoenet.c|8 +- 9 files changed, 111 insertions(+), 65 deletions(-) driver: Documentation/kref.txt| 221 +- drivers/base/class.c |2 drivers/base/core.c |3 drivers/base/firmware_class.c |3 drivers/base/platform.c |1 drivers/usb/host/hc_crisv10.c |1 fs/partitions/check.c |2 fs/sysfs/file.c | 35 ++ include/linux/debugfs.h | 14 +- include/linux/sysfs.h |7 + lib/kobject.c |7 - net/bridge/br_sysfs_if.c |2 scripts/ver_linux |2 13 files changed, 290 insertions(+), 10 deletions(-) No rush, but they should be good test for your merge speeds, as they are based off of an older HEAD than your current one :) In other words, I want it to be at the point where people can do git pull repo-address and it will just work, at least for people who don't have any local changes in their tree. None of this check out all the files again crap. That would be very nice to have. But how about a plan that we go live tomorrow - assuming nobody finds any problems before that, of course. That's fine with me. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Better option parsing for gitdiff.sh
Hello!
This patch improves option handling for gitdiff.sh. Now -p doesn't
need to precede -r, although all options still have to be placed
before the file names. Also, the patch introduces a minimal usage info
for the script.
The patch is against current git-pasky.
Signed-off-by: Pavel Roskin [EMAIL PROTECTED]
--- a/gitdiff.sh
+++ b/gitdiff.sh
@@ -27,6 +27,13 @@ die () {
exit 1
}
+usage () {
+ echo Usage: 2
+ echo gitdiff.sh -r rev1:rev2 [FILES...] 2
+ echo gitdiff.sh -r rev1 -r rev2 [FILES...] 2
+ exit 1
+}
+
diffqfile () {
dir=$1; shift
file=$1; shift
@@ -59,26 +66,44 @@ diffqueue () {
return $ret
}
-
-# FIXME: The commandline parsing is awful.
-
-if [ $1 = -p ]; then
- shift
- parent=1
-fi
-
-if [ $1 = -r ]; then
- shift
- id1=$(echo $1: | cut -d : -f 1)
- [ $id1 != $1 ] id2=$(echo $1: | cut -d : -f 2)
- shift
-fi
-
-if [ $1 = -r ]; then
- shift
- id2=$1
- shift
-fi
+# Parsing the command line
+id1_set=
+id2_set=
+while true; do
+ case $1 in
+ -p)
+ parent=1
+ shift
+ ;;
+ -r)
+ if test $id2_set; then
+ echo Too many revision numbers 21
+ usage
+ elif test $id1_set; then
+ shift
+ id2=$1
+ id2_set=1
+ shift
+ else
+ shift
+ id1=$(echo $1: | cut -d : -f 1)
+ id1_set=1
+ if test $id1 != $1; then
+ id2=$(echo $1: | cut -d : -f 2)
+ id2_set=1
+ fi
+ shift
+ fi
+ ;;
+ -*)
+ echo Unknown option $1 21
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+done
if [ $parent ]; then
id2=$id1
--
Regards,
Pavel Roskin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add help details to git help command. (This time with Perl)
Steven Cole wrote: Speaking of I think, the name cogito was suggested for the SCM layer, but IIRC Linus suggested staying with just plain git. Petr suggested tig, perhaps because it looks at git from another point of view. I haven't read _all_ the mails - I thought cogito was kinda selected and I got the feeling that Linus wasn't exactly bothered what it was called. Anyway, git has a rename that needs testing at some point... legitSince git is GPLv2, but perhaps a little too French. That made me smile. Quite a few entendres in there... It's Petr's baby - he gets to name it. David - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
On Monday 18 April 2005 10:05 pm, Kevin Smith wrote: The big feature of a darcs replace patch is that it works forward and backward in time. Let me try to come up with an example that can help explain it. Hopefully I'll get it right. Let's start with a file like this that exists in a project for which both you and I have darcs repos: cat dog fish Now, you change it to: cat dog dog fish while I simultaneously do a replace of dog with plant, resulting in: cat plant fish We merge. The final result in both of our trees is: cat plant plant fish Notice that just by looking at my diffs, you can't tell that I used a replace operation. I didn't just replace the instances of dog that were in my file at that moment. I conceptually replaced all instances, including ones that aren't there yet. I think that's the best explanation of how it works. And that is partially why darcs is so powerful. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 pgprVLv2ZgcYv.pgp Description: PGP signature
Re: [PATCH] write-tree performance problems
On Tue, 19 Apr 2005, Linus Torvalds wrote: On Tue, 19 Apr 2005, Chris Mason wrote: Very true, you can't replace quilt with git without ruining both of them. But it would be nice to take a quilt tree and turn it into a git tree for merging purposes, or to make use of whatever visualization tools might exist someday. Fair enough. The thing is, going from quilt-git really is a pretty big decision, since it's the decision that says I will now really commit all this quilt changes forever and ever. Which is also why I think it's actually ok to take a minute to do 100 quilt patches. This is not something you do on a whim. It's something you'd better think about. It's turning a very fluid environment into a unchangable, final thing. what if you turned the forest of quilt patches into a forest of git trees? (essentially applying each patch against the baseline seperatly) would this make sense or be useful? 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: Nice, it looks like the merge of this tree, and my usb tree worked just fine. Yup, it all seems to work out. [many files patched] patching file mm/mmap.c patching file net/bridge/br_sysfs_if.c patching file scripts/ver_linux --^ Hey, that's my patch! Last...and least. But perhaps a progress bar right about here might be a good thing for the terminally impatient. real3m54.909s user0m14.835s sys 0m10.587s 4 minutes might be long enough to cause some folks to lose hope. Steven - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 2005-04-19 at 15:00 -0700, Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: It looks like your domain name isn't set up properly for your box (which is why it worked for you, but not me before, causing that patch). No, I think it's a bug in your domainname changes. I don't think you should do the domainname at all if the hostname has a dot in it. Most machines I have access to (and that includes machines that are professionally maintained, not just my own cruddy setup) says (none) to domainname and have the full hostname in hostname. And even the ones that use domainname tend to not have a fully qualified DNS domain there. You need to use dnsdomainname to get that, and I don't even know how to do it with standard libc. Correct me if I am wrong, but the right way to do this is to set the hostname to just that - the hostname, and add 'domain foo.com' to /etc/resolv.conf. Then you should get something like (for say www1.foo.com): $ hostname www1 $ dnsdomainname foo.com $ hostname -f www1.foo.com I know for some buggy software the workaround was to set the hostname to the FQDN, but that is really just a kludge, and the software should rather be fixed (had to patch postfix some time back for instance). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 06:27:38PM -0400, Daniel Jacobowitz wrote: On Tue, Apr 19, 2005 at 03:00:04PM -0700, Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: It looks like your domain name isn't set up properly for your box (which is why it worked for you, but not me before, causing that patch). No, I think it's a bug in your domainname changes. I don't think you should do the domainname at all if the hostname has a dot in it. Most machines I have access to (and that includes machines that are professionally maintained, not just my own cruddy setup) says (none) to domainname and have the full hostname in hostname. And even the ones that use domainname tend to not have a fully qualified DNS domain there. You need to use dnsdomainname to get that, and I don't even know how to do it with standard libc. So how about something like this? (Somebody who actually knows how these things should be done - please feel free to pipe up). The glibc documentation blows for this, but what getdomainname comes from uname(2), not from any DNS-related configuration. Debian only ever sets this if you're using NIS. Well, somehow Gentoo sets this up properly, and I'm not using NIS. Hm, my SuSE boxes on the other hand... There's no real great way to get the current hostname; a lot of applications do a reverse DNS lookup on the primary network interface, with appropriate handwaving to define primary. Easiest might be to punt to hostname --fqdn, or an equivalent to its algorithm - which appears to be fetch the hostname from uname, do a DNS lookup on that, and a reverse DNS lookup on the result. Ick. Let's stick with Linus's patch for now... thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Steven Cole wrote: But perhaps a progress bar right about here might be a good thing for the terminally impatient. real3m54.909s user0m14.835s sys 0m10.587s 4 minutes might be long enough to cause some folks to lose hope. Well, the real operations took only 15 seconds. What kind of horribe person are you, that you don't have all of the kernel in your disk cache already? Shame on you. Or was the 4 minutes for downloading all the objest too? Anyway, it looks like you are using pasky's scripts, and the old patch-based upgrade at that. You certainly will _not_ see the [many files patched] patching file mm/mmap.c .. if you use a real git merge. That's probable be the real problem here. Real merges have no patches taking place _anywhere_. And they take about half a second. Doing an update of your tree should _literally_ boil down to # # repo needs to point to the repo we update from # rsync -avz --ignore-existing $repo/objects/. .git/objects/. rsync -L $repo/HEAD .git/NEW_HEAD || exit 1 read-tree -m $(cat .git/NEW_HEAD) || exit 1 checkout-cache -f -a update-cache --refresh mv .git/NEW_HEAD .git/HEAD and if it does anything else, it's literally broken. Btw, the above does need my read-tree -m thing which I committed today. (CAREFUL: the above is not a good script, because it _will_ just overwrite all your old contents with the stuff you updated to. You should thus not actually use something like this, but a git update should literally end up doing the above operations in the end, and just add proper checking). And if that takes 4 minutes, you've got problems. Just say no to patches. Linus PS: If you want a clean tree without any old files or anything else, for that matter, you can then do a show-files -z --others | xargs -0 rm, but be careful: that will blow away _anything_ that wasn't revision controlled with git. So don't blame me if your pr0n collection is gone afterwards. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Tue, Apr 19, 2005 at 10:20:47PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... Pasky? Can you check my latest git stuff, notably read-tree.c and the changes to git-pull-script? I've made git merge to use read-tree -m, HTH. I will probably not buy git-export, though. (That is, it is merged, but I won't make git frontend for it.) My git export already does something different, but more importantly, git patch of mine already does effectively the same thing as you do, just for a single patch; so I will probably just extend it to do it for an (a,b] range of patches. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
Daniel Barkalow wrote: See, I don't think you ever want to just pull. You want to pull-and-do-something, but the something could be any operation... In a _logical_ sense that's true; I'd only want to pull data if I intended to (possibly) do something with it. But as a _practical_ matter, I can see lots of reasons for doing a pull as a separate operation. One is disconnected operation; I may want to pull the data now, to prepare for disconnectino, and then work later while disconnected. Another is using lots of data compared to the pipesize; if I have a dial-in modem, or I want the history of the linux kernel since 0.0.1, I might want to pull go away/go to sleep for the night. I might use cron/at to automatically pull at 3am from some interesting branches. The next day, I could then pull again to update just what changed, and/or do the operation I intended to do if the operation auto-pulls the missing data. I'm actually getting suspicious that the right thing is to hide pull in the id scheme. That is, instead of saying linus to refer to the linus head that you currently have, you say +linus to refer to the head Linus has on his server currently, and this will cause you to download anything necessary to perform the operation with the resulting value. That's an interesting idea. I'll have to think about that. What command would you suggest for the common case of update with current track? I've proposed git update [NAME]. git merge with update-from-current-track as default seems unclear, and I worry that I might accidentally press RETURN too soon merge with the wrong thing. And I like the idea of git update doing the same thing (essentially) as cvs update and svn update; LOTS of people know what update does, so using the same command name for one of the most common operations smooths transition (GNU Arch's tla update is almost, though not exactly, the same too.) I still think it's important to have a very simple command that updates your current branch with a tracked branch (because it's common to stay in sync with a master branch), and a way to just download the data without doing things with it YET (because you want to do things in stages). The commands update and pull come to mind when thinking that way, though as long as the commands are simple clear that's a good thing (I think it's a GOOD idea to use the same commands as CVS and Subversion when the results are essentially the same, just because so many people are already familiar with them, but only where it makes sense.) --- David A. Wheeler - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
(Sorry for the delayed reply -- I'm living on tape delay for a bit.) On Mon, 2005-04-18 at 22:05 -0400, Kevin Smith wrote: The other is replace very instace of identifier `foo` with identifier`bar`. That could be derived, however, by a particularly smart parser [1]. No, it can't. Seriously. A darcs replace patch is encoded as rules, not effects, and it is impossible to derive the rules just by looking at the results. Not difficult. Impossible. If I do a token replace in an editor (say one of those fancy new-fangled refactoring thangs, or good ol' vi), a token-level comparator can discover what I did. That link I sent is an example of one such beast. The big feature of a darcs replace patch is that it works forward and backward in time. That's *not* a feature of the token replace patch, however. That's a feature of the darcs commutation machinery, correct? (With the obvious caveat that darcs can only *do* the commutation if it has correctly nuanced darcs-style token replace patches, rather than mere ASCII textual diffs.) Let me try to come up with an example that can help explain it. Hopefully I'll get it right. Let's start with a file like this that exists in a project for which both you and I have darcs repos: cat dog fish Now, you change it to: cat dog dog fish while I simultaneously do a replace of dog with plant, resulting in: cat plant fish We merge. The final result in both of our trees is: cat plant plant fish Okay, that all makes sense. Notice that just by looking at my diffs, you can't tell that I used a replace operation. Here's where we disagree. If you checkpoint your tree before the replace, and immediately after, the only differences in the source-controlled files would be due to the replace. And since the language of the file is known (and thereby the tokenization -- it *is* well-defined), then a tokenizer that compares the before and after trees (for just the files that changed, obviously), can discover what you did, and promote the mere ASCII diff into a token-replace diff. (The same sort of idea could be done for reindention, I'd hope.) I didn't just replace the instances of dog that were in my file at that moment. I conceptually replaced all instances, including ones that aren't there yet. Well yes, that's exactly what we want. And the key point of all of this is that there's no magic here. The darcs machinery does all the commutations such that the patches can wiggle together without conflicts. To do it's job, of course, it needs nuanced patches, rather than the quite literal ones generated by diff. We agree on everything except that it's provable that one can discover a replace operation, given a before and after tree. Now, I should mention here that I personally dislike the replace operation, and I think it is more dangerous than helpful. However, other darcs users are quite happy with it, and it certainly is a creative and powerful feature. It's creative alright, though I had the same misgivings. In my common code workflow, I almost never have global tokens -- all my replaces would be per function, so I never saw an opportunity to use it when I was screwing around with darcs. Other creative patch types have also been dreamed of. For example, a powerful language-specific refactoring operation has been discussed as a far-future possibility. That would be safe, and cool. subliminal indention patch type, indention patch type... /subliminal Automated refactoring tools, for example, perform the rename+modify as an atomic operation. [...] Although there are no such nifty refactoring tools available today, they will exist at some point. Yeah, I spent some time drooling over the refactoring editors before slapping myself and deciding I'd wait for others to live on that bleeding edge for a while. I've had to clean up too much code from other people. Even without tools, many shops have policies against checking in code that won't compile. If you rename a java class, you must simultaneously perform the rename and modify the class name inside. If you commit between those steps, it's broken. I'm trying hard to find a nice way to say that's silly. I'm failing. My suggestion in that case would be that the local coder commit many patches to a local repository, one of which is the rename. Then upon completion of the refactoring, the set of patches is committed to the group repository. Tags before and after preserve the repository's precondition that it always compiles. [I do realize that the kernel doesn't have java code, by the way.] Don't worry, I didn't think that you did :-). Ray - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] write-tree performance problems
On Tue, 19 Apr 2005, Linus Torvalds wrote: (*) Actually, I think it's the compression that ends up being the most expensive part. You're also using the equivalent of '-9', too -- and *that's slow*. Changing to Z_NORMAL_COMPRESSION would probably help a lot (but would break all existing repositories, sigh). --scott DES WTO Indonesia NRA LCPANGS supercomputer plastique class struggle AEFOX Pakistan ODEARL Secretary KUGOWN Cheney ODIBEX SDI AP JMMADD ( http://cscott.net/ ) - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
PB == Petr Baudis [EMAIL PROTECTED] writes: PB I'm wondering if doing PB if [ $(show-diff) ]; then PB git diff | git apply PB else PB checkout-cache -f -a PB fi PB would actually buy us some time; or, how common is it for people to have PB no local changes whatsoever, and whether relative slowdown of additional PB show-diff to git diff would actually matter. show-diff -s perhaps. Also wouldn't it be faster to pipe show-diff output (not git diff output) to patch (not git apply)? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SHA1 hash safety
On Tue, 19 Apr 2005, David Meybohm wrote: But doesn't this require assuming the distribution of MD5 is uniform, and don't the papers finding collisions in less show it's not? So, your birthday-argument for calculating the probability wouldn't apply, because it rests on the assumption MD5 is uniform, and it isn't. No, the collision papers don't show this at all. --scott atomic strategic HBDRILL SARANAC COBRA JUDY Ft. Meade assassination politics Mossad HOPEFUL ZPSEMANTIC DTFROGS HTKEEPER LITEMPO LIONIZER operation ( http://cscott.net/ ) - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [script] ge: export commits as patches
Petr Baudis wrote: Dear diary, on Tue, Apr 19, 2005 at 03:48:43PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... is there any 'export commit as patch' support in git-pasky? Nice idea. I will add it, probably as 'git patch'. Eek! It's a nice idea, and it'd be great as a subcommand. But PLEASE don't name it patch. I already know what patch does, patch ACCEPTS a patch... it doesn't create one ;-). How about naming it aspatch or asdiff instead? Or something else (good names, anyone?). soapbox_to_choirGood externally-viewed names are critical... good command names that are similar to what people already know can really help make the tool a joy to use./soapbox_to_choir --- David A. Wheeler - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
Ray Lee wrote: Here's where we disagree. If you checkpoint your tree before the replace, and immediately after, the only differences in the source-controlled files would be due to the replace. This is assuming that you only have one replace and no other operations recorded in the patch. If you have multiple replaces or a replace and a traditional diff recorded in the same patch, then this is not true. And since the language of the file is known (and thereby the tokenization -- it *is* well-defined), then a tokenizer that compares the before and after trees (for just the files that changed, obviously), can discover what you did, and promote the mere ASCII diff into a token-replace diff. (The same sort of idea could be done for reindention, I'd hope.) See above for one set of limitations on this. A more fundamental problem comes back to intent. If I have a file foo before: a1 a2 and after: b1 b2 is that a replace [_a-zA-Z0-9] a b foo patch, or is that a -a1 -a2 +b1 +b2 patch? Note that this comes down to heuristics, and no matter what you use, you will be wrong sometimes, *and* the choice that is made can substantively affect the contents of the repository after additional patches are applied. We agree on everything except that it's provable that one can discover a replace operation, given a before and after tree. It's provable that you can not. -Tupshin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 12:45:02AM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... PB == Petr Baudis [EMAIL PROTECTED] writes: PB I'm wondering if doing PB if [ $(show-diff) ]; then PB git diff | git apply PB else PB checkout-cache -f -a PB fi PB would actually buy us some time; or, how common is it for people to have PB no local changes whatsoever, and whether relative slowdown of additional PB show-diff to git diff would actually matter. show-diff -s perhaps. Also wouldn't it be faster to pipe show-diff output (not git diff output) to patch (not git apply)? Excellent idea, thanks. Changed git merge to do this. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tuesday 19 April 2005 04:38 pm, Linus Torvalds wrote: On Tue, 19 Apr 2005, Steven Cole wrote: But perhaps a progress bar right about here might be a good thing for the terminally impatient. real3m54.909s user0m14.835s sys 0m10.587s 4 minutes might be long enough to cause some folks to lose hope. Well, the real operations took only 15 seconds. What kind of horribe person are you, that you don't have all of the kernel in your disk cache already? Shame on you. Or was the 4 minutes for downloading all the objest too? Yes, I was using a very recent version of the pasky tools, I had created the repo this morning with git init YOUR_RSYC_URL_FOR_LINUX-2.6. I did time git pull origin and watched the fur fly. Then, the flurry of patching file blah messages, followed by a rather pregnant pause after the last patching message. I wasn't complaining about the 4 minutes, just the lack of feedback during the majority of that time. And most of it was after the last patching file message. Anyway, it looks like you are using pasky's scripts, and the old patch-based upgrade at that. You certainly will _not_ see the [many files patched] patching file mm/mmap.c .. if you use a real git merge. That's probable be the real problem here. Real merges have no patches taking place _anywhere_. And they take about half a second. Doing an update of your tree should _literally_ boil down to # # repo needs to point to the repo we update from # rsync -avz --ignore-existing $repo/objects/. .git/objects/. rsync -L $repo/HEAD .git/NEW_HEAD || exit 1 read-tree -m $(cat .git/NEW_HEAD) || exit 1 checkout-cache -f -a update-cache --refresh mv .git/NEW_HEAD .git/HEAD and if it does anything else, it's literally broken. Btw, the above does need my read-tree -m thing which I committed today. (CAREFUL: the above is not a good script, because it _will_ just overwrite all your old contents with the stuff you updated to. You should thus not actually use something like this, but a git update should literally end up doing the above operations in the end, and just add proper checking). And if that takes 4 minutes, you've got problems. Just say no to patches. Linus PS: If you want a clean tree without any old files or anything else, for that matter, you can then do a show-files -z --others | xargs -0 rm, but be careful: that will blow away _anything_ that wasn't revision controlled with git. So don't blame me if your pr0n collection is gone afterwards. OK. I may try some of this tomorrow from work, where I have a fat pipe. I'm on dialup from home, and I suspect not very many folks want to hear the sad tale of how long it takes to get the kernel over 56k dialup. Steven - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] write-tree performance problems
On Tue, 19 Apr 2005, Chris Mason wrote: 5) right before exiting, write-tree updates the index if it made any changes. This part won't work. It needs to do the proper locking, which means that it needs to create index.lock _before_ it reads the index file, and write everything to that one and then do a rename. If it doesn't need to do the write, it can just remove index.lock without writing to it, obviously. The downside to this setup is that I've got to change other index users to deal with directory entries that are there sometimes and missing other times. The nice part is that I don't have to invalidate the directory entry, if it is present, it is valid. To me, the biggest downside is actually the complexity part, and worrying about the directory index ever getting stale. How big do the changes end up being? Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [darcs-devel] Darcs and git: plan of action
On Tue, 2005-04-19 at 10:22 +0200, Juliusz Chroboczek wrote: Aye, that will require some metadata on the git side (the hack, suggested by Linus, of using git hashes to notice moves won't work). So, why won't it work? Because two files can legitimately have identical contents without being ``the same'' file from the VC system's point of view. In other words, two files may happen to have the same contents but have distinct histories. Eh, let's not talk using integral/summation view across all the patches that ever could have come in against the file. We're hamstringing ourselves if we do that, and it's not what darcs does. darcs looks at a differential view of the changes, and for a mv, it looks at it when it happens. darcs does a darcs mv to commit a file move patch to whatever logging or patch repository it keeps below the surface. The equivalent in git would be to have a given tree, move a file via bash's mv, and then checkpoint a new tree. (I'm sure there's details in there, but that's plumbing, and what we have Petr for.) A differential comparison of the two trees shows no content changed, but a file label was modified. Ergo, a rename occurred. QED. ~r. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.
On Tue, 19 Apr 2005, Junio C Hamano wrote: Let's for a moment forget what git-pasky currently does, which is not to touch .git/index until the user says Ok, let's commit. I think git-pasky is wrong. It's true that we want to often (almost always) diff against the last released thing, and I actually think git-pasky does what it does because I never wrote a tool to diff the current working directory against a tree. At the same time, I very much worked with a model where you do _not_ have a traditional work file, but the index really _is_ the work file. I'd like to start from a different premise and see what happens: - What .git/index records is *not* the state as the last commit. It is just an cache Cogito uses to speed up access to the user's working tree. From the user's point of view, it does not even exist. Yes. Yes. YES. That is indeed the whole point of the index file. In my world-view, the index file does _everything_. It's the staging area (work file), it's the merging area (merge directory) and it's the cache file (stat cache). I'll immediately write a tool to diff the current working directory against a tree object, and hopefully that will just make pasky happy with this model too. Is there any other reason why git-pasky wants to have a work file? Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wit 0.0.3 - a web interface for git available
On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote: Hi, ok it's starting to look like spam ;-) I uploaded a new version of wit to http://www.absolutegiganten.org/wit Why not work together with Kay's tool: http://ehlo.org/~kay/gitweb.pl?project=linux-2.6action=show_log Thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] init-db.c cleanup and fixes
Linus, I see you pulled the first two patches of my last series into your tree, so I know I had your attention briefly. I wanted to see what I can do to help the rest of the changes get in, so I realized last night as I was going to bed that the third patch might not be accepted because it changes the behaviour slightly, nevermind that they were - by comparison with today's alternative - plain ugly. For what it's worth, init-db is practically useless for my package without the second change in this series. Currently, I've implemented init-db in pure perl, but I'd like to use init-db. As such, I started from scratch, and came up with a much simpler series of patches. Please continue to ignore the previous series, but consider these new patches in their stead. New GIT_FILE_DIRECTORY patches will follow seperately. Cheers, Zach Welch Superlucidity Services These patches were based off commit 4e1778c8ceeaea340a2a7f62fc65736da327ec05. There are 3 patches in this series: [PATCH 1/3] init-db.c: cleanup comments [PATCH 2/3] init-db.c: normalize env var handling. [PATCH 3/3] init-db.c: create and use safe_create_dir helper - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] init-db.c: normalize env var handling.
This patch applies on top of:
[PATCH 1/3] init-db.c: cleanup comments
init-db.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Normalize init-db environment variable handling, allowing the creation
of object directories with something other than DEFAULT_DB_ENVIRONMENT.
--- a/init-db.c
+++ b/init-db.c
@@ -22,15 +22,10 @@ int main(int argc, char **argv)
}
sha1_dir = getenv(DB_ENVIRONMENT);
- if (sha1_dir) {
- struct stat st;
- if (!stat(sha1_dir, st) S_ISDIR(st.st_mode))
- return 0;
- fprintf(stderr, DB_ENVIRONMENT set to bad directory %s: ,
sha1_dir);
+ if (!sha1_dir) {
+ sha1_dir = DEFAULT_DB_ENVIRONMENT;
+ fprintf(stderr, defaulting to local storage area\n);
}
-
- sha1_dir = DEFAULT_DB_ENVIRONMENT;
- fprintf(stderr, defaulting to private storage area\n);
len = strlen(sha1_dir);
if (mkdir(sha1_dir, 0755) 0) {
if (errno != EEXIST) {
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] init-db.c: create and use safe_create_dir helper
This patch applies on top of:
[PATCH 1/3] init-db.c: cleanup comments
[PATCH 2/3] init-db.c: normalize env var handling.
init-db.c | 30 ++
1 files changed, 14 insertions(+), 16 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Factor mkdir calls into common safe_create_dir subroutine.
--- a/init-db.c 2005-04-19 18:50:14.0 -0700
+++ b/init-db.c 2005-04-19 18:45:48.0 -0700
@@ -5,6 +5,16 @@
*/
#include cache.h
+void safe_create_dir(char *dir)
+{
+ if (mkdir(dir, 0755) 0) {
+ if (errno != EEXIST) {
+ perror(dir);
+ exit(1);
+ }
+ }
+}
+
/*
* If you want to, you can share the DB area with any number of branches.
* That has advantages: you can save space by sharing all the SHA1 objects.
@@ -16,10 +26,7 @@
char *sha1_dir, *path;
int len, i;
- if (mkdir(.git, 0755) 0) {
- perror(unable to create .git directory);
- exit(1);
- }
+ safe_create_dir(.git);
sha1_dir = getenv(DB_ENVIRONMENT);
if (!sha1_dir) {
@@ -27,22 +34,13 @@
fprintf(stderr, defaulting to local storage area\n);
}
len = strlen(sha1_dir);
- if (mkdir(sha1_dir, 0755) 0) {
- if (errno != EEXIST) {
- perror(sha1_dir);
- exit(1);
- }
- }
path = malloc(len + 40);
memcpy(path, sha1_dir, len);
+
+ safe_create_dir(sha1_dir);
for (i = 0; i 256; i++) {
sprintf(path+len, /%02x, i);
- if (mkdir(path, 0755) 0) {
- if (errno != EEXIST) {
- perror(path);
- exit(1);
- }
- }
+ safe_create_dir(path);
}
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.
On Tue, 19 Apr 2005, Linus Torvalds wrote: That is indeed the whole point of the index file. In my world-view, the index file does _everything_. It's the staging area (work file), it's the merging area (merge directory) and it's the cache file (stat cache). I'll immediately write a tool to diff the current working directory against a tree object, and hopefully that will just make pasky happy with this model too. Ok, immediately took a bit longer than I wanted to, and quite frankly, the end result is not very well tested. It was a bit more complex than I was hoping for to match up the index file against a tree object, since unlike the tree-tree comparison in diff-tree, you have to compare two cases where the layout isn't the same. No matter. It seems to work to a first approximation, and the result is such a cool tool that it's worth committing and pushing out immediately. The code ain't exactly pretty, but hey, maybe that's just me having higher standards of beauty than most. Or maybe you just shudder at what I consider pretty in the first place, in which case you probably shouldn't look too closely at this one. What the new diff-cache does is basically emulate diff-tree, except one of the trees is always the index file. You can also choose whether you want to trust the index file entirely (using the --cached flag) or ask the diff logic to show any files that don't match the stat state as being tentatively changed. Both of these operations are very useful indeed. For example, let's say that you have worked on your index file, and are ready to commit. You want to see eactly _what_ you are going to commit is without having to write a new tree object and compare it that way, and to do that, you just do diff-cache --cached $(cat .git/HEAD) (another difference between diff-tree and diff-cache is that the new diff-cache can take a commit object, and it automatically just extracts the tree information from there). Example: let's say I had renamed commit.c to git-commit.c, and I had done an upate-cache to make that effective in the index file. show-diff wouldn't show anything at all, since the index file matches my working directory. But doing a diff-cache does: [EMAIL PROTECTED]:~/git diff-cache --cached $(cat .git/HEAD) -100644 blob4161aecc6700a2eb579e842af0b7f22b98443f74commit.c +100644 blob4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c So what the above diff-cache command line does is to say show me the differences between HEAD and the current index contents (the ones I'd write with a write-tree) And as you can see, the output matches diff-tree -r output (we always do -r, since the index is always fully populated). All the same rules: + means added file, - means removed file, and * means changed file. You can trivially see that the above is a rename. In fact, diff-tree --cached _should_ always be entirely equivalent to actually doing a write-tree and comparing that. Except this one is much nicer for the case where you just want to check. Maybe you don't want to do the tree. So doing a diff-cache --cached is basically very useful when you are asking yourself what have I already marked for being committed, and what's the difference to a previous tree. However, the non-cached version takes a different approach, and is potentially the even more useful of the two in that what it does can't be emulated with a write-tree + diff-tree. Thus that's the default mode. The non-cached version asks the question show me the differences between HEAD and the currently checked out tree - index contents _and_ files that aren't up-to-date which is obviously a very useful question too, since that tells you what you _could_ commit. Again, the output matches the diff-tree -r output to a tee, but with a twist. The twist is that if some file doesn't match the cache, we don't have a backing store thing for it, and we use the magic all-zero sha1 to show that. So let's say that you have edited kernel/sched.c, but have not actually done an update-cache on it yet - there is no object associated with the new state, and you get: [EMAIL PROTECTED]:~/v2.6/linux diff-cache $(cat .git/HEAD ) *100644-100664 blob 7476bbcfe5ef5a1dd87d745f298b831143e4d77e- kernel/sched.c ie it shows that the tree has changed, and that kernel/sched.c has is not up-to-date and may contain new stuff. The all-zero sha1 means that to get the real diff, you need to look at the object in the working directory directly rather than do an object-to-object diff. NOTE! As with other commands of this type, diff-cache does not actually look at the contents of the file at all. So maybe kernel/sched.c hasn't actually changed, and it's just that you touched it. In either case, it's a note that you need to upate-cache it to make the cache be in sync. NOTE 2! You can have a mixture
[PATCH 1/3] add GIT_CACHE_DIRECTORY support
cache.h|3 +++
init-db.c |9 +++--
read-cache.c | 15 +--
read-tree.c| 35 ++-
update-cache.c | 33 -
5 files changed, 73 insertions(+), 22 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
This patch introduces the GIT_CACHE_DIRECTORY to the C plumbing.
Without this patch, the index file and its lock are always placed
in './.git'. Scripts wishing to run these commands from a different
working directory can use this support to override the cache directory.
This require my latest init-db cleanups be applied first, otherwise
you will get a rejection in init-db.c.
cache.h: 5948db759b3f6fb5ade3b027f202330f71a8cb6a
--- a/cache.h
+++ b/cache.h
@@ -81,6 +81,9 @@ const char *sha1_file_directory;
struct cache_entry **active_cache;
unsigned int active_nr, active_alloc;
+#define GIT_CACHE_ENVIRONMENT GIT_CACHE_DIRECTORY
+#define DEFAULT_GIT_CACHE_ENVIRONMENT .git
+
#define DB_ENVIRONMENT SHA1_FILE_DIRECTORY
#define DEFAULT_DB_ENVIRONMENT .git/objects
init-db.c: 14beb35657de229a61673198bfc4e009daafca15
--- a/init-db.c
+++ b/init-db.c
@@ -23,10 +23,15 @@ void safe_create_dir(char *dir)
*/
int main(int argc, char **argv)
{
- char *sha1_dir, *path;
+ char *sha1_dir, *path, *git_dir;
int len, i;
- safe_create_dir(.git);
+ git_dir = getenv(GIT_CACHE_ENVIRONMENT);
+ if (!git_dir) {
+ git_dir = DEFAULT_GIT_CACHE_ENVIRONMENT;
+ fprintf(stderr, defaulting to local cache area\n);
+ }
+ safe_create_dir(git_dir);
sha1_dir = getenv(DB_ENVIRONMENT);
if (!sha1_dir) {
read-cache.c: edaadf3e1c0714735ca8d80301dd644aa0f9cd2a
--- a/read-cache.c
+++ b/read-cache.c
@@ -174,22 +174,33 @@ static int verify_hdr(struct cache_heade
int read_cache(void)
{
- int fd, i;
+ int fd, i, len;
struct stat st;
unsigned long size, offset;
void *map;
struct cache_header *hdr;
+ char *index_path, *index_file;
errno = EBUSY;
if (active_cache)
return error(more than one cachefile);
errno = ENOENT;
+
sha1_file_directory = getenv(DB_ENVIRONMENT);
if (!sha1_file_directory)
sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
if (access(sha1_file_directory, X_OK) 0)
return error(no access to SHA1 file directory);
- fd = open(.git/index, O_RDONLY);
+
+ index_path = getenv(GIT_CACHE_ENVIRONMENT);
+ if (!index_path)
+ index_path = DEFAULT_GIT_CACHE_ENVIRONMENT;
+ len = strlen(index_path);
+ index_file = malloc(len + 7);
+ if (!index_file) error(out of memory);
+ sprintf(index_file, %s/index, index_path);
+
+ fd = open(index_file, O_RDONLY);
if (fd 0)
return (errno == ENOENT) ? 0 : error(open failed);
read-tree.c: 9bcba2d567e1c86ae967d383cc081e6947d00a13
--- a/read-tree.c
+++ b/read-tree.c
@@ -65,12 +65,12 @@ static int read_tree(unsigned char *sha1
return 0;
}
-static int remove_lock = 0;
+static char *index_lock = NULL;
static void remove_lock_file(void)
{
- if (remove_lock)
- unlink(.git/index.lock);
+ if (index_lock)
+ unlink(index_lock);
}
static int path_matches(struct cache_entry *a, struct cache_entry *b)
@@ -205,14 +205,27 @@ static void merge_stat_info(struct cache
int main(int argc, char **argv)
{
- int i, newfd, merge;
+ int i, newfd, len, merge;
unsigned char sha1[20];
-
- newfd = open(.git/index.lock, O_RDWR | O_CREAT | O_EXCL, 0600);
+ char *index_file, *index_path;
+
+ index_path = getenv(GIT_CACHE_ENVIRONMENT);
+ if (!index_path)
+ index_path = DEFAULT_GIT_CACHE_ENVIRONMENT;
+
+ len = strlen(index_path);
+ index_file = malloc(len + 7);
+ if (!index_file) error(out of memory);
+ sprintf(index_file, %s/index, index_path);
+
+ index_lock = malloc(len + 12);
+ if (!index_lock) error(out of memory);
+ sprintf(index_lock, %s/index.lock, index_path);
+
+ newfd = open(index_lock, O_RDWR | O_CREAT | O_EXCL, 0600);
if (newfd 0)
die(unable to create new cachefile);
atexit(remove_lock_file);
- remove_lock = 1;
merge = 0;
for (i = 1; i argc; i++) {
@@ -253,8 +266,12 @@ int main(int argc, char **argv)
}
}
if (write_cache(newfd, active_cache, active_nr) ||
- rename(.git/index.lock, .git/index))
+ rename(index_lock, index_file))
die(unable to write new index file);
- remove_lock = 0;
+
+ free(index_file);
+ free(index_lock);
+ index_lock = NULL;
+
return 0;
}
update-cache.c: 0d16b36d7d074e9f0a2811a40e16e9823a628ec9
--- a/update-cache.c
+++ b/update-cache.c
@@ -270,25
[PATCH 2/3] rename object directory symbols
This patch applies on top of:
[PATCH 1/3] add GIT_CACHE_DIRECTORY support
cache.h |4 ++--
fsck-cache.c |2 +-
init-db.c|4 ++--
ls-tree.c|4 ++--
read-cache.c |4 ++--
sha1_file.c |2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Rename the DB_ENVIRONMENT symbols to match the newly introduced
GIT_CACHE_ENVIROMENT symbols.
cache.h: 1fca894f485471d51c6a72c16e02df6d56d0052f
--- a/cache.h
+++ b/cache.h
@@ -84,8 +84,8 @@ unsigned int active_nr, active_alloc;
#define GIT_CACHE_ENVIRONMENT GIT_CACHE_DIRECTORY
#define DEFAULT_GIT_CACHE_ENVIRONMENT .git
-#define DB_ENVIRONMENT SHA1_FILE_DIRECTORY
-#define DEFAULT_DB_ENVIRONMENT .git/objects
+#define GIT_OBJECT_ENVIRONMENT SHA1_FILE_DIRECTORY
+#define DEFAULT_GIT_OBJECT_ENVIRONMENT .git/objects
#define alloc_nr(x) (((x)+16)*3/2)
fsck-cache.c: cf39b7e054d9685fde7004ec767cd098b97e8ce7
--- a/fsck-cache.c
+++ b/fsck-cache.c
@@ -135,7 +135,7 @@ int main(int argc, char **argv)
int i, heads;
char *sha1_dir;
- sha1_dir = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
+ sha1_dir = getenv(GIT_OBJECT_ENVIRONMENT) ? :
DEFAULT_GIT_OBJECT_ENVIRONMENT;
for (i = 0; i 256; i++) {
static char dir[4096];
sprintf(dir, %s/%02x, sha1_dir, i);
init-db.c: 9e693a0a914512c5574f394222cfc75496e3453a
--- a/init-db.c
+++ b/init-db.c
@@ -33,9 +33,9 @@ int main(int argc, char **argv)
}
safe_create_dir(git_dir);
- sha1_dir = getenv(DB_ENVIRONMENT);
+ sha1_dir = getenv(GIT_OBJECT_ENVIRONMENT);
if (!sha1_dir) {
- sha1_dir = DEFAULT_DB_ENVIRONMENT;
+ sha1_dir = DEFAULT_GIT_OBJECT_ENVIRONMENT;
fprintf(stderr, defaulting to local storage area\n);
}
len = strlen(sha1_dir);
ls-tree.c: 936bb19a5525046a5a784d5f14c3ea7da406cc62
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -105,9 +105,9 @@ int main(int argc, char **argv)
usage(ls_tree_usage);
if (get_sha1_hex(argv[1], sha1) 0)
usage(ls_tree_usage);
- sha1_file_directory = getenv(DB_ENVIRONMENT);
+ sha1_file_directory = getenv(GIT_OBJECT_ENVIRONMENT);
if (!sha1_file_directory)
- sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
+ sha1_file_directory = DEFAULT_GIT_OBJECT_ENVIRONMENT;
if (list(sha1) 0)
die(list failed);
return 0;
read-cache.c: 9eee23097b9406548765ec6fc77e61788317df19
--- a/read-cache.c
+++ b/read-cache.c
@@ -186,9 +186,9 @@ int read_cache(void)
return error(more than one cachefile);
errno = ENOENT;
- sha1_file_directory = getenv(DB_ENVIRONMENT);
+ sha1_file_directory = getenv(GIT_OBJECT_ENVIRONMENT);
if (!sha1_file_directory)
- sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
+ sha1_file_directory = DEFAULT_GIT_OBJECT_ENVIRONMENT;
if (access(sha1_file_directory, X_OK) 0)
return error(no access to SHA1 file directory);
sha1_file.c: c4591cd2168ae2e42c1fc9878be8befbfa1a8afa
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -61,7 +61,7 @@ char *sha1_file_name(const unsigned char
static char *name, *base;
if (!base) {
- char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? :
DEFAULT_DB_ENVIRONMENT;
+ char *sha1_file_directory = getenv(GIT_OBJECT_ENVIRONMENT) ? :
DEFAULT_GIT_OBJECT_ENVIRONMENT;
int len = strlen(sha1_file_directory);
base = malloc(len + 60);
memcpy(base, sha1_file_directory, len);
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] rename SHA1_FILE_DIRECTORY
This patch applies on top of: [PATCH 1/3] add GIT_CACHE_DIRECTORY support [PATCH 2/3] rename object directory symbols cache.h |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Signed-Off-By: Zach Welch [EMAIL PROTECTED] Rename SHA1_FILE_DIRECTORY to GIT_OBJECT_DIRECTORY. Scripts that used to pass this setting will need to be updated. cache.h: 218bec12fab3fb57ad03fafccedd4398c64c3646 --- a/cache.h +++ b/cache.h @@ -84,7 +84,7 @@ unsigned int active_nr, active_alloc; #define GIT_CACHE_ENVIRONMENT GIT_CACHE_DIRECTORY #define DEFAULT_GIT_CACHE_ENVIRONMENT .git -#define GIT_OBJECT_ENVIRONMENT SHA1_FILE_DIRECTORY +#define GIT_OBJECT_ENVIRONMENT GIT_OBJECT_DIRECTORY #define DEFAULT_GIT_OBJECT_ENVIRONMENT .git/objects #define alloc_nr(x) (((x)+16)*3/2) - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] init-db.c: normalize env var handling.
On Tue, 19 Apr 2005, Zach Welch wrote: This patch applies on top of: [PATCH 1/3] init-db.c: cleanup comments init-db.c | 11 +++ 1 files changed, 3 insertions(+), 8 deletions(-) Signed-Off-By: Zach Welch [EMAIL PROTECTED] Normalize init-db environment variable handling, allowing the creation of object directories with something other than DEFAULT_DB_ENVIRONMENT. --- a/init-db.c +++ b/init-db.c For future reference, this is in the wrong order. You should have checkin comment first, then signed-off-by, then a line with three dashes, and then administrative trivia. Ie I'd much rather see the email look like Normalize init-db environment variable handling, allowing the creation of object directories with something other than DEFAULT_DB_ENVIRONMENT. Signed-Off-By: Zach Welch [EMAIL PROTECTED] --- This patch applies on top of: [PATCH 1/3] init-db.c: cleanup comments init-db.c | 11 +++ 1 files changed, 3 insertions(+), 8 deletions(-) .. actual patch goes here .. since otherwise I'll just have to edit it that way. I like seeing the administrative stuff (diffstat etc), but I don't want to have it in the commit message, and that's exactly what the --- marker is for - my tools will automatically cut it off as if it was a signature (or the beginning of the patch). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] init-db.c: normalize env var handling.
Linus Torvalds wrote: For future reference, this is in the wrong order. I feel even more abashed for my earlier scripting faux pas. Would you like me to resend them to you off-list? Cheers, Zach - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] init-db.c: normalize env var handling.
On Tue, 19 Apr 2005, Zach Welch wrote: I feel even more abashed for my earlier scripting faux pas. Would you like me to resend them to you off-list? No, I edited them and applied them (the first series, I'll have to think about the second one). It's only when there are tens of patches that it gets really old really quickly to edit things by hand. Three I can handle ;) Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
