* Re: GIt.xs merge status
From: Junio C Hamano @ 2006-06-30 10:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606301150250.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I'll try it (it's in pu, right?). Note that breaking git-fmt-merge-msg
> might be a good way to force somebody to rewrite it in C ;-)
It would hopefully not come to that (and that is I am playing
safe and keeping the series in "pu"), and even if it did, I am
hoping that Perl is so ubiquitous that people would fix it up
quickly.
^ permalink raw reply
* Re: [PATCH] git-grep: boolean expression on pattern matching.
From: Junio C Hamano @ 2006-06-30 10:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e82u4l$fvb$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>>
>> $ git grep -e _PATTERN --and \( -e atom -e token \)
>
> And where is documentation update?
Heh, real men do not do documentation ;-).
I am going to bed now, and am hoping a kind soul would be
sending out a patch while I am sleeping.
^ permalink raw reply
* Re: [PATCH] git-grep: --and to combine patterns with and instead of or
From: Matthias Lederhofer @ 2006-06-30 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bdnkrfb.fsf@assigned-by-dhcp.cox.net>
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).
^ permalink raw reply
* Re: [PATCH 4/4] save another call to git-update-index
From: Alex Riesen @ 2006-06-30 11:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0606301155050.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/30/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.
> > >
> > Are you sure? Does something use the index between starting update-index
> > pipe and pclose?
>
> Yes, I am sure you have to write the cache before git-read-tree and
> git-write-tree ;-)
Indeed :) That's what pclose before git-write-tree is for (which was not the
case as I published this optimization. Noticed it later. The last patch series
has pclose before git-write-tree)
> I must have done something severely wrong, though,
> since there are not too many places where they are called. The problem is
> more likely that the cache has to be _read_, and _before_ the first
> substituted call to git-update-index.
git-write-tree change index?
^ permalink raw reply
* Re: [PATCH] autoconf: Use autoconf to write installation directories to config.mak
From: Andreas Ericsson @ 2006-06-30 12:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e80lnq$9mi$1@sea.gmane.org>
Jakub Narebski wrote:
> Matthias Lederhofer wrote:
>
>
>>>This is beginning of patch series introducing installation configuration
>>>using autoconf (and no other autotools) to git. The idea is to generate
>>>config.mak using ./configure (generated from configure.ac) from
>>>config.mak.in, so one can use autoconf as an _alternative_ to ordinary
>>>Makefile, and creating one's own config.mak.
>>
>>Are you sure this should be named config.mak? From INSTALL:
>>
>>>You can place local settings in config.mak and the Makefile
>>>will include them. Note that config.mak is not distributed;
>>>the name is reserved for local settings.
>>
>>So with another filename either include it
>>- before config.mak: the user may override ./configure options with
>> config.mak
>>- after config.mak: ./configure overrides config.mak
>
>
> 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.
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).
> But perhaps using another filename for results of ./configure script
> (and including it in main Makefile) would be better idea.
>
>
>>At least do not overwrite config.mak if it exists.
>
>
> But one might want to run ./configure with different options, to finally
> arrive at the set which is satisfactionary. So unless some magic to detect
> if config.mak was generated from ./configure script, or generated by user
> is used...
>
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] consider previous pack undeltified object state only when reusing delta data
From: Andreas Ericsson @ 2006-06-30 12:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606301144450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 9] autoconf: Cleanup generation of temporary "append" file
From: Jakub Narebski @ 2006-06-30 12:37 UTC (permalink / raw)
To: git
In-Reply-To: <200606300232.34472.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
configure.ac | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 799bc87..e387f5b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -10,7 +10,7 @@ config_file=config.mak.auto
config_append=config.mak.append
config_in=config.mak.in
-echo "# ${config_append}. Generated by configure." >> "${config_append}"
+echo "# ${config_append}. Generated by configure." > "${config_append}"
# Definitions of macros
# MY_APPEND_LINE(LINE)
@@ -50,6 +50,7 @@ AC_CHECK_FUNC(setenv,,MY_APPEND_LINE(NO_
# Output files
-AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"],
-[rm -f "${config_append}"])
+AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
+
+rm -f "${config_append}"
--
1.4.0
^ permalink raw reply related
* [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
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