* Re: Change "pull" to _only_ download, and "git update"=pull+merge?
From: David Greaves @ 2005-04-19 9:18 UTC (permalink / raw)
To: dwheeler; +Cc: Petr Baudis, Daniel Barkalow, git
In-Reply-To: <42646967.9030903@dwheeler.com>
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
--
^ permalink raw reply
* [PATCH 7/8] read-tree.c: add INDEX_FILE_DIRECTORY support
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
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 <zw@superlucidity.net>
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;
}
^ permalink raw reply
* [PATCH 6/8] read-cache.c: add INDEX_FILE_DIRECTORY support
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
This patch give read-cache 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
read-cache.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
Signed-Off-By: Zach Welch <zw@superlucidity.net>
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(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);
+
+ fd = open(index_file, O_RDONLY);
if (fd < 0)
return (errno == ENOENT) ? 0 : error("open failed");
^ permalink raw reply
* [PATCH 8/8] update-cache.c: add INDEX_FILE_DIRECTORY support
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
This patch give update-cache 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
[PATCH 7/8] read-tree.c: add INDEX_FILE_DIRECTORY support
update-cache.c | 33 ++++++++++++++++++++++++---------
1 files changed, 24 insertions(+), 9 deletions(-)
Signed-Off-By: Zach Welch <zw@superlucidity.net>
update-cache.c: 0d16b36d7d074e9f0a2811a40e16e9823a628ec9
--- a/update-cache.c
+++ b/update-cache.c
@@ -270,25 +270,37 @@ static int add_cacheinfo(char *arg1, cha
return add_cache_entry(ce, allow_add);
}
-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);
}
int main(int argc, char **argv)
{
- int i, newfd, entries;
+ int i, newfd, entries, len;
int allow_options = 1;
+ 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;
entries = read_cache();
if (entries < 0)
@@ -330,9 +342,12 @@ int main(int argc, char **argv)
die("Unable to add %s to database", path);
}
if (write_cache(newfd, active_cache, active_nr) ||
- rename(".git/index.lock", ".git/index"))
+ rename(index_lock, index_file))
die("Unable to write new cachefile");
- remove_lock = 0;
+ free(index_file);
+ free(index_lock);
+ index_lock = NULL;
+
return 0;
}
^ permalink raw reply
* [PATCH 5/8] init-db.c: refactor mkdir logic
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
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 <zw@superlucidity.net>
--- a/init-db.c 2005-04-19 01:36:58.000000000 -0700
+++ b/init-db.c 2005-04-19 01:37:03.000000000 -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;
}
^ permalink raw reply
* [PATCH 4/8] init-db.c: add INDEX_FILE_DIRECTORY support
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
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 <zw@superlucidity.net>
--- a/cache.h 2005-04-18 21:13:36.000000000 -0700
+++ b/cache.h 2005-04-18 21:13:44.000000000 -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.000000000 -0700
+++ b/init-db.c 2005-04-18 21:15:14.000000000 -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);
^ permalink raw reply
* [PATCH 3/8] init-db.c: refactor directory creation
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
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 <zw@superlucidity.net>
--- 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++) {
^ permalink raw reply
* [PATCH 2/8] init-db.c: [RESEND] make init-db work with common objects
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
This makes init-db work for common object database.
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
init-db.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-Off-By: Zach Welch <zw@superlucidity.net>
Signed-Off-By: Aaron Straus <aaron@merfinllc.com>
Author: Aaron Straus <aaron@merfinllc.com>
init-db.c: aa00fbb1b95624f6c30090a17354c9c08a6ac596
--- a/init-db.c
+++ b/init-db.c
@@ -24,7 +24,7 @@ int main(int argc, char **argv)
sha1_dir = getenv(DB_ENVIRONMENT);
if (sha1_dir) {
struct stat st;
- if (!stat(sha1_dir, &st) < 0 && S_ISDIR(st.st_mode))
+ if (!stat(sha1_dir, &st) && S_ISDIR(st.st_mode))
return 0;
fprintf(stderr, "DB_ENVIRONMENT set to bad directory %s: ", sha1_dir);
}
^ permalink raw reply
* [PATCH 1/8] init-db.c: [RESEND] remove redundant getenv call
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
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 <zw@superlucidity.net>
Signed-Off-By: Tony Luck <tony.luck@intel.com>
--- a/init-db.c 2005-04-14 11:01:52.000000000 -0700
+++ b/init-db.c 2005-04-14 11:01:52.000000000 -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) {
-
^ permalink raw reply
* [PATCH 0/8] init-db.c cleanup, add INDEX_FILE_DIRECTORY support
From: Zach Welch @ 2005-04-19 9:09 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* Re: More git pull problems
From: Petr Baudis @ 2005-04-19 8:35 UTC (permalink / raw)
To: Russell King; +Cc: Git
In-Reply-To: <20050419093113.D13488@flint.arm.linux.org.uk>
Dear diary, on Tue, Apr 19, 2005 at 10:31:13AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> 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 <rmk@arm.linux.org.uk> 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.
Yes, the way to store this information changed. But by now, it [the
$orig_head which caused the havoc] is completely informational anyway
and git pull is completely rewritten not to need it for the merging
itself; just for the fancy stuff like showing diff-tree.
If I go for the pull/update change (or even if I don't), I might drop
this information anyway; I basically needed it only before merge-base
was around anyway, so that I would know what tree to use as the merge
base.
> Maybe gitmerge.sh should check whether it needs to do anything before
> attempting to do something?
That's the case with the latest git-pasky night version.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: full kernel history, in patchset format
From: Catalin Marinas @ 2005-04-19 8:33 UTC (permalink / raw)
To: David Mansfield; +Cc: Ingo Molnar, git
In-Reply-To: <426437A2.7080903@cobite.com>
David Mansfield <david@cobite.com> 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-kernel&m=110026570201544&w=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
^ permalink raw reply
* Re: More git pull problems
From: Russell King @ 2005-04-19 8:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git
In-Reply-To: <20050419082341.GC2393@pasky.ji.cz>
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 <rmk@arm.linux.org.uk> 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
^ permalink raw reply
* Re: More git pull problems
From: Petr Baudis @ 2005-04-19 8:23 UTC (permalink / raw)
To: Russell King; +Cc: Git
In-Reply-To: <20050419080251.A11988@flint.arm.linux.org.uk>
Dear diary, on Tue, Apr 19, 2005 at 09:02:51AM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> 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
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Juliusz Chroboczek @ 2005-04-19 8:22 UTC (permalink / raw)
To: Ray Lee; +Cc: darcs-devel, Git Mailing List
In-Reply-To: <1113874991.23938.113.camel@orca.madrabbit.org>
> > 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
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: Russell King @ 2005-04-19 8:18 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050419004548.GA21623@kroah.com>
On Mon, Apr 18, 2005 at 05:45:48PM -0700, Greg KH wrote:
> On Mon, Apr 18, 2005 at 05:31:16PM -0700, Linus Torvalds wrote:
> >
> >
> > On Mon, 18 Apr 2005, Greg KH wrote:
> > >
> > > Here's a small patch to commit-tree.c that does two things:
> >
> > Gaah, I really was hoping that people wouldn't feel like they have to lie
> > about their committer information.
> >
> > I guess we don't have much choice, but I'm not happy about it.
>
> Well Russell has stated that he has to for EU Privacy reasons.
That's author information, not committer information. For my committing
purposes, I'm going to be the one doing the commit, and I'm unlikely to
issue a suit on myself for spreading my own personal information.
--
Russell King
^ permalink raw reply
* Re: "True" git merge in git-pasky
From: Petr Baudis @ 2005-04-19 8:09 UTC (permalink / raw)
To: bert hubert; +Cc: git
In-Reply-To: <20050419054307.GA1528@outpost.ds9a.nl>
Dear diary, on Tue, Apr 19, 2005 at 07:43:07AM CEST, I got a letter
where bert hubert <ahu@ds9a.nl> 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
^ permalink raw reply
* A VFS layer - was: SCM ideas from 2003
From: Jon Seymour @ 2005-04-19 8:07 UTC (permalink / raw)
To: Marc Girod, git
In-Reply-To: <u0tkboecbuybl.fsf@merleau.ntc.nokia.com>
On 19 Apr 2005 08:31:42 +0300, Marc Girod <girod@shire.ntc.nokia.com> wrote:
> >>>>> "KS" == Kevin Smith <yarcs@qualitycode.com> 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...
>
Of course, it is not just SCM's that are "blinded" by file orientation
- every other tool (editors, compilters, etc) that we use has this
orientation. An SCM really has to have some notion of file
orientation, at least at the UI level, because every other tool we use
has the same orientation. The ENVY/VisualAge environments tried to
work with a pure class-level orientation and in some ways that was
great, but most developers hated it precisely because it removed the
file orientation and hence their ability to work with their favourite
tools. IBM/OTI saw the light which is why Eclipse is avowedly a
file-oriented platform.
It seems to me that file-orientation is here to stay and it would be
really cool to layer some kind of virtual filesystem over the git
repository so that different trees become transparently accessible via
different branches of a file system, e.g.:
/mnt/gitfs/working # some kind of writeable
virtual directory over the git cache
/mnt/gitfs/c157067185209b50b350571fe762c2740ea13fc1 # read-only
tree of commit c157...
/mnt/gitfs/5b53d3a08d64198d26d4f2323f235790c04aeaab # read-only
tree of comit 5b53...
Given the purity of Linus' concept and his natural orientation towards
file systems rather than SCMs, this seems like a rather natural thing
to do. If anyone is planning to do this and wants a helper, count me
in!
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: SCM ideas from 2003
From: Marc Girod @ 2005-04-19 5:31 UTC (permalink / raw)
To: git
In-Reply-To: <42647D3D.6030906@qualitycode.com>
>>>>> "KS" == Kevin Smith <yarcs@qualitycode.com> 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 Girod P.O. Box 323 Voice: +358-71 80 25581
Nokia BI 00045 NOKIA Group Mobile: +358-50 38 78415
Valimo 21 / B616 Finland Fax: +358-71 80 64474
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-19 7:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050418230941.GN5554@pasky.ji.cz>
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
^ permalink raw reply
* More git pull problems
From: Russell King @ 2005-04-19 7:02 UTC (permalink / raw)
To: Git
In-Reply-To: <E1DNlmx-00029W-L2@flint.arm.linux.org.uk>
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)
> MOTD:
> MOTD: Welcome to the Linux Kernel Archive.
> MOTD:
> MOTD: Due to U.S. Exports Regulations, all cryptographic software on this
> MOTD: site is subject to the following legal notice:
> MOTD:
> MOTD: This site includes publicly available encryption source code
> MOTD: which, together with object code resulting from the compiling of
> MOTD: publicly available source code, may be exported from the United
> MOTD: States under License Exception "TSU" pursuant to 15 C.F.R. Section
> MOTD: 740.13(e).
> MOTD:
> MOTD: This legal notice applies to cryptographic software only.
> MOTD: Please see the Bureau of Industry and Security,
> MOTD: http://www.bis.doc.gov/ for more information about current
> MOTD: U.S. regulations.
> MOTD:
>
>
> rsync: link_stat "/linux/kernel/people/torvalds/sparse.git/tags" (in pub) failed: No such file or directory (2)
> rsync error: some files could not be transferred (code 23) at main.c(723)
>
> client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
> New branch: 945a2562ee9e632bc6b3399fd49e028c39d19023
> Tracked branch, applying changes...
> Fast-forwarding 945a2562ee9e632bc6b3399fd49e028c39d19023 -> 945a2562ee9e632bc6b3399fd49e028c39d19023
> on top of 945a2562ee9e632bc6b3399fd49e028c39d19023...
> gitdiff.sh: trying to diff 67607f05a66e36b2f038c77cfb61350d2110f7e8 against itself
--
Russell King
^ permalink raw reply
* Re: "True" git merge in git-pasky
From: bert hubert @ 2005-04-19 5:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050419035107.GB5554@pasky.ji.cz>
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?
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* Re: [1/4] Report info from trees
From: Daniel Barkalow @ 2005-04-19 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vsm1nqr6x.fsf@assigned-by-dhcp.cox.net>
On Mon, 18 Apr 2005, Junio C Hamano wrote:
> ... what about names? When somebody other than connectivity
> checker walks a tree, it would be more likely than not that
> it wants to know what each entry is called, wound't it?
Yes; just add the name to the tree_entry_list.
> I can get the type of the object, either tree or blob, from
> tree->object.type, so I do not think the single-bit are needed.
You still need the mode bit (executable or not); also, the current code
can't create an object without being told in advance what it is, so you
need to use the directory bit.
> Instead, how about something simpler like this?
>
> struct tree {
> struct object object; /* the tree node itself as an object */
> unsigned child_nr;
> unsigned child_alloc;
> struct {
> struct object *object;
> char *name;
> } **child;
> };
I think the linked list is easier to deal with, and matches the other code
better.
> The tree->child[n].object would point at the same object as one
> of the object_list elements in tree->object.refs chain (i.e. you
> do not need to read the same object twice).
The object code handles causing lookup_* to return the same object every
time, so this isn't an issue. Note that each struct object has to be
embedded in a struct <type> of the appropriate type, which means that we
can only create a struct object by either knowing what type it is supposed
to be or actually reading the file to find out what it actually is.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Automerge fix
From: Junio C Hamano @ 2005-04-19 5:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504181945400.15725@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> What's the right way?
LT> Maybe
LT> if merge "$src2" "$orig" "$src1"
LT> then
LT> cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
LT> fi
LT> echo Leaving conflict merge in $src2
LT> exit 1
LT> would work?
Wouldn't this be more readable, short and sweet?
merge "$src2" "$orig" "$src1" || {
echo Leaving conflict merge in $src2 && exit 1
}
cp "$src2" "$4" && exec update-cache --add -- "$4"
You did not want subshell so I just changed the () pair to the
{} pair, and while I was at it I folded the "&& exit 0" into the
last command before it, which should be better. You'd want to
know if update-cache --add failed for whatever reason.
^ permalink raw reply
* Re: [1/4] Report info from trees
From: Junio C Hamano @ 2005-04-19 5:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.21.0504182148330.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> This patch adds actual information to struct tree, making it possible to
DB> tell what sorts of things the referenced objects are. This is needed for
DB> http-pull, and Junio wanted something of the sort.
Thanks for keeping me in the loop, but...
DB> --- 1172a9b8f45b2fd640985595cc5258db3b027828/tree.h (mode:100644 sha1:14ebbacded09d5e058c7f94652dcb9e12bc31cae)
DB> +++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/tree.h (mode:100644 sha1:985500e2a9130fe8c33134ca121838af9320c465)
DB> @@ -5,9 +5,20 @@
DB> extern const char *tree_type;
DB> +struct tree_entry_list {
DB> + struct tree_entry_list *next;
DB> + unsigned directory : 1;
DB> + unsigned executable : 1;
DB> + union {
DB> + struct tree *tree;
DB> + struct blob *blob;
DB> + } item;
DB> +};
DB> +
DB> struct tree {
DB> struct object object;
DB> unsigned has_full_path : 1;
DB> + struct tree_entry_list *entries;
DB> };
... what about names? When somebody other than connectivity
checker walks a tree, it would be more likely than not that
it wants to know what each entry is called, wound't it?
I can get the type of the object, either tree or blob, from
tree->object.type, so I do not think the single-bit are needed.
Instead, how about something simpler like this?
struct tree {
struct object object; /* the tree node itself as an object */
unsigned child_nr;
unsigned child_alloc;
struct {
struct object *object;
char *name;
} **child;
};
The tree->child[n].object would point at the same object as one
of the object_list elements in tree->object.refs chain (i.e. you
do not need to read the same object twice). Before the tree is
parsed, tree->child would be NULL. You do not need child_alloc
if the intended use of this API is only parsing existing object
tree. Otherwise keep that and realloc tree->child as needed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox