* [PATCH 10] autoconf: Write how to use ./configure generated file in git build process
From: Jakub Narebski @ 2006-06-30 12:39 UTC (permalink / raw)
To: git
In-Reply-To: <200606301437.52590.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Probably there is better way to do this.
configure.ac | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index e387f5b..ef310ee 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,3 +54,9 @@ AC_CONFIG_FILES(["${config_file}":"${con
AC_OUTPUT
rm -f "${config_append}"
+
+cat <<_ACEOF
+
+Add '-include ${config_file}' to your config.mak,
+or rename ${config_file} to config.mak
+_ACEOF
--
1.4.0
^ permalink raw reply related
* [PATCH 11] autoconf: Rename ./configure output file to config.mak.autogen
From: Jakub Narebski @ 2006-06-30 12:41 UTC (permalink / raw)
To: git
In-Reply-To: <200606301439.40584.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Choose the name you are more comfortable with
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index ef310ee..f01fc17 100644
--- a/configure.ac
+++ b/configure.ac
@@ -6,7 +6,7 @@ AC_INIT([git], [1.4.0], [git@vger.kernel
AC_CONFIG_SRCDIR([git.c])
-config_file=config.mak.auto
+config_file=config.mak.autogen
config_append=config.mak.append
config_in=config.mak.in
--
1.4.0
^ permalink raw reply related
* Re: [PATCH 4/4] save another call to git-update-index
From: Johannes Schindelin @ 2006-06-30 14:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606300235300.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Fri, 30 Jun 2006, Johannes Schindelin wrote:
> FYI I've been just battling this pipe for a couple of hours. The first
> steps were easy, but since I wanted to do it incrementally, the index has
> to be written every so often, and I seem not to be able to get that right.
I just finished it. See my upcoming series of three patches. These apply
on top of your last cumulative patch (sometimes yesterday), although I am
certain we can merge our efforts.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Johannes Schindelin @ 2006-06-30 14:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606300235300.29667@wbgn013.biozentrum.uni-wuerzburg.de>
These functions will be useful for the inbuilt merge-recursive.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
cache.h | 2 ++
read-cache.c | 57 +++++++++++++++++++++++++++++++++++++++------------------
2 files changed, 41 insertions(+), 18 deletions(-)
diff --git a/cache.h b/cache.h
index 8719939..a5343db 100644
--- a/cache.h
+++ b/cache.h
@@ -142,7 +142,9 @@ #define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
extern int read_cache(void);
+extern int read_cache_from(const char *path);
extern int write_cache(int newfd, struct cache_entry **cache, int entries);
+extern int discard_cache(void);
extern int verify_path(const char *path);
extern int cache_name_pos(const char *name, int namelen);
#define ADD_CACHE_OK_TO_ADD 1 /* Ok to add */
diff --git a/read-cache.c b/read-cache.c
index 3c32aae..04d2ec7 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -24,6 +24,9 @@ unsigned int active_nr = 0, active_alloc
struct cache_tree *active_cache_tree = NULL;
+static void *cache_mmap = NULL;
+static size_t cache_mmap_size = 0;
+
/*
* This only updates the "non-critical" parts of the directory
* cache, ie the parts that aren't tracked by GIT, and only used
@@ -729,39 +732,43 @@ static int read_index_extension(const ch
int read_cache(void)
{
+ return read_cache_from(get_index_file());
+}
+
+/* remember to discard_cache() before reading a different cache! */
+int read_cache_from(const char *path)
+{
int fd, i;
struct stat st;
- unsigned long size, offset;
- void *map;
+ unsigned long offset;
struct cache_header *hdr;
errno = EBUSY;
- if (active_cache)
+ if (cache_mmap)
return active_nr;
errno = ENOENT;
index_file_timestamp = 0;
- fd = open(get_index_file(), O_RDONLY);
+ fd = open(path, O_RDONLY);
if (fd < 0) {
if (errno == ENOENT)
return 0;
die("index file open failed (%s)", strerror(errno));
}
- size = 0; // avoid gcc warning
- map = MAP_FAILED;
+ cache_mmap = MAP_FAILED;
if (!fstat(fd, &st)) {
- size = st.st_size;
+ cache_mmap_size = st.st_size;
errno = EINVAL;
- if (size >= sizeof(struct cache_header) + 20)
- map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
+ if (cache_mmap_size >= sizeof(struct cache_header) + 20)
+ cache_mmap = mmap(NULL, cache_mmap_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
}
close(fd);
- if (map == MAP_FAILED)
+ if (cache_mmap == MAP_FAILED)
die("index file mmap failed (%s)", strerror(errno));
- hdr = map;
- if (verify_hdr(hdr, size) < 0)
+ hdr = cache_mmap;
+ if (verify_hdr(hdr, cache_mmap_size) < 0)
goto unmap;
active_nr = ntohl(hdr->hdr_entries);
@@ -770,12 +777,12 @@ int read_cache(void)
offset = sizeof(*hdr);
for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce = (struct cache_entry *) ((char *) map + offset);
+ struct cache_entry *ce = (struct cache_entry *) ((char *) cache_mmap + offset);
offset = offset + ce_size(ce);
active_cache[i] = ce;
}
index_file_timestamp = st.st_mtime;
- while (offset <= size - 20 - 8) {
+ while (offset <= cache_mmap_size - 20 - 8) {
/* After an array of active_nr index entries,
* there can be arbitrary number of extended
* sections, each of which is prefixed with
@@ -783,10 +790,10 @@ int read_cache(void)
* in 4-byte network byte order.
*/
unsigned long extsize;
- memcpy(&extsize, (char *) map + offset + 4, 4);
+ memcpy(&extsize, (char *) cache_mmap + offset + 4, 4);
extsize = ntohl(extsize);
- if (read_index_extension(((const char *) map) + offset,
- (char *) map + offset + 8,
+ if (read_index_extension(((const char *) cache_mmap) + offset,
+ (char *) cache_mmap + offset + 8,
extsize) < 0)
goto unmap;
offset += 8;
@@ -795,11 +802,25 @@ int read_cache(void)
return active_nr;
unmap:
- munmap(map, size);
+ munmap(cache_mmap, cache_mmap_size);
errno = EINVAL;
die("index file corrupt");
}
+int discard_cache()
+{
+ int ret;
+
+ if (cache_mmap == NULL)
+ return 0;
+ ret = munmap(cache_mmap, cache_mmap_size);
+ cache_mmap = NULL;
+ cache_mmap_size = 0;
+ active_nr = active_cache_changed = 0;
+ /* no need to throw away allocated active_cache */
+ return ret;
+}
+
#define WRITE_BUFFER_SIZE 8192
static unsigned char write_buffer[WRITE_BUFFER_SIZE];
static unsigned long write_buffer_len;
--
1.4.1.rc1.gb2d14
^ permalink raw reply related
* [PATCH 2/3] Make refresh_cache_entry() public
From: Johannes Schindelin @ 2006-06-30 14:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606300235300.29667@wbgn013.biozentrum.uni-wuerzburg.de>
This renames refresh_entry() to refresh_cache_entry(), to make clashes
more unlikely, and makes it public. It also rethinks the rather awkward
way to pass an error: this is done by returning a NULL pointer and setting
cache_errno now.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
cache.h | 2 ++
read-cache.c | 44 +++++++++++++++++---------------------------
2 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/cache.h b/cache.h
index a5343db..a59b319 100644
--- a/cache.h
+++ b/cache.h
@@ -115,6 +115,7 @@ #define cache_entry_size(len) ((offsetof
extern struct cache_entry **active_cache;
extern unsigned int active_nr, active_alloc, active_cache_changed;
extern struct cache_tree *active_cache_tree;
+extern int cache_errno;
#define GIT_DIR_ENVIRONMENT "GIT_DIR"
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
@@ -151,6 +152,7 @@ #define ADD_CACHE_OK_TO_ADD 1 /* Ok to
#define ADD_CACHE_OK_TO_REPLACE 2 /* Ok to replace file/directory */
#define ADD_CACHE_SKIP_DFCHECK 4 /* Ok to skip DF conflict checks */
extern int add_cache_entry(struct cache_entry *ce, int option);
+extern struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really);
extern int remove_cache_entry_at(int pos);
extern int remove_file_from_cache(const char *path);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
diff --git a/read-cache.c b/read-cache.c
index 04d2ec7..1c0fc8b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -24,6 +24,8 @@ unsigned int active_nr = 0, active_alloc
struct cache_tree *active_cache_tree = NULL;
+int cache_errno = 0;
+
static void *cache_mmap = NULL;
static size_t cache_mmap_size = 0;
@@ -580,22 +582,6 @@ int add_cache_entry(struct cache_entry *
return 0;
}
-/* Three functions to allow overloaded pointer return; see linux/err.h */
-static inline void *ERR_PTR(long error)
-{
- return (void *) error;
-}
-
-static inline long PTR_ERR(const void *ptr)
-{
- return (long) ptr;
-}
-
-static inline long IS_ERR(const void *ptr)
-{
- return (unsigned long)ptr > (unsigned long)-1000L;
-}
-
/*
* "refresh" does not calculate a new sha1 file or bring the
* cache up-to-date for mode/content changes. But what it
@@ -607,14 +593,16 @@ static inline long IS_ERR(const void *pt
* For example, you'd want to do this after doing a "git-read-tree",
* to link up the stat cache details with the proper files.
*/
-static struct cache_entry *refresh_entry(struct cache_entry *ce, int really)
+struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really)
{
struct stat st;
struct cache_entry *updated;
int changed, size;
- if (lstat(ce->name, &st) < 0)
- return ERR_PTR(-errno);
+ if (lstat(ce->name, &st) < 0) {
+ cache_errno = errno;
+ return NULL;
+ }
changed = ce_match_stat(ce, &st, really);
if (!changed) {
@@ -622,11 +610,13 @@ static struct cache_entry *refresh_entry
!(ce->ce_flags & htons(CE_VALID)))
; /* mark this one VALID again */
else
- return NULL;
+ return ce;
}
- if (ce_modified(ce, &st, really))
- return ERR_PTR(-EINVAL);
+ if (ce_modified(ce, &st, really)) {
+ cache_errno = EINVAL;
+ return NULL;
+ }
size = ce_size(ce);
updated = xmalloc(size);
@@ -669,13 +659,13 @@ int refresh_cache(unsigned int flags)
continue;
}
- new = refresh_entry(ce, really);
- if (!new)
+ new = refresh_cache_entry(ce, really);
+ if (new == ce)
continue;
- if (IS_ERR(new)) {
- if (not_new && PTR_ERR(new) == -ENOENT)
+ if (!new) {
+ if (not_new && cache_errno == ENOENT)
continue;
- if (really && PTR_ERR(new) == -EINVAL) {
+ if (really && cache_errno == EINVAL) {
/* If we are doing --really-refresh that
* means the index is not valid anymore.
*/
--
1.4.1.rc1.gb2d14
^ permalink raw reply related
* [PATCH 3/3] merge-recursive: avoid the pipe to update-index
From: Johannes Schindelin @ 2006-06-30 14:44 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606300235300.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Instead of a fork, we can use the plumbing ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
graph.c | 26 -----
merge-recursive.c | 270 +++++++++++++++++++++++++++++++++++++----------------
2 files changed, 191 insertions(+), 105 deletions(-)
diff --git a/graph.c b/graph.c
index fa2bfee..b784ea2 100644
--- a/graph.c
+++ b/graph.c
@@ -5,32 +5,6 @@ #include "cache.h"
#include "commit.h"
#include "graph.h"
-// does not belong here
-struct tree *git_write_tree()
-{
-#if 0
- fprintf(stderr, "GIT_INDEX_FILE='%s' git-write-tree\n",
- getenv("GIT_INDEX_FILE"));
-#endif
- FILE *fp = popen("git-write-tree 2>/dev/null", "r");
- char buf[41];
- unsigned char sha1[20];
- int ch;
- unsigned i = 0;
- while ( (ch = fgetc(fp)) != EOF )
- if ( i < sizeof(buf)-1 && ch >= '0' && ch <= 'f' )
- buf[i++] = ch;
- else
- break;
- int rc = pclose(fp);
- if ( rc == -1 || WEXITSTATUS(rc) )
- return NULL;
- buf[i] = '\0';
- if ( get_sha1(buf, sha1) != 0 )
- return NULL;
- return lookup_tree(sha1);
-}
-
const char *node_title(struct node *node, int *len)
{
const char *s = "(null commit)";
diff --git a/merge-recursive.c b/merge-recursive.c
index 9bbb426..6d4e797 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -9,6 +9,7 @@ #include <sys/wait.h>
#include <sys/types.h>
#include <sys/stat.h>
#include "cache.h"
+#include "cache-tree.h"
#include "commit.h"
#include "blob.h"
#include "tree-walk.h"
@@ -19,6 +20,47 @@ #include "run-command.h"
#include "graph.h"
#include "path-list.h"
+#ifdef DEBUG
+#include "quote.h"
+static void show_ce_entry(const char *tag, struct cache_entry *ce)
+{
+ if (tag && *tag &&
+ (ce->ce_flags & htons(CE_VALID))) {
+ static char alttag[4];
+ memcpy(alttag, tag, 3);
+ if (isalpha(tag[0]))
+ alttag[0] = tolower(tag[0]);
+ else if (tag[0] == '?')
+ alttag[0] = '!';
+ else {
+ alttag[0] = 'v';
+ alttag[1] = tag[0];
+ alttag[2] = ' ';
+ alttag[3] = 0;
+ }
+ tag = alttag;
+ }
+
+ fprintf(stderr,"%s%06o %s %d\t",
+ tag,
+ ntohl(ce->ce_mode),
+ sha1_to_hex(ce->sha1),
+ ce_stage(ce));
+ write_name_quoted("", 0, ce->name,
+ '\n', stderr);
+ fputc('\n', stderr);
+}
+
+static void ls_files() {
+ int i;
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ show_ce_entry("", ce);
+ }
+ fprintf(stderr, "---\n");
+}
+#endif
+
#define for_each_commit(p,list) for ( p = (list); p; p = p->next )
struct merge_result
@@ -94,12 +136,68 @@ static void output(const char *fmt, ...)
static const char *original_index_file;
static const char *temporary_index_file;
+static int cache_dirty = 0;
+
+static int flush_cache()
+{
+ /* flush temporary index */
+ struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
+ int fd = hold_lock_file_for_update(lock, getenv("GIT_INDEX_FILE"));
+ if (fd < 0)
+ die("could not lock %s", temporary_index_file);
+ if (write_cache(fd, active_cache, active_nr) ||
+ commit_lock_file(lock))
+ die ("unable to write %s", temporary_index_file);
+ discard_cache();
+ cache_dirty = 0;
+ return 0;
+}
static void setup_index(int temp)
{
const char *idx = temp ? temporary_index_file: original_index_file;
+ if (cache_dirty)
+ die("fatal: cache changed flush_cache();");
unlink(temporary_index_file);
setenv("GIT_INDEX_FILE", idx, 1);
+ discard_cache();
+}
+
+static struct cache_entry *make_cache_entry(unsigned int mode,
+ const unsigned char *sha1, const char *path, int stage, int refresh)
+{
+ int size, len;
+ struct cache_entry *ce;
+
+ if (!verify_path(path))
+ return NULL;
+
+ len = strlen(path);
+ size = cache_entry_size(len);
+ ce = xcalloc(1, size);
+
+ memcpy(ce->sha1, sha1, 20);
+ memcpy(ce->name, path, len);
+ ce->ce_flags = create_ce_flags(len, stage);
+ ce->ce_mode = create_ce_mode(mode);
+
+ if (refresh)
+ return refresh_cache_entry(ce, 0);
+
+ return ce;
+}
+
+static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
+ const char *path, int stage, int refresh, int options)
+{
+ struct cache_entry *ce;
+ if (!cache_dirty)
+ read_cache_from(getenv("GIT_INDEX_FILE"));
+ cache_dirty++;
+ ce = make_cache_entry(mode, sha1 ? sha1 : null_sha1, path, stage, refresh);
+ if (!ce)
+ return error("cache_addinfo failed: %s", strerror(cache_errno));
+ return add_cache_entry(ce, options);
}
// This is a global variable which is used in a number of places but
@@ -119,6 +217,8 @@ #if 0
sha1_to_hex(tree->object.sha1));
#endif
const char *argv[] = { "git-read-tree", NULL, NULL, };
+ if (cache_dirty)
+ die("read-tree with dirty cache");
argv[1] = sha1_to_hex(tree->object.sha1);
int rc = run_command_v(2, argv);
return rc < 0 ? -1: rc;
@@ -141,6 +241,8 @@ #endif
"git-read-tree", NULL, "-m", NULL, NULL, NULL,
NULL,
};
+ if (cache_dirty)
+ flush_cache();
argv[1] = update_arg;
argv[3] = sha1_to_hex(common->object.sha1);
argv[4] = sha1_to_hex(head->object.sha1);
@@ -149,6 +251,33 @@ #endif
return rc < 0 ? -1: rc;
}
+struct tree *git_write_tree()
+{
+#if 0
+ fprintf(stderr, "GIT_INDEX_FILE='%s' git-write-tree\n",
+ getenv("GIT_INDEX_FILE"));
+#endif
+ if (cache_dirty)
+ flush_cache();
+ FILE *fp = popen("git-write-tree 2>/dev/null", "r");
+ char buf[41];
+ unsigned char sha1[20];
+ int ch;
+ unsigned i = 0;
+ while ( (ch = fgetc(fp)) != EOF )
+ if ( i < sizeof(buf)-1 && ch >= '0' && ch <= 'f' )
+ buf[i++] = ch;
+ else
+ break;
+ int rc = pclose(fp);
+ if ( rc == -1 || WEXITSTATUS(rc) )
+ return NULL;
+ buf[i] = '\0';
+ if ( get_sha1(buf, sha1) != 0 )
+ return NULL;
+ return lookup_tree(sha1);
+}
+
struct merge_tree_result merge_trees(struct tree *head,
struct tree *merge,
struct tree *common,
@@ -640,36 +769,25 @@ struct rename_entry *getRenames(struct t
return renames;
}
-static FILE *git_update_index_pipe()
-{
- return popen("git-update-index -z --index-info", "w");
-}
-
-int setIndexStages(FILE *fp,
- const char *path,
+int setIndexStages(const char *path,
unsigned char *osha, unsigned omode,
unsigned char *asha, unsigned amode,
unsigned char *bsha, unsigned bmode,
int clear /* =True */)
{
- if ( !fp )
- return -1;
- if ( clear ) {
- fprintf(fp, "0 %s\t%s", sha1_to_hex(null_sha1), path);
- fputc('\0', fp);
- }
- if ( omode ) {
- fprintf(fp, "0%o %s 1\t%s", omode, sha1_to_hex(osha), path);
- fputc('\0', fp);
- }
- if ( amode ) {
- fprintf(fp, "0%o %s 2\t%s", amode, sha1_to_hex(asha), path);
- fputc('\0', fp);
- }
- if ( bmode ) {
- fprintf(fp, "0%o %s 3\t%s", bmode, sha1_to_hex(bsha), path);
- fputc('\0', fp);
- }
+ int options = ADD_CACHE_OK_TO_ADD | ADD_CACHE_OK_TO_REPLACE;
+ if ( clear )
+ if (add_cacheinfo(0, null_sha1, path, 0, 0, options))
+ return -1;
+ if ( omode )
+ if (add_cacheinfo(omode, osha, path, 1, 0, options))
+ return -1;
+ if ( amode )
+ if (add_cacheinfo(omode, osha, path, 2, 0, options))
+ return -1;
+ if ( bmode )
+ if (add_cacheinfo(omode, osha, path, 3, 0, options))
+ return -1;
return 0;
}
@@ -695,17 +813,17 @@ static int remove_path(const char *name)
return ret;
}
-int removeFile(FILE *fp, int clean, const char *path)
+int removeFile(int clean, const char *path)
{
int updateCache = index_only || clean;
int updateWd = !index_only;
if ( updateCache ) {
- if ( !fp )
+ if (!cache_dirty)
+ read_cache_from(getenv("GIT_INDEX_FILE"));
+ cache_dirty++;
+ if (remove_file_from_cache(path))
return -1;
- fprintf(fp, "0 %s\t%s", sha1_to_hex(null_sha1), path);
- fputc('\0', fp);
- return 0;
}
if ( updateWd )
{
@@ -785,8 +903,7 @@ static void flush_buffer(int fd, const c
}
}
-void updateFileExt(FILE *fp,
- const unsigned char *sha,
+void updateFileExt(const unsigned char *sha,
unsigned mode,
const char *path,
int updateCache,
@@ -830,20 +947,15 @@ void updateFileExt(FILE *fp,
mode, sha1_to_hex(sha), path);
}
if ( updateCache )
- {
- // XXX just always use "git update-index --index-info"?
- fprintf(fp, "%06o %s\t%s", mode, sha1_to_hex(sha), path);
- fputc('\0', fp);
- }
+ add_cacheinfo(mode, sha, path, 0, updateWd, ADD_CACHE_OK_TO_ADD);
}
-void updateFile(FILE *fp,
- int clean,
+void updateFile(int clean,
const unsigned char *sha,
unsigned mode,
const char *path)
{
- updateFileExt(fp, sha, mode, path, index_only || clean, !index_only);
+ updateFileExt(sha, mode, path, index_only || clean, !index_only);
}
// Low level file merging, update and removal
@@ -1004,7 +1116,6 @@ int processRenames(struct rename_entry *
for (sre = renamesB; sre; sre = sre->next)
path_list_insert(sre->src, &srcNames);
- FILE *fp = git_update_index_pipe();
for_each_path(src,&srcNames) {
struct rename_entry *renames1, *renames2, *ren1, *ren2;
const char *branchName1, *branchName2;
@@ -1050,26 +1161,26 @@ int processRenames(struct rename_entry *
dstName1 = uniquePath(ren1->dst, branchName1);
output("%s is a directory in %s adding as %s instead",
ren1->dst, branchName2, dstName1);
- removeFile(fp, 0, ren1->dst);
+ removeFile(0, ren1->dst);
}
if ( path_list_has_path(¤tDirectorySet, ren2->dst) ) {
dstName2 = uniquePath(ren2->dst, branchName2);
output("%s is a directory in %s adding as %s instead",
ren2->dst, branchName1, dstName2);
- removeFile(fp, 0, ren2->dst);
+ removeFile(0, ren2->dst);
}
- setIndexStages(fp, dstName1,
+ setIndexStages(dstName1,
NULL, 0,
ren1->dst_sha, ren1->dst_mode,
NULL, 0,
1 /* clear */);
- setIndexStages(fp, dstName2,
+ setIndexStages(dstName2,
NULL, 0,
NULL, 0,
ren2->dst_sha, ren2->dst_mode,
1 /* clear */);
} else {
- removeFile(fp, 1, ren1->src);
+ removeFile(1, ren1->src);
struct merge_file_info mfi;
mfi = mergeFile(ren1->src, ren1->src_sha, ren1->src_mode,
ren1->dst, ren1->dst_sha, ren1->dst_mode,
@@ -1087,18 +1198,17 @@ int processRenames(struct rename_entry *
cleanMerge = 0;
if ( !index_only )
- setIndexStages(fp,
- ren1->dst,
+ setIndexStages(ren1->dst,
ren1->src_sha, ren1->src_mode,
ren1->dst_sha, ren1->dst_mode,
ren2->dst_sha, ren2->dst_mode,
1 /* clear */);
}
- updateFile(fp, mfi.clean, mfi.sha, mfi.mode, ren1->dst);
+ updateFile(mfi.clean, mfi.sha, mfi.mode, ren1->dst);
}
} else {
// Renamed in 1, maybe changed in 2
- removeFile(fp, 1, ren1->src);
+ removeFile(1, ren1->src);
unsigned char srcShaOtherBranch[20], dstShaOtherBranch[20];
unsigned srcModeOtherBranch, dstModeOtherBranch;
@@ -1123,15 +1233,15 @@ int processRenames(struct rename_entry *
ren1->dst, branchName2);
output("Renaming %s to %s instead", ren1->src, newPath);
cleanMerge = 0;
- removeFile(fp, 0, ren1->dst);
- updateFile(fp, 0, ren1->dst_sha, ren1->dst_mode, newPath);
+ removeFile(0, ren1->dst);
+ updateFile(0, ren1->dst_sha, ren1->dst_mode, newPath);
} else if ( memcmp(srcShaOtherBranch, null_sha1, 20) == 0 ) {
output("CONFLICT (rename/delete): Rename %s->%s in %s "
"and deleted in %s",
ren1->src, ren1->dst, branchName1,
branchName2);
cleanMerge = 0;
- updateFile(fp, 0, ren1->dst_sha, ren1->dst_mode, ren1->dst);
+ updateFile(0, ren1->dst_sha, ren1->dst_mode, ren1->dst);
} else if ( memcmp(dstShaOtherBranch, null_sha1, 20) != 0 ) {
newPath = uniquePath(ren1->dst, branchName2);
output("CONFLICT (rename/add): Rename %s->%s in %s. "
@@ -1139,7 +1249,7 @@ int processRenames(struct rename_entry *
ren1->src, ren1->dst, branchName1,
ren1->dst, branchName2);
output("Adding as %s instead", newPath);
- updateFile(fp, 0, dstShaOtherBranch, dstModeOtherBranch, newPath);
+ updateFile(0, dstShaOtherBranch, dstModeOtherBranch, newPath);
cleanMerge = 0;
tryMerge = 1;
} else if ( (dst2 = find_rename_bydst(renames2, ren1->dst)) ) {
@@ -1151,9 +1261,9 @@ int processRenames(struct rename_entry *
dst2->src, dst2->dst, branchName2);
output("Renaming %s to %s and %s to %s instead",
ren1->src, newPath1, dst2->src, newPath2);
- removeFile(fp, 0, ren1->dst);
- updateFile(fp, 0, ren1->dst_sha, ren1->dst_mode, newPath1);
- updateFile(fp, 0, dst2->dst_sha, dst2->dst_mode, newPath2);
+ removeFile(0, ren1->dst);
+ updateFile(0, ren1->dst_sha, ren1->dst_mode, newPath1);
+ updateFile(0, dst2->dst_sha, dst2->dst_mode, newPath2);
dst2->processed = 1;
cleanMerge = 0;
} else
@@ -1194,21 +1304,19 @@ int processRenames(struct rename_entry *
cleanMerge = 0;
if ( !index_only )
- setIndexStages(fp,
- ren1->dst,
+ setIndexStages(ren1->dst,
osha, omode,
asha, amode,
bsha, bmode,
1 /* clear */);
}
- updateFile(fp, mfi.clean, mfi.sha, mfi.mode, ren1->dst);
+ updateFile(mfi.clean, mfi.sha, mfi.mode, ren1->dst);
}
}
}
path_list_clear(&srcNames, 0);
- if (pclose(fp)) {
- die("git update-index --index-info failed");
- }
+ if (cache_dirty)
+ flush_cache();
return cleanMerge;
}
@@ -1241,7 +1349,6 @@ int processEntry(struct index_entry *ent
unsigned oMode = entry->stages[1].mode;
unsigned aMode = entry->stages[2].mode;
unsigned bMode = entry->stages[3].mode;
- FILE *fp = git_update_index_pipe();
if ( oSha && (!aSha || !bSha) ) {
//
@@ -1253,7 +1360,7 @@ int processEntry(struct index_entry *ent
// Deleted in both or deleted in one and unchanged in the other
if ( aSha )
output("Removing %s", path);
- removeFile(fp, 1, path);
+ removeFile(1, path);
} else {
// Deleted in one and changed in the other
cleanMerge = 0;
@@ -1262,13 +1369,13 @@ int processEntry(struct index_entry *ent
"and modified in %s. Version %s of %s left in tree.",
path, branch1Name,
branch2Name, branch2Name, path);
- updateFile(fp, 0, bSha, bMode, path);
+ updateFile(0, bSha, bMode, path);
} else {
output("CONFLICT (delete/modify): %s deleted in %s "
"and modified in %s. Version %s of %s left in tree.",
path, branch2Name,
branch1Name, branch1Name, path);
- updateFile(fp, 0, aSha, aMode, path);
+ updateFile(0, aSha, aMode, path);
}
}
@@ -1302,11 +1409,11 @@ int processEntry(struct index_entry *ent
output("CONFLICT (%s): There is a directory with name %s in %s. "
"Adding %s as %s",
conf, path, otherBranch, path, newPath);
- removeFile(fp, 0, path);
- updateFile(fp, 0, sha, mode, newPath);
+ removeFile(0, path);
+ updateFile(0, sha, mode, newPath);
} else {
output("Adding %s", path);
- updateFile(fp, 1, sha, mode, path);
+ updateFile(1, sha, mode, path);
}
} else if ( !oSha && aSha && bSha ) {
//
@@ -1319,7 +1426,7 @@ int processEntry(struct index_entry *ent
"but permissions conflict %06o->%06o",
path, aMode, bMode);
output("CONFLICT: adding with permission: %06o", aMode);
- updateFile(fp, 0, aSha, aMode, path);
+ updateFile(0, aSha, aMode, path);
} else {
// This case is handled by git-read-tree
assert(0 && "This case must be handled by git-read-tree");
@@ -1331,9 +1438,9 @@ int processEntry(struct index_entry *ent
output("CONFLICT (add/add): File %s added non-identically "
"in both branches. Adding as %s and %s instead.",
path, newPath1, newPath2);
- removeFile(fp, 0, path);
- updateFile(fp, 0, aSha, aMode, newPath1);
- updateFile(fp, 0, bSha, bMode, newPath2);
+ removeFile(0, path);
+ updateFile(0, aSha, aMode, newPath1);
+ updateFile(0, bSha, bMode, newPath2);
}
} else if ( oSha && aSha && bSha ) {
@@ -1348,22 +1455,23 @@ int processEntry(struct index_entry *ent
branch1Name, branch2Name);
if ( mfi.clean )
- updateFile(fp, 1, mfi.sha, mfi.mode, path);
+ updateFile(1, mfi.sha, mfi.mode, path);
else {
cleanMerge = 0;
output("CONFLICT (content): Merge conflict in %s", path);
if ( index_only )
- updateFile(fp, 0, mfi.sha, mfi.mode, path);
+ updateFile(0, mfi.sha, mfi.mode, path);
else
- updateFileExt(fp, mfi.sha, mfi.mode, path,
+ updateFileExt(mfi.sha, mfi.mode, path,
0 /* updateCache */, 1 /* updateWd */);
}
} else
die("Fatal merge failure, shouldn't happen.");
- if (pclose(fp))
- die("updating entry failed in git update-index");
+ if (cache_dirty)
+ flush_cache();
+
return cleanMerge;
}
@@ -1570,6 +1678,10 @@ int main(int argc, char *argv[])
struct graph *graph = graph_build(commits);
result = merge(h1, h2, branch1, branch2, graph, 0, NULL);
}
+
+ if (cache_dirty)
+ flush_cache();
+
return result.clean ? 0: 1;
}
--
1.4.1.rc1.gb2d14
^ permalink raw reply related
* [PATCH 12] Revert "autoconf: Write how to use ./configure generated file in git build process"
From: Jakub Narebski @ 2006-06-30 15:08 UTC (permalink / raw)
To: git
In-Reply-To: <200606301441.01327.jnareb@gmail.com>
This reverts 6015ccba6c0439b0b615615aacefaf463c546ba4 commit.
To be replaced by better solution, idea by Andreas Ericsson
---
Or just not apply [PATCH 10] (and this patch)
configure.ac | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index f01fc17..1ead656 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,9 +54,3 @@ AC_CONFIG_FILES(["${config_file}":"${con
AC_OUTPUT
rm -f "${config_append}"
-
-cat <<_ACEOF
-
-Add '-include ${config_file}' to your config.mak,
-or rename ${config_file} to config.mak
-_ACEOF
--
1.4.0
^ permalink raw reply related
* [PATCH 13] autoconf: Append '-include config.mak.autogen' to config.mak if it is not present
From: Jakub Narebski @ 2006-06-30 15:11 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson
In-Reply-To: <200606301708.19521.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Andreas Ericsson wrote:
> Jakub Narebski wrote:
>>
>> The idea was to use ./configure to _generate_ config.mak, which the user can
>> then edit.
>
> This is bad, since it forces users to do one thing first and then do
> what they're used to. Better to have the script add
>
> -include config.mak.autogen
>
> LAST in config.mak, unless it's already in the file and generate
> config.mak.autogen with configure, e.g. with
>
> grep -q autogen config.mak || \
> echo "-include config.mak.autogen" >> config.mak
>
> Since Make does things bottoms-up (much like swedish students and
> midsummer celebrators), the previous hand-edited defaults in config.mak
> will beat the ones in config.mak.autogen (a good thing).
>
> I wouldn't want my long-standing, functioning config.mak overwritten,
> but I *might* be interested in trying some of the options provided by
> ./configure.
Done, with small changes.
Can anyone tell me if frep use is portable enough?
configure.ac | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/configure.ac b/configure.ac
index 1ead656..2904077 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,3 +54,6 @@ AC_CONFIG_FILES(["${config_file}":"${con
AC_OUTPUT
rm -f "${config_append}"
+
+grep -q -s -F "-include ${config_file}" config.mak || \
+ echo "-include ${config_file}" >> config.mak
--
1.4.0
^ permalink raw reply related
* Re: [PATCH] git-grep: boolean expression on pattern matching.
From: Matthias Lederhofer @ 2006-06-30 15:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsllnj6rh.fsf_-_@assigned-by-dhcp.cox.net>
> This extends the behaviour of git-grep when multiple -e options
> are given. So far, we allowed multiple -e to behave just like
> regular grep with multiple -e, i.e. the patterns are OR'ed
> together.
>
> With this change, you can also have multiple patterns AND'ed
> together, or form boolean expressions, like this (the
> parentheses are quoted from the shell in this example):
>
> $ git grep -e _PATTERN --and \( -e atom -e token \)
This looks really nice. So for a few trivial tests it did not fail :)
I noticed an unrelated bug. The context separators ("--") are missing
between matches in different files:
$ git-grep -e foobar -A 1 (this uses external grep)
Documentation/git-diff-tree.txt:I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h`
Documentation/git-diff-tree.txt-so it can be used to name subdirectories.
--
git-send-email.perl:#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
git-send-email.perl-
--
[..]
$ git-grep -e foobar -A 1 master (this is internal grep)
master:Documentation/git-diff-tree.txt:I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h`
master:Documentation/git-diff-tree.txt-so it can be used to name subdirectories.
master:git-send-email.perl:#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
master:git-send-email.perl-
[..]
I think this cannot be fixed in the loop in builtin-grep.c:grep_cache
because after the last hit there should be no separator but it is not
known if a grep_sha1/grep_file will match and produce output. So I
think there has to be a variable passed down which tells those
functions to print the separator before any other output.
^ permalink raw reply
* Re: [PATCH] autoconf: Use autoconf to write installation directories to config.mak
From: Jakub Narebski @ 2006-06-30 15:15 UTC (permalink / raw)
To: git
In-Reply-To: <44A51693.5020501@op5.se>
Andreas Ericsson wrote:
> grep -q autogen config.mak || \
> echo "-include config.mak.autogen" >> config.mak
>
> I wouldn't want my long-standing, functioning config.mak overwritten,
> but I *might* be interested in trying some of the options provided by
> ./configure.
Thanks for the solution. Done in my latest patch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 15:57 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FwGgm-0006Nc-9a@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano wrote:
>> I see you are trying hard to think of a way to justify your
>> original prefix "--and" (or --FOO) implementation, but I simply
>> do not see much point in that. I doubt changing the default
>> operator from --or to --and is less confusing than changing the
>> precedence for the users, so you would hear the same "I
>> personally feel FOO should not even exist" objection from me.
>
> It just happens to make more sense to me and I don't see a reason not to
> add this. If no one else is interested in this I'll just stop arguing :)
> Here again an overview of the arguments if anyone is interested:
> - Less to type for common searches using only AND (or more ANDs than
> ORs).
> - Easy to implement (both with and without extended expressions).
> - AND/* is the normal implicit operator in other contexts than grep
> (math).
> - The high precedence operator (AND) should be implicit rather than
> the low precedence one (OR) (so this is only fulfilled when the
> option is used).
Side note. It would be interesting to have a slightly different
form of --and called --near. You would use it like this:
git grep -C -e AND --near -e OR
to find lines that has AND on it, and within the context
distance there is a line that has OR on it. The lines that are
hit with such a query are still the ones that have AND on them
(in other words, a line that has OR is used to further filter
out the results so it will be prefixed with '-', not ':', unless
that line happens to also have AND on it).
With your syntax perhaps this is spelled as "--near -C -e AND -e
OR".
^ permalink raw reply
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Junio C Hamano @ 2006-06-30 16:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Alex Riesen
In-Reply-To: <Pine.LNX.4.63.0606301643150.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> +int discard_cache()
> +{
> + int ret;
> +
> + if (cache_mmap == NULL)
> + return 0;
> + ret = munmap(cache_mmap, cache_mmap_size);
> + cache_mmap = NULL;
> + cache_mmap_size = 0;
> + active_nr = active_cache_changed = 0;
> + /* no need to throw away allocated active_cache */
> + return ret;
> +}
> +
I haven't been following the details of the patches in this
thread while they are being cooked actively, but two things to
look out for are:
- I am guessing you run discard_cache() because you want to
read in a new cache (or start from a clean slate). I am not
sure what you are doing with the old cache tree data
structure. If you are starting from a clean slate
(i.e. there is no read_cache_from() after you call
discard_cache), you would probably need to discard the old
cache tree; otherwise your next write-tree may produce an
incorrect index file. If you keep the old one and later
swap it in, the problem might be even more severe.
- index_timestamp is left as the old value in this patch when
you switch cache using read_cache_from() directly. I have a
suspicion you may be bitten by "Racy Git" problem, especially
because the operations are supposed to happen quickly thanks
to the effort of you two ;-) increasing the risks that the
file timestamp of the working tree file and the cached entry
match.
^ permalink raw reply
* Re: [PATCH] consider previous pack undeltified object state only when reusing delta data
From: Nicolas Pitre @ 2006-06-30 16:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <44A518D6.8040901@op5.se>
On Fri, 30 Jun 2006, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 29 Jun 2006, Nicolas Pitre wrote:
> >
> >
> > > Without this there would never be a chance to improve packing for
> > > previously undeltified objects.
> >
> >
> > Earlier this year, I was quite surprised to learn that multiple repackings
> > actually improved packing. Does that patch mean this feature is gone?
> >
>
> The patch Linus sent removes that feature. This one re-introduces it.
Not really.
Actually that multiple repacking "feature" was rather an artifact of the
delta data reuse code and not really by design. Here's what happened
before:
Consider the first repack where no delta exists, or "git-repack -a -f"
where the -f argument makes it ignores existing delta data. In that
case all objects are sorted and delta attempted on them within a window.
So to simplify things let's assume objects are numbered from 1 upwards.
First obj #1 is added to the window. Obj #2 attempts a delta against
obj #1. Obj #3 attempts a delta against objs #2 and #1. Obj #4
attempts a delta against objs #3, #2 and #1. And so on for all object:
each new object attempts a delta against the last 10 objects (the
default window size is 10) and the best delta, if any, is kept.
In the end, some objects get deltified, some don't, and a new pack is
produced.
When repacking without -f to git-repack, then already deltified objects
are simply copied as is from the existing pack(s) avoiding costly delta
re-computation. Still, without Linus' patch, non-deltified objects were
considered for deltification and deltas attempted on them.
So supposing that objects #1 through #10 were not deltified, and objects
#11 through #50 were deltified, then those deltified objects were
skipped over for the purpose of delta matching and therefore object #51
ended up attempting a delta against objs #1 to 10 instead of #41 to #50
like in the previous run. The net effect was similar to a larger window
for some objects providing more opportunities for successful deltas, and
therefore a smaller pack.
With Linus' patch those objects already known to be undeltified are,
too, skipped. That means that successive git-repack without the -f
argument are now producing identical packs all the time and the artifact
above is gone.
I think this is a good thing since now the packing behavior is more
predictable. But nothing is lost since if you want to have better
packing like before you simply have to specify a slightly larger window
size on the first git-repack. It'll take a bit more time but running
git-repack many times also took more time in the end anyway.
Nicolas
^ permalink raw reply
* fc046a75d539a78e6b2c16534c4078617a69a327 fails on OpenBSD 3.8
From: Randal L. Schwartz @ 2006-06-30 16:57 UTC (permalink / raw)
To: git
gcc -o upload-pack.o -c -g -O2 -Wall -I/usr/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR upload-pack.c
In file included from /usr/include/sys/poll.h:54,
from upload-pack.c:9:
/usr/include/ctype.h:67: error: syntax error before ']' token
/usr/include/ctype.h:68: error: syntax error before ']' token
/usr/include/ctype.h:70: error: syntax error before ']' token
/usr/include/ctype.h:75: error: syntax error before ']' token
/usr/include/ctype.h:78: error: syntax error before '(' token
/usr/include/ctype.h:79: error: syntax error before '(' token
/usr/include/ctype.h:93: error: syntax error before "c"
In file included from /usr/include/sys/poll.h:54,
from upload-pack.c:9:
/usr/include/ctype.h:91:1: unterminated #if
/usr/include/ctype.h:40:1: unterminated #ifndef
In file included from upload-pack.c:9:
/usr/include/sys/poll.h:53:1: unterminated #ifndef
/usr/include/sys/poll.h:28:1: unterminated #ifndef
gmake: *** [upload-pack.o] Error 1
The lines in ctype.h that are probably relevant are:
#if defined(__GNUC__) || defined(_ANSI_LIBRARY) || defined(lint)
int isalnum(int);
int isalpha(int);
int iscntrl(int);
int isdigit(int);
int isgraph(int);
int islower(int);
int isprint(int);
int ispunct(int);
int isspace(int);
int isupper(int);
int isxdigit(int);
int tolower(int);
int toupper(int);
Line 67 is "int isalnum(int)"
Are you defining a macro when you shouldn't be in upload-pack?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejx6k54p.fsf@assigned-by-dhcp.cox.net>
> Side note. It would be interesting to have a slightly different
> form of --and called --near. You would use it like this:
>
> git grep -C -e AND --near -e OR
>
> to find lines that has AND on it, and within the context
> distance there is a line that has OR on it. The lines that are
> hit with such a query are still the ones that have AND on them
> (in other words, a line that has OR is used to further filter
> out the results so it will be prefixed with '-', not ':', unless
> that line happens to also have AND on it).
Nice idea even though I don't now about practical importance but it
sounds quite handy. A few questions about this (some or all of those
features may make it quite complex):
1. Should the context of near be the same as -[ABC] or perhaps
--near=N / --near=N:M (default could be the same as specified by
-[ABC]).
2. Should it be possible to specify another boolean expression after
--near? e.g. --near ( -e foo --or ( -e bar --and -e baz )) to match
if the context contains foo or 'bar and baz'.
3. Is --near just another subexpression? e.g. search for foo with
either A or B in the context:
-e foo --and ( --near A --or --near B )
This does not make sense without 1 and 2.
With some or all of those features quite mighty and complex
expressions can be build:
-e A --and --near=3:-1 ( -e B --and --near=0:0 ( -e foo --and -e bar ) )
This could mean: find lines containing A and have B in any of the 3
lines before A (without the line containing A). Additionally foo and
bar have to be found on the same line before A.
I'm really not asking for this, just telling about some ideas that
come to my mind for --near.
> With your syntax perhaps this is spelled as "--near -C -e AND -e
> OR".
Huh? What do you mean by "my syntax"? The only thing different is the
option to change the default operator to 'and'.
With the new extended expressions it would be really nice if git-grep
could also be used outside a git repository :)
^ permalink raw reply
* Re: fc046a75d539a78e6b2c16534c4078617a69a327 fails on OpenBSD 3.8
From: Junio C Hamano @ 2006-06-30 17:06 UTC (permalink / raw)
To: git
In-Reply-To: <86wtayy42o.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> gcc -o upload-pack.o -c -g -O2 -Wall -I/usr/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR upload-pack.c
> In file included from /usr/include/sys/poll.h:54,
> from upload-pack.c:9:
> /usr/include/ctype.h:67: error: syntax error before ']' token
> /usr/include/ctype.h:68: error: syntax error before ']' token
> /usr/include/ctype.h:70: error: syntax error before ']' token
> /usr/include/ctype.h:75: error: syntax error before ']' token
> /usr/include/ctype.h:78: error: syntax error before '(' token
> /usr/include/ctype.h:79: error: syntax error before '(' token
> /usr/include/ctype.h:93: error: syntax error before "c"
> In file included from /usr/include/sys/poll.h:54,
> from upload-pack.c:9:
> /usr/include/ctype.h:91:1: unterminated #if
> /usr/include/ctype.h:40:1: unterminated #ifndef
Crap. Including <sys/poll.h> pollutes your namespace with ctype
macros?
^ permalink raw reply
* Re: fc046a75d539a78e6b2c16534c4078617a69a327 fails on OpenBSD 3.8
From: Randal L. Schwartz @ 2006-06-30 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7veindn.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>> gcc -o upload-pack.o -c -g -O2 -Wall -I/usr/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR upload-pack.c
>> In file included from /usr/include/sys/poll.h:54,
>> from upload-pack.c:9:
>> /usr/include/ctype.h:67: error: syntax error before ']' token
>> /usr/include/ctype.h:68: error: syntax error before ']' token
>> /usr/include/ctype.h:70: error: syntax error before ']' token
>> /usr/include/ctype.h:75: error: syntax error before ']' token
>> /usr/include/ctype.h:78: error: syntax error before '(' token
>> /usr/include/ctype.h:79: error: syntax error before '(' token
>> /usr/include/ctype.h:93: error: syntax error before "c"
>> In file included from /usr/include/sys/poll.h:54,
>> from upload-pack.c:9:
>> /usr/include/ctype.h:91:1: unterminated #if
>> /usr/include/ctype.h:40:1: unterminated #ifndef
Junio> Crap. Including <sys/poll.h> pollutes your namespace with ctype
Junio> macros?
>From /usr/include/sys/poll.h:
#ifndef _KERNEL
#include <ctype.h>
So, I guess, it's ... Yes.
This sounds familiar. Maybe the mailing list archive has me reporting
this bug last time too. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 17:18 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1FwMPf-0005XA-N9@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> 1. Should the context of near be the same as -[ABC] or perhaps
> --near=N / --near=N:M (default could be the same as specified by
> -[ABC]).
As an end-user, I do not care either way.
> 2. Should it be possible to specify another boolean expression after
> --near? e.g. --near ( -e foo --or ( -e bar --and -e baz )) to match
> if the context contains foo or 'bar and baz'.
I would say why not.
> 3. Is --near just another subexpression? e.g. search for foo with
> either A or B in the context:
> -e foo --and ( --near A --or --near B )
> This does not make sense without 1 and 2.
Ah, interesting. I was thinking --near to be weaker form of --and,
but you made it to be a unary predicate (like --not). That
would be neater.
> With some or all of those features quite mighty and complex
> expressions can be build:
> -e A --and --near=3:-1 ( -e B --and --near=0:0 ( -e foo --and -e bar ) )
> This could mean: find lines containing A and have B in any of the 3
> lines before A (without the line containing A). Additionally foo and
> bar have to be found on the same line before A.
Having said that, I suspect the above made-up example may not be
so useful in practice. I think a more realistic usage is "I
want to find lines that contain `made-up' and `realistic' but
the paragraph might have been filled by the editor and they may
be found on separate nearby lines. Instead of saying `-e
made-up --and -e realistic', I would say `-e made-up --near -e
realistic' to find what I want". That would find the first two
lines of this paragraph, among others.
> With the new extended expressions it would be really nice if git-grep
> could also be used outside a git repository :)
I am not sure about `outside' but it might be useful to extend
the working tree walker and glob filter used there to match what
ls-files uses so that it can do untracked files as well.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Jakub Narebski @ 2006-06-30 17:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsgqimu7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>> 3. Is --near just another subexpression? e.g. search for foo with
>> either A or B in the context:
>> -e foo --and ( --near A --or --near B )
>> This does not make sense without 1 and 2.
>
> Ah, interesting. I was thinking --near to be weaker form of --and,
> but you made it to be a unary predicate (like --not). That
> would be neater.
I think --near _has_ to be non-symmetric binary operator, i.e. first
argument specifies line to be found, second argument has to be in context
for first line if it is found.
So the above expression would be written as:
-e foo --near \( A --or B \)
BTW. we can make -e equivalent to --or, and empty (default) operator to
--and, but of course you have to delimit expression from files, i.e. either
git grep A B C D -- files
or
git grep -e \( A B C D \) files
which would be equivalent to
git grep A --and B --and C --and D files
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: fc046a75d539a78e6b2c16534c4078617a69a327 fails on OpenBSD 3.8
From: Junio C Hamano @ 2006-06-30 17:38 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86sllmy3ia.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>...
>>> In file included from /usr/include/sys/poll.h:54,
>>> from upload-pack.c:9:
>>> /usr/include/ctype.h:91:1: unterminated #if
>>> /usr/include/ctype.h:40:1: unterminated #ifndef
>
> Junio> Crap. Including <sys/poll.h> pollutes your namespace with ctype
> Junio> macros?
I should stop imitating others -- not my style. Sorry.
Would this work for you?
diff --git a/upload-pack.c b/upload-pack.c
index 2b70c3d..b18eb9b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -1,3 +1,6 @@
+#include <signal.h>
+#include <sys/wait.h>
+#include <sys/poll.h>
#include "cache.h"
#include "refs.h"
#include "pkt-line.h"
@@ -5,9 +8,6 @@ #include "tag.h"
#include "object.h"
#include "commit.h"
#include "exec_cmd.h"
-#include <signal.h>
-#include <sys/poll.h>
-#include <sys/wait.h>
static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
^ permalink raw reply related
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 17:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e83n97$973$1@sea.gmane.org>
Jakub Narebski wrote:
> I think --near _has_ to be non-symmetric binary operator, i.e. first
> argument specifies line to be found, second argument has to be in context
> for first line if it is found.
>
> So the above expression would be written as:
>
> -e foo --near \( A --or B \)
Why is that?
-e foo --and --near \( -e A -- or -e B \)
would mean lines containing foo and either A or B in the context and
-e foo --or --near \( -e A -- or -e B \)
would mean lines containing foo or having A or B in the context.
> BTW. we can make -e equivalent to --or, and empty (default) operator to
> --and, but of course you have to delimit expression from files, i.e. either
>
> git grep A B C D -- files
This is incompatible with the current implementation.
'git grep A B C D -- files' means A is the pattern, B, C, D are
revisions and files is the pathspec.
> or
>
> git grep -e \( A B C D \) files
>
> which would be equivalent to
>
> git grep A --and B --and C --and D files
I think this could probably be used. But I think having two different
implicit operators depending on the context is too confusing.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 17:58 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git, Jakub Narebski
In-Reply-To: <E1FwN7M-0007GI-Ng@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> -e foo --or --near \( -e A -- or -e B \)
> would mean lines containing foo or having A or B in the context.
How would that "--near" be useful? You will see A or B either way.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Jakub Narebski @ 2006-06-30 18:03 UTC (permalink / raw)
To: git
In-Reply-To: <E1FwN7M-0007GI-Ng@moooo.ath.cx>
Matthias Lederhofer wrote:
> Jakub Narebski wrote:
>> I think --near _has_ to be non-symmetric binary operator, i.e. first
>> argument specifies line to be found, second argument has to be in context
>> for first line if it is found.
>>
>> So the above expression would be written as:
>>
>> -e foo --near \( A --or B \)
> Why is that?
> -e foo --and --near \( -e A --or -e B \)
> would mean lines containing foo and either A or B in the context and
> -e foo --or --near \( -e A --or -e B \)
> would mean lines containing foo or having A or B in the context.
Because --near needs an expression it check context for (context is for
found match of lhs expression). So
-e foo --near \( -e A --or -e B \)
means lines containing foo and either A or B in the context _for "foo"_.
--and --near could be shorthand for --and-near, and --or --near for
--or-near... except that the second one doesn't have much sense:
What is the difference between
-e foo --or --near \( -e A --or -e B \)
and
-e foo --or \( -e A --or -e B \)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] Fix probing for already installed Error.pm
From: Pavel Roskin @ 2006-06-30 18:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vbqsbks69.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-06-30 at 00:40 -0700, Junio C Hamano wrote:
> > It is trying to see if we need to install the Error.pm we ship
> > just in case the system does not have Error.pm available. But
> > this script is run in perl/ directory where we have that private
> > copy of Error.pm, so "require Error" always succeeds, eh, at
> > least after you fixed the above syntax error X-<.
Nice catch! Thank you for fixing it.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Junio C Hamano @ 2006-06-30 18:16 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e83p0q$dla$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Because --near needs an expression it check context for (context is for
> found match of lhs expression). So
>
> -e foo --near \( -e A --or -e B \)
>
> means lines containing foo and either A or B in the context _for "foo"_.
The syntax and semantics of --near I suggested (and you are
following) and what Matthias discusses are different and I think
that is why you two are talking past each other.
What I originally suggested is that you can (syntactically)
replace --near with --and. That is, the LHS is the match and
RHS is "the LHS must match, but in addition RHS must match but
unlike --and RHS does not have to be exactly on the same line
but it is OK if it is a line somewhere nearby".
The --near Matthias talk about is syntactically not like --and
but more like --not. It takes a condition for a line after
that, and loosens it to cover nearby lines. So "-e A"
means "the line must have A on it" but "--near -e A" means "the
line must be nearby a line that satisfies `-e A'".
Matthias's "--near EXP" is spelled as "-e '' --near EXP" (the
first one is always true) with our syntax, in other words.
I do not think either of these semantics is invalid; they are
just different. The version by Matthias is more general and
more expressive.
^ 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