* Re: [RFC] adding merge-node to parent lines in a commit
From: Junio C Hamano @ 2005-05-15 22:36 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git
In-Reply-To: <1441.10.10.10.24.1116194876.squirrel@linux1>
>>>>> "S" == Sean <seanlkml@sympatico.ca> writes:
S> Yes, it's pretty basic unless i'm overlooking something:
Rn---\
Mn
Mn-1
Rn-1 |
Rn-2 |
Rn-3--/
Initial
S> So for this particular case it's rather simple, the Rn merge
S> node would have:
S> parent Rn-1 (ommitted)
S> parent Mn Rn-3
Isn't that something you can obtain by scanning the parents and
running merge-base across them without recording it in the
commit?
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Thomas Gleixner @ 2005-05-15 22:13 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <1392.10.10.10.24.1116193437.squirrel@linux1>
On Sun, 2005-05-15 at 17:43 -0400, Sean wrote:
> Well I honestly don't know what you want. If I wanted to include a
> "fortune" line in every commit and couldn't explain what value it
> provided, i'd expect you or others to object.
Last try.
A repository Id makes it possible to identify workflows in and across
repositories.
This information is valuable for me and others due to already discussed
reasons.
I accept that is irrelevant for you.
tglx
^ permalink raw reply
* Re: [RFC] adding merge-node to parent lines in a commit
From: Sean @ 2005-05-15 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfywoqira.fsf@assigned-by-dhcp.cox.net>
On Sun, May 15, 2005 5:30 pm, Junio C Hamano said:
> It is not clear to me ID of what object is being recorded as
> SHA1-MERGE-NODE in your proposal. Care to illustrate?
Hey Junio,
Yes, it's pretty basic unless i'm overlooking something:
Rn---\
> Mn
> Mn-1
Rn-1 |
Rn-2 |
Rn-3--/
Initial
So for this particular case it's rather simple, the Rn merge node would have:
parent Rn-1 (ommitted)
parent Mn Rn-3
Essentially, you are recording in the merge commit the length of each
branch that represents new commits that did not exist in this repository
before this merge.
But there are more complicated cases with multiple parent merges. What
this would avoid is the need to calculate common_anscestor in routines
like git-rev-list, because that information would already be stored. As
far as I know this information is already available at merge time anyway,
so recording it shouldn't be a burden. I'm not sure it buys you a ton
out the other end, but perhaps it would be slightly easier to piece the
merge history back together.
Sean
^ permalink raw reply
* Re: git repository for net drivers available
From: Junio C Hamano @ 2005-05-15 21:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jeff Garzik, Linux Kernel, git
In-Reply-To: <20050515200514.GA31414@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Dear diary, on Fri, May 13, 2005 at 05:29:30PM CEST, I got a letter
PB> 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.
PB> Would it be a big problem to use refs/heads/$branch? That's the
PB> currently commonly agreed convention about location for storing branch
PB> heads, not just some weird Cogito-specific invention. And it'd be very
PB> nice to have those locations consistent across git repositories.
Since Jeff brought up $repo/branches/$branch, you may also want
to add that $repo/branches/$branch is used to record the URL of
the remote $branch (the information used to be in a flat file
$repo/remotes, branch name and URL separated by shell $IFS, one
record on each line), and is quite different from those 40-byte
SHA1 plus LF files you see in $repo/refs/*/ directory.
I think it is a reasonable one, I also follow the
$repo/branches/$branch convention Cogito uses, and I would
encorage other Porcelain implementations to follow suit.
^ permalink raw reply
* Re: git-rev-list in local commit order
From: Sean @ 2005-05-15 21:43 UTC (permalink / raw)
To: tglx; +Cc: git
In-Reply-To: <1116192629.11872.201.camel@tglx>
On Sun, May 15, 2005 5:30 pm, Thomas Gleixner said:
> 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.
Well I honestly don't know what you want. If I wanted to include a
"fortune" line in every commit and couldn't explain what value it
provided, i'd expect you or others to object.
My time based proposal solves the issue of :
Rn------\
Rn-1 Mn
Rn-2 Mn-1
Rn-3 ---/
Initial
Showing up in two repositories sorted based on the order they were
committed locally. This was an issue that you stated you were trying to
solve. The test case works just as advertised. Remote times don't
matter, all that matters is the time you merge the objects locally.
> Even LOCALLY is no guarantee for correct timestamps.
Sure, but then your repoid might have gone missing or be set incorrectly
too. One nice thing if your time is wrong, you can simply reset the
timestamp on the file. If your repo-id is wrong, you have to recast the
commit object which will get a different SHA1 number and make things more
difficult.
Sean
^ permalink raw reply
* 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
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