* Re: [RFC] adding merge-node to parent lines in a commit
From: Junio C Hamano @ 2005-05-15 21:30 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <1282.10.10.10.24.1116192147.squirrel@linux1>
It is not clear to me ID of what object is being recorded as
SHA1-MERGE-NODE in your proposal. Care to illustrate?
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Thomas Gleixner @ 2005-05-15 21:30 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <1273.10.10.10.24.1116192097.squirrel@linux1>
On Sun, 2005-05-15 at 17:21 -0400, Sean wrote:
> > Time is illusion.
>
> What you're missing is that time is only important in this case to deduce
> the relative age of each commit LOCALLY. The intention of this proposal
> is not to allow time comparison of commits between repositories.
I do not want to compare times. I want to figure out workflows and
histories between different repositories.
> In fact,
> you'll see if you look closely, that you don't need to do that in order to
> solve the stated problem of sorting the commits by the time they were
> merged LOCALLY.
Even LOCALLY is no guarantee for correct timestamps.
tglx
^ permalink raw reply
* [PATCH 0/4] Rediffed against the tip of git-pb tree
From: Junio C Hamano @ 2005-05-15 21:23 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
In-Reply-To: <7vis1kvqac.fsf@assigned-by-dhcp.cox.net>
Petr, I am sending rediff against the tip of git-pb tree. One
of the patches is not just rediff---the earlier version I failed
to add a couple of newly created files.
[1/4] Add --author and --committer match to git-rev-list and git-rev-tree.
[2/4] Tweak diff output further to make it a bit less distracting.
[3/4] Implement git-checkout-cache -u to update stat information in the cache.
[4/4] Trivial test harness fixes.
^ permalink raw reply
* [PATCH 3/4] Implement git-checkout-cache -u to update stat information in the cache.
From: Junio C Hamano @ 2005-05-15 21:23 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
With -u flag, git-checkout-cache picks up the stat information
from newly created file and updates the cache. This removes the
need to run git-update-cache --refresh immediately after running
git-checkout-cache.
---
*** The one I posted earlier failed to add a couple of files
*** that the patch should have added. Please discard it and
*** replace it with this one. Thanks.
Documentation/git-checkout-cache.txt | 6 +++
Makefile | 2 -
cache.h | 9 +++++
checkout-cache.c | 35 ++++++++++++++++++++++-
index.c | 53 +++++++++++++++++++++++++++++++++++
read-cache.c | 20 +++++++++++++
t/t2002-checkout-cache-u.sh | 31 ++++++++++++++++++++
update-cache.c | 48 ++-----------------------------
8 files changed, 157 insertions(+), 47 deletions(-)
index.c (. --> 100644)
t/t2002-checkout-cache-u.sh (. --> 100644)
--- a/Documentation/git-checkout-cache.txt
+++ b/Documentation/git-checkout-cache.txt
@@ -9,7 +9,7 @@
SYNOPSIS
--------
-'git-checkout-cache' [-q] [-a] [-f] [-n] [--prefix=<string>]
+'git-checkout-cache' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
[--] <file>...
DESCRIPTION
@@ -19,6 +19,10 @@
OPTIONS
-------
+-u::
+ update stat information for the checked out entries in
+ the cache file.
+
-q::
be quiet if files exist or are not in the cache
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,7 @@
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
- tag.o date.o
+ tag.o date.o index.o
LIB_FILE=libgit.a
LIB_H=cache.h object.h blob.h tree.h commit.h tag.h
--- a/cache.h
+++ b/cache.h
@@ -127,6 +127,15 @@
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
extern int ce_match_stat(struct cache_entry *ce, struct stat *st);
extern int index_fd(unsigned char *sha1, int fd, struct stat *st);
+extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
+
+struct cache_file {
+ struct cache_file *next;
+ char lockfile[PATH_MAX];
+};
+extern int hold_index_file_for_update(struct cache_file *, const char *path);
+extern int commit_index_file(struct cache_file *);
+extern void rollback_index_file(struct cache_file *);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -36,7 +36,7 @@
#include <dirent.h>
#include "cache.h"
-static int force = 0, quiet = 0, not_new = 0;
+static int force = 0, quiet = 0, not_new = 0, refresh_cache = 0;
static void create_directories(const char *path)
{
@@ -154,6 +154,12 @@
free(new);
return error("checkout-cache: unknown file mode for %s", path);
}
+
+ if (refresh_cache) {
+ struct stat st;
+ lstat(ce->name, &st);
+ fill_stat_cache_info(ce, &st);
+ }
return 0;
}
@@ -224,6 +230,8 @@
{
int i, force_filename = 0;
const char *base_dir = "";
+ struct cache_file cache_file;
+ int newfd = -1;
if (read_cache() < 0) {
die("invalid cache");
@@ -252,12 +260,37 @@
not_new = 1;
continue;
}
+ if (!strcmp(arg, "-u")) {
+ refresh_cache = 1;
+ if (newfd < 0)
+ newfd = hold_index_file_for_update
+ (&cache_file,
+ get_index_file());
+ if (newfd < 0)
+ die("cannot open index.lock file.");
+ continue;
+ }
if (!memcmp(arg, "--prefix=", 9)) {
base_dir = arg+9;
continue;
}
}
+ if (base_dir[0]) {
+ /* when --prefix is specified we do not
+ * want to update cache.
+ */
+ if (refresh_cache) {
+ close(newfd); newfd = -1;
+ rollback_index_file(&cache_file);
+ }
+ refresh_cache = 0;
+ }
checkout_file(arg, base_dir);
}
+
+ if (0 <= newfd &&
+ (write_cache(newfd, active_cache, active_nr) ||
+ commit_index_file(&cache_file)))
+ die("Unable to write new cachefile");
return 0;
}
--- a/index.c
+++ b/index.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2005, Junio C Hamano
+ */
+#include <signal.h>
+#include "cache.h"
+
+static struct cache_file *cache_file_list;
+
+static void remove_lock_file(void)
+{
+ while (cache_file_list) {
+ if (cache_file_list->lockfile[0])
+ unlink(cache_file_list->lockfile);
+ cache_file_list = cache_file_list->next;
+ }
+}
+
+static void remove_lock_file_on_signal(int signo)
+{
+ remove_lock_file();
+}
+
+int hold_index_file_for_update(struct cache_file *cf, const char *path)
+{
+ sprintf(cf->lockfile, "%s.lock", path);
+ cf->next = cache_file_list;
+ cache_file_list = cf;
+ if (!cf->next) {
+ signal(SIGINT, remove_lock_file_on_signal);
+ atexit(remove_lock_file);
+ }
+ return open(cf->lockfile, O_RDWR | O_CREAT | O_EXCL, 0600);
+}
+
+int commit_index_file(struct cache_file *cf)
+{
+ char indexfile[PATH_MAX];
+ int i;
+ strcpy(indexfile, cf->lockfile);
+ i = strlen(indexfile) - 5; /* .lock */
+ indexfile[i] = 0;
+ i = rename(cf->lockfile, indexfile);
+ cf->lockfile[0] = 0;
+ return i;
+}
+
+void rollback_index_file(struct cache_file *cf)
+{
+ if (cf->lockfile[0])
+ unlink(cf->lockfile);
+ cf->lockfile[0] = 0;
+}
+
--- a/read-cache.c
+++ b/read-cache.c
@@ -9,6 +9,26 @@
struct cache_entry **active_cache = NULL;
unsigned int active_nr = 0, active_alloc = 0, active_cache_changed = 0;
+/*
+ * This only updates the "non-critical" parts of the directory
+ * cache, ie the parts that aren't tracked by GIT, and only used
+ * to validate the cache.
+ */
+void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
+{
+ ce->ce_ctime.sec = htonl(st->st_ctime);
+ ce->ce_mtime.sec = htonl(st->st_mtime);
+#ifdef NSEC
+ ce->ce_ctime.nsec = htonl(st->st_ctim.tv_nsec);
+ ce->ce_mtime.nsec = htonl(st->st_mtim.tv_nsec);
+#endif
+ ce->ce_dev = htonl(st->st_dev);
+ ce->ce_ino = htonl(st->st_ino);
+ ce->ce_uid = htonl(st->st_uid);
+ ce->ce_gid = htonl(st->st_gid);
+ ce->ce_size = htonl(st->st_size);
+}
+
int ce_match_stat(struct cache_entry *ce, struct stat *st)
{
unsigned int changed = 0;
--- a/t/t2002-checkout-cache-u.sh
+++ b/t/t2002-checkout-cache-u.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+test_description='git-checkout-cache -u test.
+
+With -u flag, git-checkout-cache internally runs the equivalent of
+git-update-cache --refresh on the checked out entry.'
+
+. ./test-lib.sh
+
+test_expect_success \
+'preparation' '
+echo frotz >path0 &&
+git-update-cache --add path0 &&
+t=$(git-write-tree)'
+
+test_expect_failure \
+'without -u, git-checkout-cache smudges stat information.' '
+rm -f path0 &&
+git-read-tree $t &&
+git-checkout-cache -f -a &&
+git-diff-files | diff - /dev/null'
+
+test_expect_success \
+'with -u, git-checkout-cache picks up stat information from new files.' '
+rm -f path0 &&
+git-read-tree $t &&
+git-checkout-cache -u -f -a &&
+git-diff-files | diff - /dev/null'
--- a/update-cache.c
+++ b/update-cache.c
@@ -3,7 +3,6 @@
*
* Copyright (C) Linus Torvalds, 2005
*/
-#include <signal.h>
#include "cache.h"
/*
@@ -31,26 +30,6 @@
return (unsigned long)ptr > (unsigned long)-1000L;
}
-/*
- * This only updates the "non-critical" parts of the directory
- * cache, ie the parts that aren't tracked by GIT, and only used
- * to validate the cache.
- */
-static void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
-{
- ce->ce_ctime.sec = htonl(st->st_ctime);
- ce->ce_mtime.sec = htonl(st->st_mtime);
-#ifdef NSEC
- ce->ce_ctime.nsec = htonl(st->st_ctim.tv_nsec);
- ce->ce_mtime.nsec = htonl(st->st_mtim.tv_nsec);
-#endif
- ce->ce_dev = htonl(st->st_dev);
- ce->ce_ino = htonl(st->st_ino);
- ce->ce_uid = htonl(st->st_uid);
- ce->ce_gid = htonl(st->st_gid);
- ce->ce_size = htonl(st->st_size);
-}
-
static int add_file_to_cache(char *path)
{
int size, namelen, option, status;
@@ -313,36 +292,17 @@
return add_cache_entry(ce, option);
}
-static const char *lockfile_name = NULL;
-
-static void remove_lock_file(void)
-{
- if (lockfile_name)
- unlink(lockfile_name);
-}
-
-static void remove_lock_file_on_signal(int signo)
-{
- remove_lock_file();
-}
+struct cache_file cache_file;
int main(int argc, char **argv)
{
int i, newfd, entries, has_errors = 0;
int allow_options = 1;
- static char lockfile[MAXPATHLEN+1];
- const char *indexfile = get_index_file();
-
- snprintf(lockfile, sizeof(lockfile), "%s.lock", indexfile);
- newfd = open(lockfile, O_RDWR | O_CREAT | O_EXCL, 0600);
+ newfd = hold_index_file_for_update(&cache_file, get_index_file());
if (newfd < 0)
die("unable to create new cachefile");
- signal(SIGINT, remove_lock_file_on_signal);
- atexit(remove_lock_file);
- lockfile_name = lockfile;
-
entries = read_cache();
if (entries < 0)
die("cache corrupted");
@@ -401,9 +361,9 @@
if (add_file_to_cache(path))
die("Unable to add %s to database", path);
}
- if (write_cache(newfd, active_cache, active_nr) || rename(lockfile, indexfile))
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_index_file(&cache_file))
die("Unable to write new cachefile");
- lockfile_name = NULL;
return has_errors ? 1 : 0;
}
^ permalink raw reply
* [RFC] adding merge-node to parent lines in a commit
From: Sean @ 2005-05-15 21:22 UTC (permalink / raw)
To: git
Just a random thought presented for flamage... Would adding the merge
node to each "parent" line in merge nodes be workable?
parent SHA1-PARENT SHA1-MERGE-NODE
It's not exactly clear cut I guess, especially in the case of multi-parent
merges, but it would make descending the history slightly easier. It
would let you look at any merge, and know exactly which commits were
associated with that merge, without needing any repo-id or time
information. This information is needed at the time of merge anyway, so
recording it rather than leaving it to be calculated later makes some
sense. Comments?
Cheers,
Sean
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Sean @ 2005-05-15 21:21 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1116191636.11872.195.camel@tglx>
On Sun, May 15, 2005 5:13 pm, Thomas Gleixner said:
> On Sun, 2005-05-15 at 16:45 -0400, Sean wrote:
>
>> You can continue the personal attacks or you can simply explain to the
>> list what you are trying to accomplish and why it is important and why
>> any
>> other proposal besides yours isn't worthy.
>
> I did never say, that my proposal is the world formula, but I have more
> than once explained, why time is the worst source of information.
>
> You keep beating on time as a reliable source of information and tell me
> that most people are completely happy with it. You must have access to a
> quite good opinion survey.
>
> Time of files or time in commit blobs is not a reliable information to
> keep track of
> - workflows
> - history
> Thats all I'm talking about and it is the concern of others too.
>
> In "git" repositories the only reliable source of information is the
> parent child relationship. This information is only partially reliable
> due to the head forward scenario. I think we agreed on this, right ?
> You have no other reliable source of information due to the fact that
> committer names are not unique.
>
>> I disagree that they're inherently error prone,
>> steps can be taken to make them as secure as you desire.
>
> You continue to propose stuff which is not viable. Can you enforce
> - NTP syncronisation
> - the correct usage of rsync options
> - timestamp aware backups
>
> No, you can't.
>
> Why did the mail people resort to "In-Reply-To", "Message-ID" and
> "References" ? Because time turned out to be an inreliable source of
> information. Please read the related discussions before you argue that
> time based solutions are sufficient.
>
> Time is illusion.
What you're missing is that time is only important in this case to deduce
the relative age of each commit LOCALLY. The intention of this proposal
is not to allow time comparison of commits between repositories. In fact,
you'll see if you look closely, that you don't need to do that in order to
solve the stated problem of sorting the commits by the time they were
merged LOCALLY.
Cheers,
Sean
^ permalink raw reply
* [PATCH 4/4] Trivial test harness fixes.
From: Junio C Hamano @ 2005-05-15 21:21 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
The documentation of the test harness still refer to old
numbering and also contains an obvious typo.
Also "make test" should be run after making sure we have built
all binaries, since test is designed to test the newly built
ones.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 +-
t/README | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -120,7 +120,7 @@
strbuf.o: $(LIB_H)
gitenv.o: $(LIB_H)
-test:
+test: all
make -C t/ all
clean:
--- a/t/README
+++ b/t/README
@@ -32,7 +32,7 @@
Or you can run each test individually from command line, like
this:
- $ sh ./t0500-ls-files.sh
+ $ sh ./t3001-ls-files-killed.sh
* ok 1: git-update-cache --add to add various paths.
* ok 2: git-ls-files -k to show killed files.
* ok 3: validate git-ls-files -k output.
@@ -92,7 +92,7 @@
# Copyright (c) 2005 Junio C Hamano
#
- test_description=xxx test (option --frotz)
+ test_description='xxx test (option --frotz)
This test registers the following structure in the cache
and tries to run git-ls-files with option --frotz.'
@@ -120,6 +120,7 @@
consistently when command line arguments --verbose (or -v),
--debug (or -d), and --immediate (or -i) is given.
+
End with test_done
------------------
^ permalink raw reply
* [PATCH 2/4] Tweak diff output further to make it a bit less distracting.
From: Junio C Hamano @ 2005-05-15 21:19 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
Adds an newline between each diff. Also change "#mode : "
string, which was misleading in that we are not showing just
mode when we talk about a file changing into a symlink.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.c | 18 ++++++++++--------
t/t4000-diff-format.sh | 6 ++++--
2 files changed, 14 insertions(+), 10 deletions(-)
--- a/diff.c
+++ b/diff.c
@@ -83,7 +83,7 @@
struct diff_tempfile *temp)
{
int i, next_at;
- const char *git_prefix = "# mode: ";
+ const char *git_prefix = "\n@. ";
const char *diff_cmd = "diff -L'%s%s' -L'%s%s'";
const char *diff_arg = "'%s' '%s'||:"; /* "||:" is to return 0 */
const char *input_name_sq[2];
@@ -128,15 +128,17 @@
else if (!path1[1][0])
printf("%s%s . %s\n", git_prefix, temp[0].mode, name);
else {
- if (strcmp(temp[0].mode, temp[1].mode))
+ if (strcmp(temp[0].mode, temp[1].mode)) {
printf("%s%s %s %s\n", git_prefix,
temp[0].mode, temp[1].mode, name);
-
- if (strncmp(temp[0].mode, temp[1].mode, 3))
- /* we do not run diff between different kind
- * of objects.
- */
- exit(0);
+ if (strncmp(temp[0].mode, temp[1].mode, 3))
+ /* we do not run diff between different kind
+ * of objects.
+ */
+ exit(0);
+ }
+ else
+ putchar('\n');
}
fflush(NULL);
execlp("/bin/sh","sh", "-c", cmd, NULL);
--- a/t/t4000-diff-format.sh
+++ b/t/t4000-diff-format.sh
@@ -26,7 +26,8 @@
'git-diff-files -p after editing work tree.' \
'git-diff-files -p >current'
cat >expected <<\EOF
-# mode: 100644 100755 path0
+
+@. 100644 100755 path0
--- a/path0
+++ b/path0
@@ -1,3 +1,3 @@
@@ -34,7 +35,8 @@
Line 2
-line 3
+Line 3
-# mode: 100755 . path1
+
+@. 100755 . path1
--- a/path1
+++ /dev/null
@@ -1,3 +0,0 @@
^ permalink raw reply
* [PATCH 1/4] Add --author and --committer match to git-rev-list and git-rev-tree.
From: Junio C Hamano @ 2005-05-15 21:18 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
Zack Brown wondered if handling author match at core GIT level
would make cg-log -u go faster (JIT also can use this in jit-log
--author). Later Peter Baudis wanted to have --committer match
similar to it.
This version is improved from the one I posted to GIT list
earlier in that:
(1) I bit the bullet and added author and committer names to
the commit object, so there is no double unpacking anymore.
The strings are shared across multiple commits so consider
them intern'ed and do not free them.
(2) Determination of if author and committer names are
"interesting" is done only once per name, not per commit.
This version uses simple "substring" logic, but it is
easily extendable for more interesting match such as
regexps.
This also fixes documentation of git-rev-list which did not
describe its already existing options.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-rev-list.txt | 19 +++++
Documentation/git-rev-tree.txt | 8 +-
commit.c | 135 +++++++++++++++++++++++++++++++++-----
commit.h | 18 ++++-
rev-list.c | 18 ++++-
rev-tree.c | 27 +++++++
t/t6010-rev-tree-author-commit.sh | 98 +++++++++++++++++++++++++++
t/t6110-rev-list-author-commit.sh | 97 +++++++++++++++++++++++++++
8 files changed, 396 insertions(+), 24 deletions(-)
t/t6010-rev-tree-author-commit.sh (. --> 100755)
t/t6110-rev-list-author-commit.sh (. --> 100755)
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -9,7 +9,7 @@
SYNOPSIS
--------
-'git-rev-list' <commit>
+'git-rev-list' [--author=author] [--committer=committer] [--max-count=count] [--max-age=unixtime] [--min-age=unixtime] <commit>
DESCRIPTION
-----------
@@ -18,6 +18,23 @@
useful to produce human-readable log output.
+OPTIONS
+-------
+--author::
+ Limit the final output to commits written by the author.
+
+--committer::
+ Limit the final output to commits committed by the author.
+
+--max-count::
+ Stop after showing the specified number of commits.
+
+--max-age::
+ Stop before showing the commits older than specified time.
+
+--min-age::
+ Do not show the commits newer than specified time.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
--- a/Documentation/git-rev-tree.txt
+++ b/Documentation/git-rev-tree.txt
@@ -9,7 +9,7 @@
SYNOPSIS
--------
-'git-rev-tree' [--edges] [--cache <cache-file>] [^]<commit> [[^]<commit>]
+'git-rev-tree' [--author author] [--committer committer] [--edges] [--cache <cache-file>] [^]<commit> [[^]<commit>]
DESCRIPTION
-----------
@@ -17,6 +17,12 @@
OPTIONS
-------
+--author::
+ Limit the final output to commits written by the author.
+
+--committer::
+ Limit the final output to commits committed by the author.
+
--edges::
Show edges (ie places where the marking changes between parent
and child)
--- a/commit.c
+++ b/commit.c
@@ -23,22 +23,111 @@
return (struct commit *) obj;
}
-static unsigned long parse_commit_date(const char *buf)
-{
- unsigned long date;
+static struct person_name **person_name;
+static int person_nr;
+static int person_alloc;
+
+static const char *interesting_author = NULL;
+static const char *interesting_committer = NULL;
+
+void commit_author_committer_match_initialize(const char *author,
+ const char *committer)
+{
+ interesting_author = author;
+ interesting_committer = committer;
+}
+
+static int person_name_pos(const char *name)
+{
+ int first, last;
+
+ first = 0;
+ last = person_nr;
+ while (last > first) {
+ int next = (last + first) >> 1;
+ struct person_name *pn = person_name[next];
+ int cmp = strcmp(name, pn->name);
+ if (!cmp)
+ return next;
+ if (cmp < 0) {
+ last = next;
+ continue;
+ }
+ first = next+1;
+ }
+ return -first-1;
+}
- if (memcmp(buf, "author", 6))
- return 0;
- while (*buf++ != '\n')
- /* nada */;
- if (memcmp(buf, "committer", 9))
- return 0;
- while (*buf++ != '>')
- /* nada */;
- date = strtoul(buf, NULL, 10);
- if (date == ULONG_MAX)
- date = 0;
- return date;
+#define INTERESTING_AUTHOR 01
+#define INTERESTING_COMMITTER 02
+
+static struct person_name *person_name_lookup(const char *name)
+{
+ int pos = person_name_pos(name);
+ struct person_name *pn;
+ if (0 <= pos)
+ return person_name[pos];
+ pos = -pos-1;
+ pn = xmalloc(sizeof(*pn) + strlen(name) + 1);
+ strcpy(pn->name, name);
+ pn->mark = 0;
+
+ /*
+ * When we decide we want to go fancier, strstr() below
+ * can be replaced with something like regexp match to
+ * pick up more than one author or committer. For now
+ * let's try simple substring find and see what happens.
+ * Note that not specifying anybody means we are interested
+ * in everybody.
+ */
+ if (!interesting_author || strstr(name, interesting_author))
+ pn->mark |= INTERESTING_AUTHOR;
+ if (!interesting_committer || strstr(name, interesting_committer))
+ pn->mark |= INTERESTING_COMMITTER;
+
+ if (person_nr == person_alloc) {
+ person_alloc = alloc_nr(person_alloc);
+ person_name = xrealloc(person_name, person_alloc *
+ sizeof(struct person_name *));
+ }
+ person_nr++;
+ if (pos < person_nr)
+ memmove(person_name + pos + 1, person_name + pos,
+ (person_nr - pos - 1) * sizeof(pn));
+ person_name[pos] = pn;
+ return pn;
+}
+
+static void *parse_commit_nametime(char *ptr, const char *ep,
+ const char *field,
+ unsigned long *date,
+ struct person_name **name)
+{
+ unsigned long d;
+ char *cp;
+ int fldlen = strlen(field);
+ if (ptr == NULL || memcmp(ptr, field, fldlen) || ptr[fldlen] != ' ') {
+ *date = 0;
+ *name = NULL;
+ return NULL; /* malformed commit */
+ }
+ for (cp = ptr + fldlen + 1; cp < ep && *cp != '>'; cp++)
+ ; /* skip */
+ if (*cp != '>' || *++cp != ' ') {
+ *date = 0;
+ *name = NULL;
+ return NULL; /* malformed commit */
+ }
+ *cp = 0;
+ *name = person_name_lookup(ptr + fldlen + 1);
+ *cp++ = ' ';
+ d = strtoul(cp, NULL, 10);
+ if (d == ULONG_MAX)
+ d = 0;
+ *date = d;
+ while (cp < ep && *cp++ != '\n')
+ ; /* skip */
+ return cp;
}
int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
@@ -63,7 +152,13 @@
}
bufptr += 48;
}
- item->date = parse_commit_date(bufptr);
+
+ bufptr = parse_commit_nametime(bufptr, (char *)buffer + size,
+ "author", &item->author_date,
+ &item->author);
+ parse_commit_nametime(bufptr, (char *)buffer + size,
+ "committer", &item->date,
+ &item->committer);
return 0;
}
@@ -152,3 +247,11 @@
}
return ret;
}
+
+int commit_author_committer_match(struct commit *item)
+{
+ return ( ((item->author != NULL) &&
+ (item->author->mark & INTERESTING_AUTHOR)) &&
+ ((item->committer != NULL) &&
+ (item->committer->mark & INTERESTING_COMMITTER)) );
+}
--- a/commit.h
+++ b/commit.h
@@ -11,8 +11,9 @@
struct commit {
struct object object;
- unsigned long date;
+ unsigned long author_date, date;
struct commit_list *parents;
+ struct person_name *author, *committer;
struct tree *tree;
};
@@ -36,4 +37,19 @@
struct commit *pop_most_recent_commit(struct commit_list **list,
unsigned int mark);
+struct person_name {
+ char mark;
+ char name[0];
+};
+
+/* This function must be called before fetching any commit object
+ * if commit-author-committer-match function is to be used to filter
+ * commits for output. Passing NULL is permitted, which makes all
+ * authors (or committers) "interesting".
+ */
+void commit_author_committer_match_initialize(const char *, const char *);
+
+/* Returns true only if author and committer are "interesting". */
+int commit_author_committer_match(struct commit *);
+
#endif /* COMMIT_H */
--- a/rev-list.c
+++ b/rev-list.c
@@ -11,6 +11,8 @@
unsigned long max_age = -1;
unsigned long min_age = -1;
int max_count = -1;
+ const char *author = NULL;
+ const char *committer = NULL;
for (i = 1 ; i < argc; i++) {
char *arg = argv[i];
@@ -21,6 +23,10 @@
max_age = atoi(arg + 10);
} else if (!strncmp(arg, "--min-age=", 10)) {
min_age = atoi(arg + 10);
+ } else if (!strncmp(arg, "--author=", 9)) {
+ author = arg + 9;
+ } else if (!strncmp(arg, "--committer=", 12)) {
+ committer = arg + 12;
} else {
commit_arg = arg;
}
@@ -28,9 +34,13 @@
if (!commit_arg || get_sha1(commit_arg, sha1))
usage("usage: rev-list [OPTION] commit-id\n"
- " --max-count=nr\n"
- " --max-age=epoch\n"
- " --min-age=epoch\n");
+ " --author=author\n"
+ " --committer=committer\n"
+ " --max-count=number\n"
+ " --max-age=unixtime\n"
+ " --min-age=unixtime\n");
+
+ commit_author_committer_match_initialize(author, committer);
commit = lookup_commit(sha1);
if (!commit || parse_commit(commit) < 0)
@@ -44,6 +54,8 @@
continue;
if (max_age != -1 && (commit->date < max_age))
break;
+ if (!commit_author_committer_match(commit))
+ continue;
if (max_count != -1 && !max_count--)
break;
printf("%s\n", sha1_to_hex(commit->object.sha1));
--- a/rev-tree.c
+++ b/rev-tree.c
@@ -64,7 +64,7 @@
}
/*
- * Usage: rev-tree [--edges] [--cache <cache-file>] <commit-id> [<commit-id2>]
+ * Usage: rev-tree [--edges] [--author <author>] [--cache <cache-file>] <commit-id> [<commit-id2>]
*
* The cache-file can be quite important for big trees. This is an
* expensive operation if you have to walk the whole chain of
@@ -75,6 +75,9 @@
int i;
int nr = 0;
unsigned char sha1[MAX_COMMITS][20];
+ const char *author = NULL;
+ const char *committer = NULL;
+ int initialized_author_commiter = 0;
/*
* First - pick up all the revisions we can (both from
@@ -83,6 +86,16 @@
for (i = 1; i < argc ; i++) {
char *arg = argv[i];
+ if (!strcmp(arg, "--author")) {
+ author = argv[++i];
+ continue;
+ }
+
+ if (!strcmp(arg, "--committer")) {
+ committer = argv[++i];
+ continue;
+ }
+
if (!strcmp(arg, "--cache")) {
read_cache_file(argv[++i]);
continue;
@@ -98,7 +111,14 @@
basemask |= 1<<nr;
}
if (nr >= MAX_COMMITS || get_sha1(arg, sha1[nr]))
- usage("rev-tree [--edges] [--cache <cache-file>] <commit-id> [<commit-id>]");
+ usage("rev-tree [--edges] [--author <author>] [--committer <committer>] [--cache <cache-file>] <commit-id> [<commit-id>]");
+
+ if (!initialized_author_commiter) {
+ commit_author_committer_match_initialize(author,
+ committer);
+ initialized_author_commiter = 1;
+ }
+
process_commit(sha1[nr]);
nr++;
}
@@ -125,6 +145,9 @@
if (!interesting(commit))
continue;
+ if (!commit_author_committer_match(commit))
+ continue;
+
printf("%lu %s:%d", commit->date, sha1_to_hex(obj->sha1),
obj->flags);
p = commit->parents;
--- a/t/t6010-rev-tree-author-commit.sh
+++ b/t/t6010-rev-tree-author-commit.sh
@@ -0,0 +1,98 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+test_description='git-rev-tree --author and --committer flags.
+'
+
+. ./test-lib.sh
+
+export_them () {
+export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL
+}
+
+set_author_zero () {
+ GIT_AUTHOR_NAME="A U Thor" &&
+ GIT_AUTHOR_EMAIL="<author@example.xz>"
+}
+set_author_one () {
+ GIT_AUTHOR_NAME="R O Htua" &&
+ GIT_AUTHOR_EMAIL="<rohtua@example.xz>"
+}
+set_committer_zero () {
+ GIT_COMMITTER_NAME="C O Mmitter" &&
+ GIT_COMMITTER_EMAIL="<committer@example.xz>"
+}
+set_committer_one () {
+ GIT_COMMITTER_NAME="R E Ttimmoc" &&
+ GIT_COMMITTER_EMAIL="<rettimmoc@example.xz>"
+}
+
+# read rev-tree output, and find the author|committer of commit object
+pick_actor () {
+ sed -e 's/^[^ ]* //;s/:.*//' |
+ xargs -r -n1 git-cat-file commit |
+ sed -ne 's/^\('"$1"'\) \([^>]*>\).*/\2/p'
+}
+
+test_expect_success \
+ 'preparation' '
+echo frotz >path0 &&
+git-update-cache --add path0 &&
+tree0=$(git-write-tree) &&
+
+set_author_zero &&
+set_committer_zero &&
+export_them &&
+commit0=$(echo frotz | git-commit-tree $tree0) &&
+
+set_author_zero &&
+set_committer_one &&
+export_them &&
+commit1=$(echo frotz | git-commit-tree $tree0 -p $commit0) &&
+
+set_author_one &&
+set_committer_zero &&
+export_them &&
+commit2=$(echo frotz | git-commit-tree $tree0 -p $commit1) &&
+
+set_author_one &&
+set_committer_one &&
+export_them &&
+commit3=$(echo frotz | git-commit-tree $tree0 -p $commit2)'
+
+test_expect_success \
+ 'without restriction git-rev-tree should report all four commits.' \
+ 'test $(git-rev-tree $commit3 | wc -l) == 4'
+
+test_expect_success \
+ 'limiting to A U Thor (two commits)' '
+ case "$(git-rev-tree --author "A U Thor" $commit3 |
+ pick_actor "author" | sort -u)" in
+ "A U Thor <author@example.xz>") : ;;
+ *) (exit 1) ;;
+ esac'
+
+test_expect_success \
+ 'limiting to R E Ttimmoc (two commits)' '
+ case "$(git-rev-tree --committer "R E Ttimmoc" $commit3 |
+ pick_actor "committer" | sort -u)" in
+ "R E Ttimmoc <rettimmoc@example.xz>") : ;;
+ *) (exit 1) ;;
+ esac'
+
+LF='
+'
+
+test_expect_success \
+ 'limiting to A U Thor and C O Mmitter (one commit)' '
+ case "$(git-rev-tree --author "A U Thor" --committer "C O Mmitter" \
+ $commit3 | pick_actor "committer\\|author" | sort -u)" in
+ "A U Thor <author@example.xz>${LF}C O Mmitter <committer@example.xz>")
+ : ;;
+ *) (exit 1) ;;
+ esac
+'
+
+test_done
--- a/t/t6110-rev-list-author-commit.sh
+++ b/t/t6110-rev-list-author-commit.sh
@@ -0,0 +1,97 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+
+test_description='git-rev-list --author and --committer flags.
+'
+
+. ./test-lib.sh
+
+export_them () {
+export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL
+}
+
+set_author_zero () {
+ GIT_AUTHOR_NAME="A U Thor" &&
+ GIT_AUTHOR_EMAIL="<author@example.xz>"
+}
+set_author_one () {
+ GIT_AUTHOR_NAME="R O Htua" &&
+ GIT_AUTHOR_EMAIL="<rohtua@example.xz>"
+}
+set_committer_zero () {
+ GIT_COMMITTER_NAME="C O Mmitter" &&
+ GIT_COMMITTER_EMAIL="<committer@example.xz>"
+}
+set_committer_one () {
+ GIT_COMMITTER_NAME="R E Ttimmoc" &&
+ GIT_COMMITTER_EMAIL="<rettimmoc@example.xz>"
+}
+
+# read rev-list output, and find the author|committer of commit object
+pick_actor () {
+ xargs -r -n1 git-cat-file commit |
+ sed -ne 's/^\('"$1"'\) \([^>]*>\).*/\2/p'
+}
+
+test_expect_success \
+ 'preparation' '
+echo frotz >path0 &&
+git-update-cache --add path0 &&
+tree0=$(git-write-tree) &&
+
+set_author_zero &&
+set_committer_zero &&
+export_them &&
+commit0=$(echo frotz | git-commit-tree $tree0) &&
+
+set_author_zero &&
+set_committer_one &&
+export_them &&
+commit1=$(echo frotz | git-commit-tree $tree0 -p $commit0) &&
+
+set_author_one &&
+set_committer_zero &&
+export_them &&
+commit2=$(echo frotz | git-commit-tree $tree0 -p $commit1) &&
+
+set_author_one &&
+set_committer_one &&
+export_them &&
+commit3=$(echo frotz | git-commit-tree $tree0 -p $commit2)'
+
+test_expect_success \
+ 'without restriction git-rev-tree should report all four commits.' \
+ 'test $(git-rev-list $commit3 | wc -l) == 4'
+
+test_expect_success \
+ 'limiting to A U Thor (two commits)' '
+ case "$(git-rev-list --author="A U Thor" $commit3 |
+ pick_actor "author" | sort -u)" in
+ "A U Thor <author@example.xz>") : ;;
+ *) (exit 1) ;;
+ esac'
+
+test_expect_success \
+ 'limiting to R E Ttimmoc (two commits)' '
+ case "$(git-rev-list --committer="R E Ttimmoc" $commit3 |
+ pick_actor "committer" | sort -u)" in
+ "R E Ttimmoc <rettimmoc@example.xz>") : ;;
+ *) (exit 1) ;;
+ esac'
+
+LF='
+'
+
+test_expect_success \
+ 'limiting to A U Thor and C O Mmitter (one commit)' '
+ case "$(git-rev-list --author="A U Thor" --committer="C O Mmitter" \
+ $commit3 | pick_actor "committer\\|author" | sort -u)" in
+ "A U Thor <author@example.xz>${LF}C O Mmitter <committer@example.xz>")
+ : ;;
+ *) (exit 1) ;;
+ esac
+'
+
+test_done
------------------------------------------------
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Thomas Gleixner @ 2005-05-15 21:13 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <1102.10.10.10.24.1116189916.squirrel@linux1>
On Sun, 2005-05-15 at 16:45 -0400, Sean wrote:
> You can continue the personal attacks or you can simply explain to the
> list what you are trying to accomplish and why it is important and why any
> other proposal besides yours isn't worthy.
I did never say, that my proposal is the world formula, but I have more
than once explained, why time is the worst source of information.
You keep beating on time as a reliable source of information and tell me
that most people are completely happy with it. You must have access to a
quite good opinion survey.
Time of files or time in commit blobs is not a reliable information to
keep track of
- workflows
- history
Thats all I'm talking about and it is the concern of others too.
In "git" repositories the only reliable source of information is the
parent child relationship. This information is only partially reliable
due to the head forward scenario. I think we agreed on this, right ?
You have no other reliable source of information due to the fact that
committer names are not unique.
> I disagree that they're inherently error prone,
> steps can be taken to make them as secure as you desire.
You continue to propose stuff which is not viable. Can you enforce
- NTP syncronisation
- the correct usage of rsync options
- timestamp aware backups
No, you can't.
Why did the mail people resort to "In-Reply-To", "Message-ID" and
"References" ? Because time turned out to be an inreliable source of
information. Please read the related discussions before you argue that
time based solutions are sufficient.
Time is illusion.
tglx
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Sean @ 2005-05-15 20:45 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1116189873.11872.171.camel@tglx>
On Sun, May 15, 2005 4:44 pm, Thomas Gleixner said:
> On Sun, 2005-05-15 at 15:57 -0400, Sean wrote:
>> Afterall, most people using git are getting by
>> just fine without such a facility today.
>
> Axiom 1:
> Sean knows exactly what people care about
>
> Axiom 2:
> Time is a reliable source of information.
>
> Axiom 3:
> All information except X can be derived from time.
>
> Axiom 4:
> Most people dont care about X, therefor X is irrelevant.
>
> Axiom 5:
> If doubts, see Axiom 1
>
Thomas,
You can continue the personal attacks or you can simply explain to the
list what you are trying to accomplish and why it is important and why any
other proposal besides yours isn't worthy.
Sean
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Thomas Gleixner @ 2005-05-15 20:44 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <4971.10.10.10.24.1116187076.squirrel@linux1>
On Sun, 2005-05-15 at 15:57 -0400, Sean wrote:
> Afterall, most people using git are getting by
> just fine without such a facility today.
Axiom 1:
Sean knows exactly what people care about
Axiom 2:
Time is a reliable source of information.
Axiom 3:
All information except X can be derived from time.
Axiom 4:
Most people dont care about X, therefor X is irrelevant.
Axiom 5:
If doubts, see Axiom 1
tglx
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Junio C Hamano @ 2005-05-15 20:36 UTC (permalink / raw)
To: Brad Roberts; +Cc: Petr Baudis, Juliusz Chroboczek, git
In-Reply-To: <Pine.LNX.4.44.0505151309030.2136-100000@bellevue.puremagic.com>
>>>>> "BR" == Brad Roberts <braddr@puremagic.com> writes:
BR> Additionally, all of these changes were posted originally on 4/22, this
BR> was just a bring-forward of them as requested.
I admit I overreacted without first seeing the extent of damage.
Sorry I made too big a fuss about this.
The 4/22 one I found very good and expected it to be in good
shape when finished. I simply did not expect that to be taken
piecemeal like Petr did. I overreacted, thinking he did so
_without_ considering much about possible conflicts.
The request to _continue_ using good judgements when to forewarn
people still stands ;-). In this case, Petr used good
judgement. My apologies to both of you if my knee-jerk reaction
caused you bad feelings.
^ permalink raw reply
* [RFD] git-run-with-user-path
From: Junio C Hamano @ 2005-05-15 20:27 UTC (permalink / raw)
To: Petr Baudis, torvalds; +Cc: GIT Mailing Lists
In-Reply-To: <7v4qd5vxao.fsf@assigned-by-dhcp.cox.net>
Petr, I have not written the implementation yet, but do you
think Cogito would find something like this useful? I've seen
some patch to add running from subdirectory support to cg-add in
the mailing list and I assume Cogito is in the process of being
enhanced in this area.
JIT has been supporting running from the subdirectory from the
day one, but has been using a bit different mechanism. If we
can agree on a core-ish helper (I consider this just as non-core
as git-diff-helper is), I would want to switch to use something
like this one.
This _deliberately_ conflates the user-path canonicalization
with the ignore-list processing discussed recently on the list.
When you think about it, they are very closely related and
handling them at the same place makes more sense than having
them separately. It is a way to munge paths given by users and
"find -print0 | xargs -0" into a form appropriate for core GIT
consumption. Similar reasoning with which you accepted the use
of cg-Xignore by David Greaves in cg-commit.
Linus, and everybody else, suggestions and comments?
------------
git-run-with-user-path(1)
=========================
v0.1, May 2005
NAME
----
git-run-with-user-path - Run command from the top after canonicalizing paths.
SYNOPSIS
--------
'git-run-with-user-path' [options] <command> <argument>... '--' <path>...
DESCRIPTION
-----------
This command takes a <command>, zero or more <argument> and zero
or more <path> arguments. <path> arguments name objects on the
filesystem, <command> is typically a core GIT command, and
<argument> are the initial arguments to the <command>.
It first finds the project top directory (the directory that
corresponds to the top of the tree structure GIT_INDEX_FILE
describes), and canonicalizes the given <path> to be relative to
the project top. It then chdir(2)'s to the project top
directory and runs the given <command>, with <argument> and
these canonicalized <path> arguments.
This is useful for the Porcelain layer to run core GIT commands
from subdirectories. For example, if linux-2.6.git tree is
checked out in /usr/src/linux, you can do:
$ cd /usr/src/linux/fs
$ ... work in fs directory making changes ...
$ git-run-with-user-path git-diff-tree -r HEAD -- ext? ../include/linux
$ find ext? ! -type d -print0 |
xargs -0 git-run-with-user-path git-update-cache --add -- --
The above is roughly equivalent to:
$ cd /usr/src/linux
$ git-diff-tree -r HEAD fs/ext? include/linux
$ find fs/ext? include/linux ! -type d -print0 |
xargs git-update-cache --add --
OPTIONS
-------
--no-ignore::
By default, the path arguments are filtered with the
same ignore rules Porcelain layers use. With
--no-ignore flag, there is no such filtering done.
Author
------
Written by Junio C Hamano <junkio@cox.net>
Documentation
--------------
Documentation by Junio C Hamano.
GIT
---
Part of the link:git.html[git] suite
^ permalink raw reply
* Re: git repository for net drivers available
From: Jeff Garzik @ 2005-05-15 20:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: James Ketrenos, Netdev, Linux Kernel, git, Andrew Morton
In-Reply-To: <20050515200514.GA31414@pasky.ji.cz>
Petr Baudis wrote:
> Dear diary, on Fri, May 13, 2005 at 05:29:30PM CEST, I got a letter
> where Jeff Garzik <jgarzik@pobox.com> told me that...
>
>>Looks like cogito is using $repo/heads/$branch, whereas my git repo is
>>using $repo/branches/$branch.
>
>
> Would it be a big problem to use refs/heads/$branch? That's the
> currently commonly agreed convention about location for storing branch
> heads, not just some weird Cogito-specific invention. And it'd be very
> nice to have those locations consistent across git repositories.
Sure, that's doable.
I've pushed out this change to kernel.org.
Jeff
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Brad Roberts @ 2005-05-15 20:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Juliusz Chroboczek, git
In-Reply-To: <20050515194803.GI13024@pasky.ji.cz>
> Date: Sun, 15 May 2005 21:48:03 +0200
> From: Petr Baudis <pasky@ucw.cz>
> To: Junio C Hamano <junkio@cox.net>
> Cc: Brad Roberts <braddr@puremagic.com>,
> Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>,
> git@vger.kernel.org
> Subject: Re: Darcs-git: a few notes for Git hackers
>
> Dear diary, on Sun, May 15, 2005 at 09:25:06PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
> > >>>>> "BR" == Brad Roberts <braddr@puremagic.com> writes:
> >
> > >> I've merged some of the minor stuff for now.
> >
> > BR> Cool, though there appears to have been some objections. :)
> >
> > I do not have any problem with what the _patch_ does at all. I
> > had more trouble in the process of how the patch appeared in
> > git-pb tree, and I still do.
> >
> > Please consider the revert request retracted. Request to
> > forewarn people in the mailing list still stands.
>
> Well, it isn't like this was some huge large-scale change; the diff is
> quite small. Do you want me to announce _any_ identifier renames in
> advance on the mailing list? Or where should be the threshold? These
> were three renames of not-so-frequently used identifiers.
Additionally, all of these changes were posted originally on 4/22, this
was just a bring-forward of them as requested.
Later,
Brad
^ permalink raw reply
* Re: git repository for net drivers available
From: Petr Baudis @ 2005-05-15 20:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: James Ketrenos, Netdev, Linux Kernel, git
In-Reply-To: <4284C7DA.1020707@pobox.com>
Dear diary, on Fri, May 13, 2005 at 05:29:30PM CEST, I got a letter
where Jeff Garzik <jgarzik@pobox.com> told me that...
> Looks like cogito is using $repo/heads/$branch, whereas my git repo is
> using $repo/branches/$branch.
Would it be a big problem to use refs/heads/$branch? That's the
currently commonly agreed convention about location for storing branch
heads, not just some weird Cogito-specific invention. And it'd be very
nice to have those locations consistent across git repositories.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Sean @ 2005-05-15 19:57 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1116186533.11872.152.camel@tglx>
On Sun, May 15, 2005 3:48 pm, Thomas Gleixner said:
> On Sat, 2005-05-14 at 17:44 -0400, Sean wrote:
>> Attached is a preliminary hackish patch to sort git-rev-list in local
>> commit order.
>
> +unsigned long sha1_local_date(const unsigned char *sha1)
> +{
> + struct stat st;
> + if (find_sha1_file(sha1, &st))
> + return st.st_mtime;
> + return 0;
> +}
>
> Do you really want to base workflow and history information on file
> times ?
The local commit order just isn't all that important in many situations.
And for situations where it is important, this proposal seems completely
adequate. Mind you, the patch in question is complete crap.
> File times are local and completely error prone in distributed
> environments.
I disagree that they're inherently error prone, steps can be taken to make
them as secure as you desire. Also, many people just will not care about
this local-commit-time as they will simply be tracking a remote
repository. For applications like David Woodhouse's need to present the
newest commits first on a web page, this is _completely_ adequate. I've
yet to see an intended use for this information that isn't completely
handled by this proposal. Afterall, most people using git are getting by
just fine without such a facility today.
Regards,
Sean
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Petr Baudis @ 2005-05-15 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brad Roberts, Juliusz Chroboczek, git
In-Reply-To: <7vfywothpp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, May 15, 2005 at 09:25:06PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "BR" == Brad Roberts <braddr@puremagic.com> writes:
>
> >> I've merged some of the minor stuff for now.
>
> BR> Cool, though there appears to have been some objections. :)
>
> I do not have any problem with what the _patch_ does at all. I
> had more trouble in the process of how the patch appeared in
> git-pb tree, and I still do.
>
> Please consider the revert request retracted. Request to
> forewarn people in the mailing list still stands.
Well, it isn't like this was some huge large-scale change; the diff is
quite small. Do you want me to announce _any_ identifier renames in
advance on the mailing list? Or where should be the threshold? These
were three renames of not-so-frequently used identifiers.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Thomas Gleixner @ 2005-05-15 19:48 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <4127.10.10.10.24.1116107046.squirrel@linux1>
On Sat, 2005-05-14 at 17:44 -0400, Sean wrote:
> Attached is a preliminary hackish patch to sort git-rev-list in local
> commit order.
+unsigned long sha1_local_date(const unsigned char *sha1)
+{
+ struct stat st;
+ if (find_sha1_file(sha1, &st))
+ return st.st_mtime;
+ return 0;
+}
Do you really want to base workflow and history information on file
times ?
File times are local and completely error prone in distributed
environments.
tglx
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Junio C Hamano @ 2005-05-15 19:25 UTC (permalink / raw)
To: Brad Roberts; +Cc: Petr Baudis, Juliusz Chroboczek, git
In-Reply-To: <Pine.LNX.4.44.0505151204230.2136-100000@bellevue.puremagic.com>
>>>>> "BR" == Brad Roberts <braddr@puremagic.com> writes:
>> I've merged some of the minor stuff for now.
BR> Cool, though there appears to have been some objections. :)
I do not have any problem with what the _patch_ does at all. I
had more trouble in the process of how the patch appeared in
git-pb tree, and I still do.
Please consider the revert request retracted. Request to
forewarn people in the mailing list still stands.
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Brad Roberts @ 2005-05-15 19:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: Juliusz Chroboczek, git
In-Reply-To: <20050515114847.GD13024@pasky.ji.cz>
> Date: Sun, 15 May 2005 13:48:47 +0200
> From: Petr Baudis <pasky@ucw.cz>
> To: Brad Roberts <braddr@puremagic.com>
> Cc: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>,
> git@vger.kernel.org
> Subject: Re: Darcs-git: a few notes for Git hackers
>
> Dear diary, on Sun, May 15, 2005 at 04:04:25AM CEST, I got a letter
> where Brad Roberts <braddr@puremagic.com> told me that...
> > > I wasn't able to finish redoing these against linus tip, but I got most of
> > > it done (patches 1-14 of the original 19):
> > >
> > > http://gameboy2.puremagic.com:8090/
> > > rsync://gameboy2.puremagic.com/git/
> > >
> > > The second, third, and forth to last changes need a careful review,
> > > they're direct applications of the original patches which were lightly
> > > tested during the first round and nothing other than compile tested in
> > > this round.
> > >
> > > I suspect the remaining parts of the original patch series will go in
> > > fairly smoothly. If no one gets to them before tonight I'll finish
> > > it up after work.
> > >
> > > Later,
> > > Brad
> >
> > I've completed the re-merge, and moved to tip of git-pb.git rather than
> > tip of git.git. Unfortunatly that merge was also somewhat intrusive and
> > my individual diffs along the way are somewhat useless now. The entire
> > history is available about the above locations still. Attached is the
> > full diff vs git-pb @ 902b92e00e491a60d55c4b2bce122903b8347f34.
>
> I've merged some of the minor stuff for now.
Cool, though there appears to have been some objections. :)
> > 2) Should the index changing areas be constructing a new index instead of
> > shuffling bits within the current index?
>
> When I have a big cache (the only time it matters), I do usually only
> relatively small changes to it, so...
The entire index is bit shuffled around even if nothing changed. At least
today, size and amount changed doesn't matter.
> > 3) The vocabulary and code is inconsistent between cache and index.
>
> Yes...
>
> > 4) read-cache.c does much more than reading.
>
> and yes. And cache.h is full of crap. Perhaps we could move read-cache.c
> to cache.c?
At least parts of it, probably yes.
> I'd imagine the plan of attack to continue by changing active_cache to
> be struct cache, then making it local.
Which is what the rest of that patch does.
Thanks for looking at this.
Later,
Brad
^ permalink raw reply
* Request reverting some from git-pb
From: Junio C Hamano @ 2005-05-15 18:29 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
Petr, you added two small patches to git-pb recently.
* Rename some more cache-related functions
* Rename cache_match_stat() to ce_match_stat()
I would really appreciate if you do not do these name clean-ups
yet, _especially_ not without having GIT mailing list discussion
about it first. This kind of changes inevitably introduce merge
conflicts.
I suspect this is something you lifted from a larger
libification patch. While I think name cleanups are good in the
long run, I do not see value in lifting only some name cleanups
from the libification patch and having people to adjust for the
merge conflicts twice (now and when libification is ready to be
included). I would not mind if these renames happen as a part
of libification as a whole. Pending patches need to be
inspected and adjusted when that happens anyway. But not until
then, at least please have a courtesy to give people a warning
and an opportunity to speak out.
^ permalink raw reply
* Request reverting some from git-pb
From: Junio C Hamano @ 2005-05-15 18:25 UTC (permalink / raw)
To: pasky; +Cc: git, torvalds
Petr, please do not do these name clean-ups yet, _especially_
without having GIT mailing list discussion about renaming. This
kind of change inevitably introduces merge conflicts.
I suspect this is something you lifted from the larger
libification patch. While I think name cleanups are good in the
long run, I do not see value in lifting only some name cleanups
from a larger libification patch and having people to adjust for
the merge conflicts twice. I would not mind if these renames
happen as a part of libification as a whole. Pending patches
need to be inspected and adjusted when that happens anyway. But
not until then, at least please have a courtecy to give people a
bit of warning and an opportunity to speak out.
------------------------------------------------
Rename some more cache-related functions
same_name -> ce_same_name()
remove_entry_at() -> remove_cache_entry_at()
Signed-off-by: Brad Roberts <braddr@puremagic.com>
Signed-off-by: Petr Baudis <pasky@ucw.cz>
------------------------------------------------
Rename cache_match_stat() to ce_match_stat()
Signed-off-by: Brad Roberts <braddr@puremagic.com>
Signed-off-by: Petr Baudis <pasky@ucw.cz>
------------------------------------------------
Rename cache_match_stat() to ce_match_stat()
Signed-off-by: Brad Roberts <braddr@puremagic.com>
Signed-off-by: Petr Baudis <pasky@ucw.cz>
------------------------------------------------
^ permalink raw reply
* Re: Mercurial 0.4e vs git network pull
From: Jeff Garzik @ 2005-05-15 18:23 UTC (permalink / raw)
To: Matt Mackall
Cc: Adam J. Richter, pasky, git, linux-kernel, mercurial, torvalds
In-Reply-To: <20050515173923.GK5914@waste.org>
Matt Mackall wrote:
> On Sun, May 15, 2005 at 04:22:19AM -0700, Adam J. Richter wrote:
>
>>On Sun, 15 May 2005 10:54:05 +0200, Petr Baudis wrote:
>>
>>>Dear diary, on Thu, May 12, 2005 at 10:57:35PM CEST, I got a letter
>>>where Matt Mackall <mpm@selenic.com> told me that...
>>>
>>>>Does this need an HTTP request (and round trip) per object? It appears
>>>>to. That's 2200 requests/round trips for my 800 patch benchmark.
>>
>>>Yes it does. On the other side, it needs no server-side CGI. But I guess
>>>it should be pretty easy to write some kind of server-side CGI streamer,
>>>and it would then easily take just a single HTTP request (telling the
>>>server the commit ID and receiving back all the objects).
>>
>> I don't understand what was wrong with Jeff Garzik's previous
>>suggestion of using http/1.1 pipelining to coalesce the round trips.
>
>
> You can't do pipelining if you can't look ahead far enough to fill the pipe.
Even if you cannot fill a pipeline, HTTP/1.1 is sufficiently useful
simply by removing the per-request connection overhead.
Jeff
^ 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